On the 0x1A1 day of Apache Harmony Mark Hindess wrote: > On 8 July 2006 at 1:35, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > > On 7/7/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > On 7 July 2006 at 21:29, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > > > > On 7/7/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Ivan Volosyuk wrote: > > > > > > > > > > > > The drlvm build already has ant property called "build.cfg" > > > > > > and "build.cxx" for the debug or release build and the > > > > > > compiler name. The properties is initialized from BUILD_CFG > > > > > > and CXX environment variables. IMHO, it will be convenient to > > > > > > have the same property for drlvm and classlib build. Is it ok > > > > > > to have _this_ property names? I don't think the word 'native' > > > > > > in property make sense as this switch can be used somehow even > > > > > > in java build (?) eventually. > > > > > > > > > > > > > > > I do think we should agree on something, to make federation > > > > > easier. > > > > > > > > > > geir > > > > > > > > Linux version of the makefiles update is already in > > > > http://issues.apache.org/jira/browse/HARMONY-803 > > > > > > The DEFINES and INCLUDES is exactly the kind of thing I was thinking > > > about. However: > > > > > > 1) I think we've somehow lost the default '-O1' option > > > > Yes. I'll fix it. > > > > > 2) I think the $(shell uname -m) is overkill, we'll handle this a > > > better way when the time comes in the meantime forking/execing sh > > > and uname for each call to make is just overhead. > > > > I know that fork/exec operation is quite efficient on linux, more over > > the compilation of sources uses much more time. > > But it always returns the same result, for any valid architecture that > we can build on, so why not just leave it out for now? > > As a general rule, we add complexity when we need it not before we need > it without any discussion/justification. > > > > > I didn't touch ant build system. It allows to pass environment to > > > > makefiles. That's enough. Makefiles will do the rest. > > > > > > Sorry, but I don't like this for reasons I discussed yesterday. It > > > was late and I guess I wasn't clear enough. > > > > > > It should be done via ant because ant is the interface that > > > developers should be using to execute the build - either using the > > > top-level ant file or the module ant file (or via some federation > > > calling ant). Even if they are only building native code in a > > > module developers should still use the ant file. > > > > Working on different projects, I've found out that Java programmers > > and C programmers have different habits. Java programmers likes ant, > > Linux/C programmers - make. I am C programmer :) > > (I don't think it helps clarify the issue, but for the record, I'm a C > programmer and Perl hacker. I don't particularly like make or ant. I > like using the right tool for the job.)
For the more record, I am a C programmer too :) And not scared of 'ant' :) Except one thing: let's do the *parallel build feature*. It is a real pleasure to use it with 'make'! > Harmony Classlib is primarily a Java project that includes a little > C code[1]. The build is kicked off with ant so ant is the primary > *interface* for developers, are you suggesting we change the top-level > interface to make? > > It still uses make for the C underneath so as not to scare off C > developers when they work at that level but they are always encouraged > to kick off the build via ant for consistency. > > > If we going to do all the build ant-way, let's use cpptask as DRLVM > > does. But I will not sign up under that task - I can deal with > > makefile based build system, but I have quite little knowledge of ant > > to do that task. > > No. As you say C programmers prefer tools like make (and configure) > so we decided a while ago to stick to tools that matched expectations > (for the implementation but not the interface). > > I'm not arguing that we should use *ant* for the *implementation* of the > C code building just that ant is the *interface*. > > > > We may change[0] the way native code is built if handle things like > > > this configuration issue via ant then the interface for developers > > > can remain the same even when we change what happens under the > > > covers. > > > > > > Regards, Mark. > > > > > > [0] Probably sooner rather than later if we start ports to other > > > platforms. > > Regards, > Mark > > [1] Arguably as little as we can get away with because we believe that > in the long term the JIT will do better than a compiler when it comes to > optimisation. Mark, do you mean that the JIT should be better than what it is? :) -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
