On 7/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
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.
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.
> 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. 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. Does it looks ok for you? -- Ivan --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
