> As far as I understand, the trick with preprocessing XML files allows to keep > platform-specific configuration compactly in one readable file. > And by the way, the XML transformation (what you call "meta build" system) is > only limited to filtering XML fragments based on the detected platform.
Sorry for jumping in with a late explanation and thanks to Salikh who have already answered the most: Yes, this is correct - the DRLVM build generates XML scripts on the fly primarily to filter out the XML fragments which are irrelevant to the selected configuration (which is defined by attributes - OS, Arch, compiler, release/debug mode). Another idea behind the DRLVM build was to share as much building code between the different modules as possible, while trying to keep flexibility for each individual module. An intent was to let the code developers do not write any building code (like javac tasks) for their modules, but rather describe what the specific module is (see examples os the component descriptors under the drlvm/trunk/build/make/components directory). Some of the concepts of DRLVM build can be found at: drlvm/trunk/build/make/components/readme.txt Though this scheme may look pretty tricky, it helped to minimize the code in XML files and allowed to avoid writing makefiles for each specific module (only descriptors have to be written for the modules). You now may see whether it's convenient enough or not, but at least it worked :)
Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml
build.tmp.xml is produced just to put all modules together into a single file in order to process the dependencies between the modules correctly. Thank you, Andrey Chernyshev Intel Middleware Products Division On 6/7/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Salikh Zakirov wrote: > Geir Magnusson Jr wrote: >> What I don't understand is the "motivation" or the "theory" behind how >> and why it was done. I'm hoping that if I grok that, all will fall into >> place for me and with that different perspective, I might find it easier >> to work with. > > The two main requirements behind the design of this build system were > 1. Unify the build system for the class library and VM But we can *easily* do that simply by having a top level script first invoke the DRLVM build, and then the classlibrary (or whatever order is approrpros...) > 2. Do not use Cygwin for the build on Windows That's fine, although at some point, someone will hopefully make that work too. > > (and a number of other reasonable requirements > 3. incremental build > 4. tracking C++ dependencies > 5. keeping platform-specific configuration in a compact and readable form) Ok > >> As I understand it, it's really a "meta build" system, as it's purpose >> seems to be to create the actual ant scripts that execute to do the >> work. Why? > > (less sure about this one) > As far as I understand, the trick with preprocessing XML files allows to keep > platform-specific configuration compactly in one readable file. > And by the way, the XML transformation (what you call "meta build" system) is > only limited to filtering XML fragments based on the detected platform. Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml > >> Also, it doesn't use 'make' for building the C/C++ code. Why? > > Using GNU make leads to requirement to have GNU tools on Windows (contradicts > requirement (2) above) > NMAKE cannot be used since it is not available on the Linux. We seem to do ok w/ classlib though...? > Moreover, <cctask> from Ant-contrib is not bad in tracking dependencies > and running various kinds of compilers. > > We used GNU Make for some time while preparing DRLVM contribution, > but moved on to Ant-based system later because of requirements (1), (2). Ok, thanks. > > -- > Salikh Zakirov, Intel Middleware Products Division > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
