> At least during development and debugging I want the generate script to
> simply pack all sources into one big file, and nothing more, maybe fix
> some formatting or so, bud definitely not mangle and scramble all variable
> names, remove all whitespace and so on.
A simple concatenation of class files during generation is missing
currently. But why are you not using the source version? This would also
retain file names.
> I first tried this in the application's config.json:
You were close:
> "jobs" :
> {
> "build-script" :
> {
> "fix-files" : {},
"fix-files" will change the class code on disk, but doesn't influence the
code that gets included into the build version.
> "pretty-print" :
> {
> "general" :
> {
> "indent-string" : "\t"
> },
> "comments" :
> {
> "trailing" :
> {
> "keep-column" : false,
> "comment-cols" : [50, 70, 90],
> "padding" : " "
> }
> },
> "blocks" :
> {
> "align-with-curlies" : false,
> "open-curly" :
> {
> "newline-before" : "a",
> "indent-before" : false
> }
> }
> },
Same with "pretty-print", it changes source files on disk.
> "compile-options" :
> {
> "code" :
> {
> "format" : true,
> "optimize" : []
> },
> "paths" :
> {
> "gzip" : false
> }
> }
This is actually the key you want to tweak. And tweaking it in the
"build-script" job is the right place to do it, as this job creates, well,
the build script. The only thing missing here: You should have prepended a
"=" before the "optimize" key, so it looked like this:
"=optimize" : []
Thus, it would not be changed by the default "build-script" job (see
further).
This would basically retain your original code (no name mangling, no
string extraction asf.), but it would remove all comments and most of the
white space nevertheless, so you might find it hard to recognize it :).
> So I changed the build job in tool\data\config.json,
tool\data\config\base.json
> without removing the changes I already did to the application's
config.json.
> Didn't help either.
Depends on what you did in base.json, but this is the place where the
default "build-script" job is defined.
What you have to keep in mind if you define a job in your config.json with
same name as one of the standard jobs is that they are automatically
linked to each other during execution. Your definition of the job is taken
as a template, and the definition coming in from e.g. base.json is merged
into this template. New keys are added to the template, scalar values are
blocked by the template, but complex values (maps and lists) are merged
recursively. In the case of your build-script job, this means that
"format" : true,
will block the value of the "format" key from base.json (as there is no
way to merge atomic values), but
"optimize" : []
will be "merged" (in the case of a list, like here, this means: appending)
with the value coming in from base.json, which is
"optimize" : ["basecalls", "privates", "strings", "variables"]
Append both lists and you'll end up with the full optimization! To avoid
these kinds of merges, the "=" prefix was introduced. A key with this
prefix will block any incoming value from a linked job.
> I looked into tool\data\application.json, and no build job or any related
> job seems to be configured there, so I didn't change anything.
application.json just collects the jobs from base.json together with the
jobs from the components like Apiviewer, Testrunner, etc., so you can
'generate.py api' etc.
HTH,
Thomas
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
