harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [drlvm] the build.... why?
Date Thu, 22 Jun 2006 20:27:13 GMT
Well, this is something to look at going forward.  So far, none of the
core build process has been changed, just how dependencies are handled.

geir


Andrey Chernyshev wrote:
>> > 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 <geir@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message