On 7 July 2006 at 2:25, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > 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.
Not sure how this follows from what Gregory wrote. I still think (as Gregory suggested above) if it only affects native code it should include the word native. Or are you going to modify how the corresponding hy.javac.debug flags is derived? Personally, I think the hy.native.cfg variable is more in keeping with the existing variables - e.g. hy.javac.*. If we decide to modify the way hy.javac.debug is setup then perhaps we could use something without native in the name but I think that is out of scope of the current change. > > > > 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. This seems like a separate issue. > > 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) Yes. Gregory's interpretation was accurate. > I will do that as I understood :) Great, but please use variable names in keeping with what is in classlib already unless you want to have the discussion about renaming all of the classlib variables. Personally I'd leave that issue to another day. ;-) Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
