Sorry for the second reply, but just noticed a piece of your question I wanted to clarify (above).
Originally Posted by nefis
The "sencha build" command is a low-level command that is equivalent in scope to "sencha compile". So if you have a build process based on JSB files and the like, "sencha compile" is the logical upgrade to that.
On the other hand, if you had used the SDK Tools v2 "sencha app build" process previously, then this is the same in Cmd - except that internally Cmd uses the compiler vs the old JSB process. This is the best option in many cases because "sencha app build" automates so many more pieces of the build process.
But if you had not been using that in previous versions, the upgrade from "SDK Tools and JSB files" to "Cmd and app build" is a bit of apples-and-oranges as it were. I believe you will be better off basing higher-level builds on "sencha app build" but it is a bit different than the low-level approach.
I just ran into the same issue...
The only reason I got interested in compile instead of build is so that I could:
- Choose the compressor
- Only generate the JS (not the HTML, assets, etc.)
Are there config switches for build that would do that?
Wouldn't it be easier for Sencha to publish the exact compile command used to build a project?
There are options in the build script you can set to control this - more so in an Ext JS app than Touch at the current time, but we are working to regularize that. I encourage you to read the build script to see what is going on - it is found in .sencha/app/build-impl.xml. I would not recommend changing that file as it is replaced when you upgrade Cmd, but that should give you the details you are wanting. In a pinch, of course, you can edit the file if needed but just be aware of this or you may lose your edits on upgrade.
The "sencha app build" command simply loads the generated build,xml (which imports .sencha/app/build-impl.xml) and invokes the "build" target. This target comes from the build-impl and consists of many stages to handle JS compilation, SASS building and resource copying. Each of these stages can be "hooked" by providing "-before-" or "-after-" targets in your build.xml.
This is only going to gain more features as we ship Cmd 3.1 with vastly improved theme support, so the ideal division of labor is to leverage "sencha app build" or the build.xml directly and look at the tuning properties we provide. If we have missed some, let us know.
Having said all the above, there are advanced use cases that require more direct interaction with the compile command. This can be addressed by augmenting or editing the build scripts or by learning what they do and making your own. According to the "one size never fits all" rule, we also need to document this low level support provided by Cmd. Sadly, all that documentation can just be misleading for folks that would be content on the simple path.
For 3.1, I'll definitely want more granularity with steps like these
available from the command line, so that we can script some common operations:
- js, generates app.js
- html, generates both the JS and html
- assets, could take care of all the non-js things?
"sencha app build testing js" to build app.js
"sencha app build package sass" to compile the finalized css for our app
Compression could be available per classpath, defined in sencha.cfg
And I agree, documentation is key. Took me a while to figure out what to put in a command file as the syntax differs from what you would type on the command line.
Regarding build-impl.xml, I'm guessing that we can only play with the properties found in the "-page" target, which means that things like compression are not available. Correct?