On 05/10/2013 10:43 AM, Peter Schneider wrote:
> Hi there,
>
> I would like to know if it is possible to "switch on/off" a "copy-file" (and
> "add-script") sub-job dependent on variants?
>
> For example, depending on the setting of the "myApp.withWebSocket":
>
> <code>
>
> // ...
>
> "build" : {
> "environment" : {
> "myApp.withWebSocket" : false, // [true|false]
> // ...
> }
> },
>
> "source" : {
> "environment" : {
> "myApp.withWebSocket" : true, // [true|false]
> // ...
> }
> },
>
> // ...
>
> "source-script" :
> {
> // *** Possible to enable/disable this via environment/variants? ***
> "add-script": [ { "uri" : "./resource/socket.io/socket.io.js" } ]
> },
>
>
> "build-script" :
> {
> // *** Possible to enable/disable this via environment/variants? ***
> "copy-files" : {
> "files" : [ "./socket.io/socket.io.min.js",
> "./socket.io/WebSocketmain.swf",
> "./socket.io/WebSocketMainInsecure.swf" ],
> "source" : "./source/resource/",
> "target" : "./build/"
> },
> "add-script" : [ { "uri" : "socket.io/socket.io.min.js" } ]
> },
>
> },
>
> // ...
> </code>
>
> is something like this possible?
Generally, there is no conditional branching in the config. What you
could do, though, is to mis-use macros to draw in settings from other
jobs by making the other job's name depend on the macro value. E.g. in
the case of the 'add-script' key you could
"source-script" : {
"let" : {
"FLAG" : "do" // or "no"
},
"extend" : ["my-add-script-${FLAG}includer"]
},
"my-add-script-doincluder" : {
"add-script" : [ { "uri" : "./resource/socket.io/socket.io.js" } ]
},
"my-add-script-noincluder" : {
// intentionally left empty
}
And then set the FLAG macro to "do" or "no" according to what you want.
You can do this in the global "let" section of your config.json, or on
the command line with '-m FLAG:no'. The same should work with a
'copy-files' key. The basic idea is always to have two includer jobs for
the same set of settings, and depending on a macro you will include one
or the other.
This is only possible with macros, so you cannot use an environment key
directly as you intended. But you can work the other way round and make
the environment key depend on a macro. Unfortunately, only string values
will work this way with macros so true and false cannot be used in job
names . So you will have to provide the 'environment' key also as part
of an includer job.
In your special case it is probably not possible to accumulate several
settings into a single pair of includer jobs, but you might have to have
individual pairs for each setting (as you need individual settings in
different jobs). So you might end up having this pattern of includer
jobs (job contents mostly omitted for clarity):
"withWebSocket-env-yes" : {
"environment" : { "myApp.withWebSocket" : true }
},
"withWebSocket-env-no" : {
}
"withWebSocket-add-script-yes" : {
},
"withWebSocket-add-script-no" : {
},
"withWebSocket-copy-files-yes" : {
}
"withWebSocket-copy-files-no" : {
}
(In fact, some of these jobs could actually remain empty). Then use
these includer jobs in the source and build jobs, e.g. your build jobs
could look like this:
"build" : {
"extend" : [ "withWebSocket-env-${WithWebSocket}"]
},
"build-script" : {
"extend" : [
"withWebSocket-env-${WithWebSocket}",
"withWebSocket-add-script-${WithWebSocket}",
"withWebSocket-copy-files-${WithWebSocket}"
]
}
and you would set the macro "WithWebSocket" to either "yes" or "no".
HTH,
T.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
