Removing the common extend did not help, but extending the build script did it, thanks.
I thought a bit more about the current problems of the build system and I really think you should look at what Grails does. It is probably a very good example because Grails had exactly the same needs as Qooxdoo: there are some predefined jobs doing about the same thing (compiling source, compiling and building for production, etc), and IMHO the end result (eg the Grails script system) is quite good. (Btw, I would not say that in general of Grails; eg I tend to like Qooxdoo much more than Grails for a number of reasons, but I do prefer the Grails build system :). I think the main strength of Grails build system is that it leverages an existing framework (Gant which is based on Ant) and extends it via code, and not parameters / config keys. This was really a brilliant idea because you can extend predefined jobs as in Qooxdoo, but you also have the whole power underneath of Ant, with good documentation and many people familiar with it. And writin actual code is so much better than defining keys, because you are never limited, and it makes debugging much easier (just println a variable if you are not sure of its value, etc). This obviously was not the case for Qooxdoo and changing that would pretty much rewrite everything I guess, so this is not possible. However, apart from that, I think many interesting aspects from Grails can be taken and incorporated into Qx to resolve the problems I have spoke about. In particular, IMHO some ideas on what could be done: 1) There should be a "Settings" job that *all* other jobs include (currently that's kind of like the "common" job). Grails has that, with a documented list of all the possible settings / parameters. All macros that are always defined in Qooxdoo should definitely be documented. 2) There should probably be only the concept of extension / inclusion, not of overriding. In Grails you can use the predefined jobs in two ways: * first you can include them as prerequisite, which means that the script will be ran before your actual defined job; * second, if you need to somehow change a bit the behavior of an predefined job, you can hook at various places of the defined jobs to run your own code (like the "CompileStart" event, "CompileEnd" etc). There could be hooks for job specific settings so that you can change those if needed. (that also applies to global settings, instead of having a "let" key you would just hook into the Settings job and redefine the variables). 3) I am not sure how currently the macro are resolved, but it seems once a macro is set it cannot be changed anymore. I think this causes a lot of confusions. Macros should just be variables, and their values changed as many time as you change the value of the variables. Eg, over the run of a job, the macro value evolves with each assignment. I am willing to help on this, file bugs, discuss a bit more over it via IRC, etc. Cheers Jean-Noel On Wed, Dec 16, 2009 at 1:22 AM, thron7 <[email protected]>wrote: > > > "let" : > > { > > "APPLICATION" : "custom", > > "QOOXDOO_PATH" : "/usr/local/opt/qooxdoo", > > "QXTHEME" : "custom.theme.Theme", > > "API_EXCLUDE" : ["qx.test.*"], > > "LOCALES" : [ "en", "fr" ], > > "CACHE" : "${TMPDIR}/cache", > > "ROOT" : "." > > }, > > > > "jobs" : > > { > > "sample": > > { > > "extend": ["common"], > > "compile-dist": > > { > > "code": > > { > > "format": false > > } > > } > > }, > > > > > > When I run ./generate.py build, the locales are correctly generated. > > But when I run ./generate.py sample, they are not: > > > > Why is this happening, I have the LOCALES macro correctly defined? How > > can I fix that? > > For one thing, it is not enough to define a macro, you also have to > *use* it in a job of your own. I wouldn't just extend "common" in the > hope that this will fix it. (It's actually easy to inspect what "common" > will provide you with in tool/data/config/base.json). A probably better > alternative would be to extend the "build-script" job (The config system > is designed such that you achieve best results when extending *existing* > jobs). > > But if you insist to roll your own job from the ground up, it is > necessary that you check all relevant keys and their sub-keys, to > provide sufficient information. Your main action key is a "compile-dist" > key, so you should check the reference for that key. Also mind the > "peer-keys" section that accompanies most of the key descriptions. As an > alternative, you could look into the "build-script" job in > tool/data/config/base.json, to see how it's done there. > > T. > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
