Re: Building choices (was: Re: Code contribution to harmony)
On 11/23/05, Graeme Johnson [EMAIL PROTECTED] wrote: 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Well, good point. However, as it was suggested earlier in the thread, let's separate the building platforms and the target platforms. I would expect that one most likely will choose some conventional platform for the development and building. Hence, there is a high probability that Java is already available there. Bootstraping for Javaless platforms can be solved with C cross compiler. GCC does exactly the same to bootstrap. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. I would agree that make is the preferred choice for any Unix developers. The problem actually comes when we start to develop on Windows (I believe, there still be a plenty of such developers). Let's consider the specific example – I'm building on Windows. I can use nmake, but, it is MSVC specific and is not available on Linux, hence it can't be our choice. Next, I'll try to use gmake – this, however, requires me to install cygwin in addition to MSVC. Note that I already have Java installed since I'm building the java sources with ant. Then the question comes, why do I have to install something else? The problem is that C development toolset isn't necessarily associated with the make toolset, and the make toolsets are not always compatible with each other. Make-based builds sometimes tend to do not work even between the different Linux distributions, if not specially hacked. Java luckily conforms to a single standard, hence works everywhere similarly, if only available. I'm currently working on preparing a prototype of a full ant-based build system which would allow to build the provided class libraries contributions. Perhaps it would make sense to return to this talk some time later if I get the prototype working. Thank you, Andrey Chernyshev Intel Managed Runtime Division
Re: Building choices (was: Re: Code contribution to harmony)
Tim Ellison [EMAIL PROTECTED] wrote on 11/21/2005 07:17:16 AM: Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. [snip] 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. Graeme Johnson J9 VM Team, IBM Canada.
Re: Building choices (was: Re: Code contribution to harmony)
that is the most convincing argument till now. :-) bye :-) Ashish Ranjan India [EMAIL PROTECTED] On 11/23/05, Graeme Johnson [EMAIL PROTECTED] wrote: Tim Ellison [EMAIL PROTECTED] wrote on 11/21/2005 07:17:16 AM: Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. [snip] 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. Graeme Johnson J9 VM Team, IBM Canada.
Re: Building choices (was: Re: Code contribution to harmony)
Matt Benson wrote: --- Ashish Ranjan [EMAIL PROTECTED] wrote: that is the most convincing argument till now. :-) +1 from an Ant PMC member. That logic is irrefutable. :) -Matt What about cross-compilation/cross-building ? If harmony is to be successful in its goal of wide portability I would expect that the build process would make cross-builds almost as easy as native builds. -- Robin bye :-) Ashish Ranjan India [EMAIL PROTECTED] On 11/23/05, Graeme Johnson [EMAIL PROTECTED] wrote: Tim Ellison [EMAIL PROTECTED] wrote on 11/21/2005 07:17:16 AM: Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. [snip] 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. Graeme Johnson J9 VM Team, IBM Canada. __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Re: Building choices (was: Re: Code contribution to harmony)
On Mon, Nov 21, 2005 at 12:17:16PM +, Tim Ellison wrote: There is a distinction to be drawn between the portability of the 'product' (i.e. the VM, class libaries, tools, etc.) that we are building, and the portability of the toolsuite that is used to build it. Hmm. I'm not convinced of the need to make the development toolset portable across all platforms. Regardless of the relative merits of Ant and make and other alternatives (I tend to think both Ant and make are painful beyond a certain project size. Lately I've been a fan of scons (http://www.scons.org/)), having a stable, consistent, free, dependable, stable, easily accessible, stable (etc) build system is quite important for open source project success. I didn't say portable, but having a cross-platform (cross-make, cross-compiler, ...) build system means you only need to maintain one which might mean all those other factors are consistently taken care of. The build consistency of higher level tools such as Maven or the various setups for all the scripting languages (Ruby Gems comes to mind) is very valuable and if its attainable for us (really, I don't have a clue) then that is quite valuable. LSD
