ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <rvau...@seaconinc.com>
Subject Re: Why Properties became immutable
Date Fri, 21 Jul 2000 14:08:11 GMT
Peter Donald wrote:

> Well I am going to go out ona limb and say yes - you can do all those
> things you say - I personally use the scripting way in my projects. However
> it is very non-intuitive. Fairly complex and takes a lot to grok - very
> un-Ant like.
>
> ...
> err - it loads the whole set of bf and js jars. - May be insignificant in
> long run but an extra second to do something that IMHO should be done in
> ant is annoying. It also means build files can get complex to read as
> everyone usues own fav scripting language (I use python and javascript -
> someone else may use tcl and xslt - neither of us can easily understand
> each others build files. We have also added dependancies to build process
> and opened a whole kettle of fish that can lead you down the road to make -
> "the road to make is littered with good intentions" :)

I completely agree.  This is *possible* and solves the immediate problem, but
only by introducing bigger ones.  Again, I believe the goal of Ant should be to
simply the build process.  The scripting solution introduces the need to know not
only the Ant syntax, but a whole other scripting language, as well as typical
usage patterns for both.  In terms of initial learning and maintainability, it's
a nightmare.

My *real* problem is that of repeated build patterns, which are extremely common
as we all know.  This sort of thing led to the development of implicit rules and
many other features in Make, but we as yet have no analogue in Ant.  Yet, I spent
*years* (as did others, I'm sure) fighting Make to produce more complex
pattern-based builds.  Anything more complex than "this source file becomes this
object file like this" took a lot of work, and often ended up impossible without
recursive builds.  If we managed to get complex-pattern rules into Ant, we'd have
a complete coup - as least in the Java-build world.

The sub-builds approach is more "correct" than scripting, but still requires too
much usage-pattern knowledge.  I'm also concerned about the extra memory this
approach takes - particularly in big projects where it is needed most.  I'm
already running out of memory with big single-level builds.

I'm tending more towards the suggestion of a two-stage XSLT-processed build file
very similar to the Imake process.  IOW, you would have a build description file
(similar to the Imakefile) and a set of pattern templates (similar to the Imake
templates) which produce the Ant build.xml in an automated step.  I actually use
(believe it or not) very simple Makefiles to drive Ant, so this would integrate
very easily into my process.

The advantages to this approach are:
1) It requires no changes to Ant.
2) It works in only one syntax - XML.
3) It gives you the full power of XSLT expressions to accomplish very complicated
things with less work.
4) It adds no performance penalties to Ant, as it is completely unchanged.

The disadvantages are:
1) The two stage build is somewhat harder to maintain.
2) The builds will be more difficult to construct up front (but later builds will
be easier if the template file is reusable).

One of the major problems with Make was that it required years of learning usage
patterns to make it do anything complex or efficient.  Beginners could get the
basics, but it really takes experts to get it to go.  In my opinion, we should
endeavor to make the full power of Ant available to beginners as well as experts
-- which means that complex constructs have to be expressed *in* Ant, rather than
through scripts or XSLT templates.

BTW, for its own reasons, I'm still fond of the idea of scoped properties.  As
well as answering the original problem in this discussion, it would also solve
the problem of sub-builds changing the properties of their parent builds.  I
understand the problem that properties are substituted at parse time.  However, I
am all for changing this to run-time substitution.  Why?  Because it's *much*
more intuitive.  It behaves like procedural code, which we all work with every
day.  It's easier for beginners to learn, and easier for experts to work with.
According to Stephan's description, we never need to include our "init" targets
as dependencies, because they never actually "run".  Just the presence of the
properties makes the rest of the file work, since they're substituted at parse
time anyway.  I don't know about you guys, but this isn't at all intuitive to me.

Run-time substitution is also much more flexible.  I'd gladly trade a little
speed for that flexibility.  Parse time macro substitution was one of Make's
biggest problem areas - one which GNU only partially solved with run-time macros.

roger



Mime
View raw message