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.) 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. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
