You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/06/07 00:09:45 UTC
[drlvm] the build.... why?
I have to admit, I don't grok the build for drlvm.
I was trying to figure out how to unhook the building of everything,
like APR and our own classlib, and I just got lost in layer after layer.
It certainly is an impressive achievement - the author clearly
understood how to get the best out of ant, and there are some very
clever things in there, but for maintainability by a broad group of
people, I think it's going to be challenging.
I may be just too much of a simpleton, although the generated 21,000
line ant script gave me confidence that I wasn't too off base. :)
So... can someone provide some background?
Personally, I'd love to see something like we're using in classlib, w/
ant as the scripting environment, using make where appropriate...
geir
---------------------------------------------------------------------
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
Re: [drlvm] the build.... why?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 <ge...@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
Re: [drlvm] the build.... why?
Posted by Andrey Chernyshev <a....@gmail.com>.
> > 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 <ge...@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
Re: [drlvm] the build.... why?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
Re: [drlvm] the build.... why?
Posted by Salikh Zakirov <Sa...@Intel.com>.
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
2. Do not use Cygwin for the build on Windows
(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)
> 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.
> 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.
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).
--
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
Re: [drlvm] the build.... why?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Of course I can get it to work, and it works well. Like I said in my
first note, it's very impressive.
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.
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?
Also, it doesn't use 'make' for building the C/C++ code. Why?
geir
Vladimir Gorr wrote:
> Hi Geir,
>
> It's not exactly clear to me how you started the build process for DRLVM
> but I hope it has been made in accordance with the README file, namely:
>
> - set ANT_HOME & JAVA_HOME env variable
> - cd build; build.bat update
> - build.bat
>
> Second step is intended for downloading all necessary third-party sources
> used by DRLVM
> (APR, LOG4CXX, ICU and etc). After this the *pre-copied* directory will be
> created where all sources are kept.
> No needs to perform this step if downloading is successfully finalized. The
> latest step will start the build process
> for all downloaded resources including the Harmony classes. All binaries
> will be in the *build\win_ia32_icl_debug\deploy\jre* directory.
>
> Thanks,
> Vladimir.
>
>
> On 6/7/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>> I have to admit, I don't grok the build for drlvm.
>>
>> I was trying to figure out how to unhook the building of everything,
>> like APR and our own classlib, and I just got lost in layer after layer.
>> It certainly is an impressive achievement - the author clearly
>> understood how to get the best out of ant, and there are some very
>> clever things in there, but for maintainability by a broad group of
>> people, I think it's going to be challenging.
>>
>> I may be just too much of a simpleton, although the generated 21,000
>> line ant script gave me confidence that I wasn't too off base. :)
>>
>> So... can someone provide some background?
>>
>> Personally, I'd love to see something like we're using in classlib, w/
>> ant as the scripting environment, using make where appropriate...
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> 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
Re: [drlvm] the build.... why?
Posted by Vladimir Gorr <vv...@gmail.com>.
Hi Geir,
It's not exactly clear to me how you started the build process for DRLVM
but I hope it has been made in accordance with the README file, namely:
- set ANT_HOME & JAVA_HOME env variable
- cd build; build.bat update
- build.bat
Second step is intended for downloading all necessary third-party sources
used by DRLVM
(APR, LOG4CXX, ICU and etc). After this the *pre-copied* directory will be
created where all sources are kept.
No needs to perform this step if downloading is successfully finalized. The
latest step will start the build process
for all downloaded resources including the Harmony classes. All binaries
will be in the *build\win_ia32_icl_debug\deploy\jre* directory.
Thanks,
Vladimir.
On 6/7/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> I have to admit, I don't grok the build for drlvm.
>
> I was trying to figure out how to unhook the building of everything,
> like APR and our own classlib, and I just got lost in layer after layer.
> It certainly is an impressive achievement - the author clearly
> understood how to get the best out of ant, and there are some very
> clever things in there, but for maintainability by a broad group of
> people, I think it's going to be challenging.
>
> I may be just too much of a simpleton, although the generated 21,000
> line ant script gave me confidence that I wasn't too off base. :)
>
> So... can someone provide some background?
>
> Personally, I'd love to see something like we're using in classlib, w/
> ant as the scripting environment, using make where appropriate...
>
> geir
>
> ---------------------------------------------------------------------
> 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
>
>