harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [classlib] debug compilation as default
Date Sun, 09 Jul 2006 07:33:02 GMT
On the 0x1A1 day of Apache Harmony Mark Hindess wrote:
> On 8 July 2006 at 1:35, "Ivan Volosyuk" <ivan.volosyuk@gmail.com> wrote:
> > On 7/7/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
> > >
> > > On 7 July 2006 at 21:29, "Ivan Volosyuk" <ivan.volosyuk@gmail.com> wrote:
> > > > On 7/7/06, Geir Magnusson Jr <geir@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message