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.
>
>
>
------------------------------------------------------------------------------
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
