harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib] debug compilation as default
Date Mon, 10 Jul 2006 13:41:50 GMT

On 10 July 2006 at 16:18, "Ivan Volosyuk" <ivan.volosyuk@gmail.com> wrote:
> On 7/9/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
> >
> > On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= <thunde
> raxiom@gmail.com> wrote:
> > > Ivan Volosyuk skrev  den 08-07-2006 00:35:
> > > > 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 :)
> > > > 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.
> > > Personally I think that it will be easier to use other C IDE's if the
> > > project uses Makefiles since that is what historically has been used for
> > > that purpose.
> > >
> > > Make and ant are to me very different in how you think when using it
> > > - make is in terms of creating rules for deriving file(s) from other
> > > file(s), where ant describes tasks.
> > >
> > > I think it is fine to use ant to invoke the global build, but
> > > that make should be used for the C build.  Perhaps ant can build
> > > the configuration files used by make?  Something similar to what
> > > "configure" does?
> >
> > No.  I think we should just invoke configure not re-invent it in ant.
> >
> > The point is that if/when we change from using raw make to using
> > configure the developer running ant at the top-level (or module level)
> > shouldn't care how, for example:
> >
> >   ant -Dbuild.cfg=release
> >
> > and:
> >
> >   ant -Dbuild.cfg=debug
> >
> > is implemented underneath.
> >
> > Regards,
> >  Mark.
> Mark,
> What's wrong with the notation:
>   'BUILD_CFG=debug ant' or simply 'ant'
>   BUILD_CFG=release ant

Consistency?  All the other variables that affect the classlib build
are ant properties.  Since you went with the name build_cfg (although I
suggested something specific to the natives) this seemed generic enough
that the value of this property would likely affect the java parts of
the build at a later date.  Classlib doesn't use environment variables
for any of the top-level interface.  (It does use them when it invokes
the native build however it only *sets* environment variables it never
reads them.)

Ant property behaviour is much more well-defined.  Environment variables
are horribly platform dependent.  (If you read back in the archives
you'll find a number of discussions about the problems with the
interface between case-insensitive environment variables on windows and
the case-sensitive properties in ant.)

There is also much more flexibility in ant regarding how properties are
passed down the tree from ant.  This flexibility will be useful when we
have a top-level federation build - that I think should be written using
ant.  (I don't like the use of build.sh and build.bat in drlvm and would
rather use on platform-independent script.  Ant seems like a reasonable

> When we will (possibly) move to 'configure and make' we can do the
> changes in ant build files to keep _this_ interface. For now, this
> interface require 'zero' intrusion into ant build system, as the
> environment variable simply go into makefile.

Great.  The interface I'm suggesting has this useful property as well.

> I do not especially insist in current form, we can do it this way
> either:
>   ant -Dbuild.cfg=release
> I think it is trivial to do, but I just want to understand the
> benifits of this solution.
> If the influence from ant-build-system minimal, people who deals
> with makefiles can just keep in mind the things they want to do in
> makefiles and ignore all of the build layers above. It is much easier.
> As I know humans mind can handle about 7 different types of entities
> at once. Let's keep it simple.

I don't see the relevance of this.  The ant variable will be passed to
the native make/configure as an environment variable so the concepts
that need to be "handled" at that level are exactly the same.  And as
I outlined originally this is exactly the same as the hy.hdk/HY_HDK
variable that developers already "handle".  I've not heard anyone
reporting confusion about this.


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

View raw message