Hi Thomas,
thanks very much for the extensive explanation. I think I understood what's
going on and will to setup the solution you suggested. As far as I can see
that will at least let me hide the specific dependency of LocalLibrary by
paying the price to have "include" it in a bit more complex way.
I'll get back if new issues arise.
Cheers,
Fritz
On Fri, 11 Jun 2010, thron7 wrote:
> 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
>
>
--
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
------------------------------------------------------------------------------
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
