Fritz,

On 06/11/2010 09:20 AM, Fritz Zaucker wrote:
> I have an Application which includes a local library and in the
> application's config.json I include with
> 
>    "jobs" :
>    {
> 
>      "libraries" :
>      {
>        "library" :
>        [
>          {
>            "manifest" :  "../../LocalLibary/Manifest.json"
>          }
>        ]
>    }
> 
> This works as expected.
> 
> In LocalLibrary I use QxJqPlot (but I guess it could just be
> any other library) and try to include it with LocalLibrary's config.json
> doing
> 
>    "jobs" :
>    {
> 
>      "libraries" :
>      {
>        "library" :
>        [
>          {
>            "manifest" :  "contrib://QxJqPlot/trunk/Manifest.json"
>          }
>        ]
>    }
> 
> Unfortunately, this seems not to work as the qxjqplot name space is not
> known/available in the main application. If I move the above library include
> from LocalLibrary's config.json to the application's config.json, everything
> works, but this defies the effort of hiding the dependency from QxJqPlot in
> LocalLibrary (application doesn't use any QxJqPlot element directly).


I know what you're after, but the base line is: You have to repeat the
QxJqPlot library in your application's job definition. There are only
differences in how to achieve this.

What you describe is no "include" in the our sense. Including and, more
interestingly, transitive including is only supported on the *config
level* with the top-level "include" key. This key does transitive
inclusion, so a config file can pull in another config, which in turn
can pull in other configs, asf. The *only effect* of this is that more
job definitions be available in the current config. That's all! But
these job definitions have to be used to be effectual.

The "library" key on the other hand is like any other "normal" config
key that can show up in concrete job definitions. So if you want some
specific key with some specific value to show up in a specific job, you
have just two options:
- put the key and value in by hand
- 'extend' the current job with jobs that have that particular key
and/or particular values of that key that you're after

So, if you want to get at some specific "library" setting of your
LocalLibrary, it's not enough to use this library in the "library" key
of a local job (this just extends the range of paths where classes and
resources are searched). Think of C development where you have to pass
libraries with *each* call to the linker "cc ..... -lm -lpthread -ldl
-lgmp". If you don't want to repeat all those -l options by hand across
multiple applications you would e.g. use a make macro that is available
in all affected Makefiles. Switch to generator: You would need to get at
a job definition that extends you current "library" key with the
necessary values.

You can easily accomplish that by (top-level)"include"ing an 'export
configuration' of LocalLibrary (either in its own config.json or a
dedicated file) that in turn defines an 'export job' that has all the
necessary settings to use this library successfully, e.g.

"jobs" : {

   "export" : {

      "library" : [ { "manifest" :
"contrib://QxJqPlot/trunk/Manifest.json" } ],
      ...
    },

and in your local app's config you do:

"include" : [ { "path": "to/LocalLibrary/config_with_export_job.json",
"as" : "locallib" }]

"jobs" : {

  "my_job_using_LocalLibrary": {

     "extend" : [ "locallib::export", ... ]

This will make sure the additional "library" value is available for this
job.

You might argue that the additional "library" value should somehow be
'automagically' be merged with jobs in your current config, but I'm not
sure about this. I like explicit better :). But maybe we should make a
How-to out of that:

If a library has specific settings that need to be available in jobs
using it, then:
- define an "export" job that defines all those settings
- include this job in the using application
- add this job to the using job's "extend" key

HTH,
T.

> 
> Am I making myself clear? If not I'll be happy to provide more info to the
> toolchain experts ...
> 
> Cheers,
> Fritz
> 

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to