On 10 July 2006 at 16:18, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > > On 7/9/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= <thunde > [EMAIL PROTECTED]> 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 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. > 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. 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]
