On 7/7/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Friday 07 July 2006 01:28 Ivan Volosyuk wrote:
> > I'm happy with release and debug but the top-level interface (and
> > the module-level interface too for that matter) is ant - make should
> > not be called directly - so it will probably need to be an ant property.
> >
> > I was thinking:
> >
> > 1) adding a 'hy.native.cfg' property to make/properties.xml
>
> 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.
The names are not important, they could be changed in drlvm build as well if
we find those that most of us like. I think word native is ok or there may be
a confusion that the same rule applies to java sources (this of course
depends on what hy.native.cfg, be it compilation flags, then it should not
apply to java, or just debug/release, then it is ok for java).
Well, I will stick to corresponding names from drlvm then. Somebody
who will commit the changes can rename both of them if needed.
> > 3) adding !if/ifeq directives in defines.mak and makefile.include to
> > define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags
> > for debug/optimisation.
>
> I would also like to have CFLAGS and LDFLAGS to be used in the
> defines.mak. People can set corresponding environment variables for
> extra compiler switches they want.
I think that #4 covers this.
> > 4) breaking up the existing flags variables and defining them in terms
> > of separate defines for different types of flags CFG flags, warning
> > flags, etc.
>
> Could you reformulate this, I think I not quite catch the idea.
This is something that I was thinking about, separate groups of flags for
debug info control, optimization flags, warning level and just user
additional flags (which should probably go the last to take the precedence).
(hopefully I clarified this paragraph correctly for Ivan from how I understood
it myself)
I will do that as I understood :)
+1 for #1, #2, #3 and #4 in my interpretation.
--
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]
