Jean-Noël Rivasseau wrote:
> Hi,
>
> the following snippet:
>
> "setupLibraries":
> {
> "library":
> [
> {
> "manifest": "Manifest.json",
> "uri": "http://www.example.com/js/";
> },
>
> {
> "manifest": "${QOOXDOO_PATH}framework/Manifest.json",
> "uri":
> "http://static.kameleoon-dev.net/qooxdoo/framework/";
> },
>
> {
> "manifest":
> "/usr/local/opt/UploadWidget/Manifest.json",
> "uri": "http://static.kameleoon-dev.net/UploadWidget/";
> }
> ]
> },
>
> "test":
> {
> "extend": ["setupLibraries"]
> },
>
> works (with the exception that a directory ${CACHE} is created and
> used, instead of expanding to "cache"...)
I cannot confirm that a ${CACHE} directory is created. Rather, the
default ${TMPDIR}/cache directory is used, as intended. Maybe yours is
from another generator run with a misconfigured job. The old "cache"
subdirectory is not used anymore.
> However if I just replace "extend": ["setupLibraries"] by "extend":
> ["libraries"] (and replace setupLibraries by libraries), the test
> files will be placed in the build directory as a result of the
> BUILD_PATH set to build.
Well, I'll try to make a long story short. This is a rather nasty effect
of the way job extending works. First you have to be aware that you are
overriding (or "shadowing") two pre-defined jobs in your config, "test"
and "libraries". The generator warns you about that saying
- ! Shadowing job "libraries" with local one
- ! Shadowing job "test" with local one
This is to prevent accidental overriding, but I assume you were doing it
on purpose. When you renamed your local "setupLibraries" to "libraries",
you were shadowing the predefined "libraries" job. This results in your
local job silently extending the predefined job, so '"libraries" :
{...}' becomes '"libraries": { "extend" :
["application::libraries"],...}'. This is how shadowing is supposed to work.
Since the order in which job extending is then processed is depth-first,
this results in "test" -> includes "libraries" -> inlcudes
"application::libraries". But application::libraries already carries
(unnecessarily at this point) the BUILD_PATH macro from
application.json, introducing it into the target job "test". After that,
the subsequent inclusion of application::test (which is caused by the
local "test" job shadowing the one from application.json, see?!), which
carries the correct BUILD_PATH macro (${ROOT}/test) cannot overwrite the
existing value, since existing values always take precedence of
inherited values. Therefore, the test application is created in the
"./build" directory.
I believe I should resolve the global "let" section in base.json into
job-specific let sections, so the "libraries" jobs will not carry
unnecessary macros with it.
There are various work-arounds you could apply, other than renaming your
"libraries" job again. A very simple one would be to remove your local
"test" job entirely, as it does nothing more than including the
"libraries" job. But as this is shadowing the predefined "libraries"
job, it will be included anyway (as all predefined compile jobs use it),
and your local version of it will be used. So the standard "test" job
will use it, but now its own definition of BUILD_PATH comes first, and
so cannot be overwritten later. It's just a matter of the point in time,
at which a setting is introduced.
If you intend to keep your local "test" job, another work-around would
be to add a local "let" section to the job, with BUILD_PATH :
"${ROOT}/test", as this would take precedence over everything else. But
I would prefer the previous solution.
Could you open a bug for it, including your config file and my answer?
Thanks.
>
> I *really* cannot understand why this happens. I tried to trace that,
> looking at a lot of config.json file, but I dont get it... It seems to
> me it should not behave like that.
You can get an idea by looking at the output of "generate.py test -v"
very closely, as it shows in which sequence jobs are included into each
other. But it's a real challenge to decypher what's going on (even for
me ;).
HTH,
T.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
