Hi Jean-Noel,
I had exactly the same problem
I can reproduce your problem by specifying a QOOXDOO_PATH variable pointing
to an older (0.8.2) version of the Qooxdoo sdk with my current 0.8.3 setup
(which works just fine if I specify the correct QOOXDOO_PATH as I just confirmed
to be sure).
So it looks as if you somewhere point to the wrong Qooxdoo version (I
suspect the older generator script or something like that not handling the
cache variable setting the same as in 0.8.3).
Cheers,
Fritz
On Wed, 16 Sep 2009, Jean-Noël Rivasseau wrote:
Hi, thanks for the help. I indeed did a generate.py test -v before posting
to the ML, but even with the verbose output I would not have understood with
your help. But your reply made things clear.
One key thing I was missing is that apparently overriding a job actually
extends it, and does not replace it as I though. Am I corrrect?
A few points about your reply:
1) I do have the ${CACHE} directory created everytime. I am on 0.8.3 and
this is prefectly reproducable everytime on new projects. I have this even
with a blank config.json file from a new project (only when I run the test
job though; source effectively does not have this), see below:
{
"name" : "custom",
"include" :
[
{
"path" : "${QOOXDOO_PATH}/tool/data/config/application.json"
}
],
"export" :
[
"api",
"build",
"clean",
"distclean",
"fix",
"inspector",
"lint",
"migration",
"pretty",
"profiling",
"source",
"source-all",
"test",
"test-source",
"translation"
],
"let" :
{
"APPLICATION" : "custom",
"QOOXDOO_PATH" : "../../../../../usr/local/opt/qooxdoo",
"QXTHEME" : "custom.theme.Theme",
"API_EXCLUDE" : ["qx.legacy.*","qx.test.*"],
"LOCALES" : [ "en" ],
"ROOT" : "."
}
}
2) Your suggestion of simply droping the test job worked well.
On Wed, Sep 16, 2009 at 11:34 AM, thron7 <[email protected]>wrote:
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.
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
------------------------------------------------------------------------------
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
