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: [jchevm] Porting JCHEVM to OSX/PPC
The good news first: it compiles now. The problem I described in the previous mail was that libjc was linked with the option -module (so it can be dlopen()ed) and this is not portable. I removed the -module and now it compiles. I stripped out lots of ELF specific stuff, so my version could be interesting for a port to windows too. I just don't want to commit it to trunk yet because it's completely untested. Hi David, I'm trying to compile JCHEVM with MSVC but, at the moment, the work, as underlined by Archie, last week, is not trivial and in fact, I'm having a noticeable number of compiling errors. Next week, I'm gonna try to use the native port of the GNU chain, MinGW, as suggested by Ashish Ranjan and compile JCHEVM with GCC. Since you have successfully compiled the code with GCC, could you tell/send me the modifications you did, in order for me to speed up the job? Has anybody tried to use the U/WIN project by ATT instead of MinGW? The U/WIN project is a DLL (posix.dll) that seats on top of Windows and allows the programmer to call all POSIX APIs Enrico
[result] Re: [vote] accept JIRA contribution HARMONY-14 (IBMs contribution of core classlib, native support and vm/classlib interface)
Ok, this was longer than 72 hours, but good things are worth waiting for. By my count, there were 8 +1s, no 0s or -1s, and it seems that Anindo Ghosh tried to vote twice :) So I'll finish the admin stuff and drop into the sandbox, and then we start thinking about how we might want to re-arrange things. geir On Nov 26, 2005, at 11:12 PM, Geir Magnusson Jr. wrote: IBM has offered a core to a class library, native support and vm/ classlib interface to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-14 The paperwork (Bulk Contribution Checklist) has been received, and while the entire codebase hasn't been written by people that can satisfactorily execute an Authorized Contributor Questionnaire, new code has been, the contributor asserts that all code was written under a process designed and executed to prevent access to other implementations, and various examinations have turned up nothing of material concern. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Full disclosure
On Mon, 2005-11-28 at 07:16 -0800, Leo Simons wrote: I didn't take notes but one of the many things I took away from this is that it might be a real good idea to try and see if classpath can be LGPLed; Mark seemed to think that is not an unattainable goal. When I get my hands on some spare time (I hope it'll be under the christmas tree) I hope to push forward om some of that. I don't understand this. The GNU Classpath license was designed to be even more liberal than the LGPL. What makes relicensing GNU Classpath to LGPL a good idea? AG
