On 7/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
On 10 July 2006 at 19:11, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote:
> On 7/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> >
> > On 10 July 2006 at 16:18, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote:
> > >
> > > 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
> > choice.)
> >
> > > 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.
>
> Yes, but there is an intrusion to ant build system. The property goes
> through some transformations inside ant build system. People should
> look through ant files to know exact flow of variable name.
You gave it a generic name - not just a native specific one - so it is
fair to assume that it might (one day) affect other things. So, yes, it
would be wise to look at what happens in the ant files since it might
affect something else - like the java code. Only if it had a native
specific name would it be reasonable to assume it didn't affect anything
else.
This is equally true whether it is an environment variable or an ant
property.
> > > 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.
>
> Well. There is not a big deal. I can do this in following way:
> If the BUILD_CFG environment variable exists it will be converted to
> ant variable build.cfg.
We don't need the environment variable. Nothing else in the Harmony
classlib uses them - reads them - for reasons I stated previously. I'm
not going to start adding them with no justification.
(Incidentally "because it is used by drlvm" isn't a justification. I
don't think it is a good idea there either but now is not the time for
that discussion.)
> Ant variable can be also set via -Dbuild.cfg=release directive.
> The ant variable will be converted to BUILD_CFG environment variable
> when calling makefile.
This part is ok.
> Does it looks ok for you?
Almost.
Working on it. Not sure I like the way make is called from ant build.
Here is an example:
(from modules/luni/build.xml)
<target name="clean.native" if="is.windows">
<exec failonerror="true"
executable="${make.command}"
dir="${hy.luni.src.main.native}/vmi/${hy.os}">
<env key="HY_HDK" value="${hy.hdk}" />
<arg line="clean" />
</exec>
<exec failonerror="true"
executable="${make.command}"
dir="${hy.luni.src.main.native}/luni/${hy.os}">
<env key="HY_HDK" value="${hy.hdk}" />
<arg line="clean" />
</exec>
<exec failonerror="true"
executable="${make.command}"
dir="${hy.luni.src.main.native}/launcher/${hy.os}">
<env key="HY_HDK" value="${hy.hdk}" />
<arg line="clean" />
</exec>
<exec failonerror="true"
executable="${make.command}"
dir="${hy.luni.src.main.native}/vmls/${hy.os}">
<env key="HY_HDK" value="${hy.hdk}" />
<arg line="clean" />
</exec>
</target>
This means that I should copy paste the environment variable from ant
variable conversion code in dozen of places. BTW, why the clean up is
just windows specific? What about Linux?
I'm going to create some kind of macro command which will include all
common settings for make execution. (/me is reading manuals)
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
