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)
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)
--- Ashish Ranjan <[EMAIL PROTECTED]> wrote: > that is the most convincing argument till now. :-) +1 from an Ant PMC member. That logic is irrefutable. :) -Matt > 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)
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)
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)
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
Building choices (was: Re: Code contribution to harmony)
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. However, the Ant cpptask wrappers the same platform compiler, so the complexity in terms of options etc. is equivalent. The resource dependency checking performed by Ant and make are both done 'behind the scenes' anyway. Was there some other part of Ant and make that you were thinking about? > - Having make in addition to ant will introduce additional > dependencies for the build. While make is available on Unix systems, > it is not available on Windows by default, one would have to install > it as a part of cygwin, MSVC or whatever. You are right, there is no C development environment shipped with Windows by default. I doubt we can fix that very easily :-) Everyone will need to install a C development environment to use cpptask too. > Another issue is that nmake > that comes with MSVC and gmake are not compatible with each other. Agreed. One of the many platform-specific areas we deal with everyday. At development time the differences include code and resource compilers, packaging and so on; at runtime the differences include resource management, OS APIs, etc. I see that in HARMONY-16 you have used break-out XML files (jaaswin.xml and jaasnix.xml) to deal with the build-time differences. That's fine. Some level of the tooling will have to bridge the differences. > - Overall, ant possibly better suites the portability needs, at least > between Windows and Linux 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. I'm not convinced of the need to make the development toolset portable across all platforms. I'd rather enable people to choose their development tooling within the broadest set of resources that we are prepared to support consistently. So if people want to use command-line tools (emacs, make), or IDEs (Eclipse CDT or VisualSudio) then they should be free to make that choice. > As an example, I can suggest to look at Intel's contribution of the > security package at http://issues.apache.org/jira/browse/HARMONY-16. > > Though the experts may say the example isn't ideal (the native part of > security is really simple such that the build doesn't even utilize ant > cpptask), it still may serve as illustration of the alternative > approach, e.g. building a product using a single language. I think the discussion is simply at what point the Ant script does a platform-specific . When using 'make' the script calls-out early and uses make to manage the native code side dependencies; when using 'cpptask' the script calls-out later and uses Ant to manage the dependencies. We figured that 'make' was a more universal C build system than cpptask. > Thank you, > Andrey Chernyshev > Intel Managed Runtime Division > Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
