Gaetan de Menten wrote:
> Here is one regression in 0.8: moving the qooxdoo lib around is a pain:
>
> In 0.7.x you only had to change the path to where Qooxdoo is installed
> in one place. Now you have to change it in 3 places: twice in
> config.json and one in generate.py, which is especially ugly IMO.
>
Yes, but the generate.py is only a concession to people which are
uncomfortable with juggling paths, for the time being. It's just a path
proxy for tool/bin/generator.py. I wouldn't use it altogether but just
added ${QX}/tool/bin to my PATH, or define a shell alias to it :).
> Couldn't the "userland" generate.py get the path to qooxdoo from config.json?
>
That would be possible, but actually we are aspiring to something more
elaborate, like a build tool gui.
> Also I tried to eliminate the extra one in config.json, by having
> something like this:
>
> "let" :
> {
> "QOOXDOO_ROOT" : "../qooxdoo/0.8/",
> "QOOXDOO_PATH" : "${QOOXDOO_ROOT}/framework",
> },
>
> "include" :
> [
> {
> "path" : "${QOOXDOO_ROOT}/tool/data/config/application.json",
> "as" : "appconf"
> }
> ],
>
> But apparently the macro system doesn't work for the "path" key (it's
> not expanded)...
>
Yep. Macros are only expanded in jobs, not other entities like the
top-level include. The top-level 'let' itself was an afterthought, to
eliminate jobs entirely in the simplest config files (a fact which I
never really liked much). Now we're re-thinking the whole config file
schema.
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
