Re: [qooxdoo-devel] Makefile Migration from 0.7 to 0.8 questions and suggestions

[thron7 <th...@us...>]

> The only reason I ended up writing the config.json file this way was that
> this was the only way I found that got the "compile-source" key to affect
> the build process. I tried putting that same "compile-source" key in several
> different places in my config.json file, and the result was either that it
> was ignored (thus default values were used for the generate source command)
> or a fatal error. When I tried to define my own job named "source" and put
> the key there, I get this: KeyError: u'Job already exists: "source"'. (I was
> trying to follow the example config file listed here:
> http://qooxdoo.org/documentation/0.8/generator_config )

This sample doesn't use any external config (there's no top-level 
"include" key). But you can easily circumvent the name clash by renaming 
your local job to something like "mysource".

>  So my question boils
> down to, if I want to provide "compile-source" arguments to the "source"
> job, how do you recommend I put them in the config.json file I posted
> earlier?
>   

A simple way for doing this would be as follows: You had the "my-source" 
job already. Remove the "run" key and add "extend" : ["source-script"] 
(provided you are using the trunk version of qooxdoo; otherwise see 
further down). This should do the job. For the build version it is more 
complex (see also further down).

The point here is that you actually don't want to parameterized the 
"source" job with a modified "compile-source" argument, but the 
"source-script" job one level further down.

> I've tried putting that key in the top level of the JSON object, in the
> "jobs" key, and in an individual "job" key.

The only valid context for the "compile-source" key is an individual job 
(This URL tries to convey this: 
http://qooxdoo.org/documentation/0.8/generator_config#listing_of_keys_in_context)

>  None of those places worked for
> me unless I defined my own job, which you don't recommend doing.

Oh yes, I *do* recommend defining own jobs! I just wanted you to be 
aware of the peculiarities incurred by using the "run" key within a job.

>  (Also, it
> doesn't work when I try a build version.)
>   

It can't. The "compile-source" key is the key to trigger creation of the 
source version. "compile-build" is the key to create the build version, 
and it's an independent key. Changes you do to one don't affect the other.

>> Here's a little quiz for everybody:
>> How many times would the compiler generate the build/script/<name>.js 
>> file if you applied the same strategy to the "build" job? How could you 
>> overcome this problem?
>>
>>     
>
> No idea, which is why I'm posting here. ;)
>   

Too bad nobody anwered to this one (I was silently hoping I could stir a 
little playful competition by posting a series of generator quizzes, 
thereby fostering more insight in its workings ...:(.

If you created a "my-build" job like "my-build" : { "compile-build" : 
..., "run" : ["build"] }, this would have happened: Since the "build" 
job from base.json is a run job itself, and is expanded into three 
distinct jobs, each of these jobs would have inherited the 
"compile-build" key from the "my-build" job. Running this job would have 
resulted in the compiler generating the script output three times 
(provided there were no errors in between).

You'd overcome this problem by moving the "run" key to a separate local 
job with the only key being "run" : ["build-resources", "build-files", 
"my-build"], and at the same time defining "my-build" as "my-build" : { 
"compile-build" : ...<as before>..., "extend" : ["build-script"] }. This 
way, you have a local job with a "run" key that runs the default 
build-files, build-resources, but in place of the default build-script 
it runs your self-defined my-build. This one contains the compile-dist 
key, but makes also use of the settings derived from the original 
build-script job. (This only works when the application.json/base.json 
have no "export" key restriction on the top-level, which is the case in 
the trunk version since recently; you can remove it manually if you have 
a 0.8 release version).

HTH,
Thomas