ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laird Nelson" <ljnel...@unix.amherst.edu>
Subject Re: Some thoughts about runtime evaluation of properties
Date Wed, 26 Jul 2000 01:18:56 GMT
----- Original Message -----
From: <donaldp@mad.scientist.com>
> then it could lead to examples such as
> $($($(OS).ARCH).MODE).FLAGS = ....
> which I have scattered through my build files. This is slow
> and prolly way to complex to add to ant

Agreed.  (Incidentally, for others suffering under make, may I *heartily*
endorse Applying RCS and SCCS by Bolinger and Bronson--their TCCS system,
while implemented poorly, is a godsend.)

Here's more food for thought on the subject.  Mutable properties and
runtime-set properties typically "need" to exist because a target (or an
entire buildfile, or an entire project) needs to figure out what its
platform is.  By platform I mean the combination of the following:

*  The operating system.  Less important with java, but some narsty little
things still get you.
*  The "type" of build you're doing.  Is this a "debug" build?  An
"optimized" build?  A "turn everything in the whole world on and set all
integral arguments to 53" build?  A "oh god this better be recoverable"
build?
*  The tools (and what version of them, if appropriate) you're using to do
the build.  It's particularly important to reference them in production
builds *explicitly* so you know exactly what you're getting.
*  The environment and other "mind" settings in effect during the build.  Do
you *really* know what your classpath is?  What about your LD_LIBRARY_PATH?
Just where is ANT_HOME, anyway?
*  .jar and library files you have to load or link against.

For work, I stared hard at the book I just mentioned, and reimplemented
their suggested system using CVS, GNU make and perl.  The best thing that
the silly system does is break the notion of the platform apart from the
notion of the rules and targets that say how to put something together *on*
the platform.  The former is called (surprise) a platform description and
the latter, of course, is the make- or buildfile.  The platform description
is loaded up by the system before the makefiles are run and supplies the
inventory of commands, switches, settings, etc. that the makefile targets
use.

Now you can always implicitly shove the platform description into a make- or
buildfile by (a) either shoving your make variables at the top of some
master makefile somewhere, or, equivalently I suppose in ant, (b) by
embedding lots of properties inside your <project> element.  So I grant that
that is possible today using the tool as it stands.  But I wonder (out loud,
really) if that notion of a platform description can be made any
more...more...*separate* somehow (i.e. something with a few corners on it
instead of being this fuzzy mushball of vague theories).

Again, am I making sense?  :-)  Or am I just rambling?  Well, I know I'm
just rambling, but hopefully there's something in there.  I'm just intrigued
by the idea of using XML tags, which seem perfectly suited to the job, for
creating a...a...file? section? something else? that looks like this:

  <platform name="Solaris Optimized">
    <toolset name="JDK" version="1.2.2" vendor="Sun">
      <tool name="java" universal-flags="">
        <location filepath="/usr/local/bin/java" />
      </tool>
      <tool name="javac" universal-flags="">
        <location filepath="/usr/local/bin/javac" />
      </tool>
    </toolset>
    <property name="whatever" value="something platform specific">
    <tool-configuration name="javac">
      <flag>-deprecation</flag>
      ...etc...
    </tool-configuration>
  </platform>

...and then (ick; the tool-configuraiton element sucks; you'll see what I'm
doing with it in a sec.) your buildfiles' tasks would somehow reference this
platform description instead of embedding the flags and settings and
libraries and all that platform information separately:

  <target name="go">
    <!-- All tasks could get at their platform description or build
context -->
    <!-- automagically -->
    <javac blah blah blah>
  </target>

Blugh.  Does that make sense?  I think I'll work on this and see if it's
feasible.  Discussion/comments encouraged.

Cheers,
Laird


Mime
View raw message