Peter Donald writes:
> Other people are in favor of adding all sorts of
> logic/flow-control operators
> straight into core (or as tasks). This of course would mean
> ant is now
> expressible and extensible but not simple. Considering that a
> lot of build
> scenarios I setup are for less technically orientated people,
It's interesting that you say this. Because the same is true for
me, and has been for the 12 or so years I've been implementing
builds for one thing or another -- developers (whether C, C++,
Java or otherwise) generally consider build automation "beneath"
them (though they could not live without it) and so do not want to
be bothered with the intricacies of *any* build tool, whether it
be make, Ant, or (God forbid) shell scripts. Therefore, to me the
*key* requirement for a build tool is that it supports the construction
of an "infrastructure" which defines a project/company specific
environment of *conceptually simple* constructs that are reusable from
project to project within the company and where a project build file is
a "no brainer" for the developers -- the intelligence is embedded in the
infrastructure, where it can be explained to the small cadre of people who
care or have interest in such things, and where it can be appropriately
grown to meet the evolving needs of the company.
So, here's my problem with all your "template" concepts: they require that
I (and, more importantly, others who will inherit the infrastructure that
I construct, whether it be 6 weeks or 6 years from now) study and understand
yet another tool/language/etc. to do what can be done neatly and cleanly
within
the core of ant in a far simpler manner conceptually.
Let me know if you want examples of what I'm talking about (simple
per-project build files built on a powerful infrastructure) from both the
ant and make worlds.
-Peter
