ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Dabbs <Dda...@Zefer.com>
Subject RE: The RIGHT Direction for ANT (was Re: Problem using script tas k)
Date Tue, 09 Jan 2001 20:49:49 GMT

There is an interesting next-gen config/build/track tools 'proposal' process
going on at
http://software-carpentry.codesourcery.com/entries/second-round/results.html
. There are some good ideas there. Perhaps Ant should be represented there,
too.


David



-----Original Message-----
From: Jerry Huth [mailto:jerry.huth@Sun.COM]
Sent: Tuesday, January 09, 2001 12:57 PM
To: ant-dev@jakarta.apache.org
Subject: The RIGHT Direction for ANT (was Re: Problem using script task)



This discussion about whether or not ANT should have more advanced
features such as templates is amusing because the obvious answer is
that if your software system is so large that you need such advanced
features, then your build system should include both a
dependency-generation program as well as a dependency-reading program.

ANT and MAKE are dependency-reading programs.  They are meant to read
dependency scripts and fire the actions.  They are not meant as
human-written scripting languages for large software systems.
Dependency-generation programs are those that write out the dependency
scripts: they generate the ANT or MAKE build scripts so that humans
don't have to.

As software systems grow in size, the folly of trying to use the
dependency scripts to define your whole software build system becomes
more and more apparent.  No matter how many advanced features you add
to your dependency-reading program, you will always be able to build
large software systems easier using a dependency-generation program in
combination with the dependency-reading program.  

In fact, the only reason to add advanced features to ANT or MAKE is to
allow them to be used (however awkwardly) for medium-sized software
projects.  For large software projects it is clear that using the two
programs in combination is infinitely easier than trying to build the
whole system with only a dependency-reading program.  Indeed, MAKE
has become exorbitantly bloated with "advanced" features over the
years, but still it is completely inadequate for large software
systems unless it is used in combination with a dependency-generation
program.

Mathematically the reason why using the two programs together is
easier is that the dependency-generation program requires only
Constant time effort (it is not dependent on the size of the software
system being built), whereas dependency scripts always require at
least some O(n) effort (n is the number of lines of source code being
built).  Furthermore, using a dependency-generation program allows you
to minimize the O(n) effort by putting the "smarts" of the build
system in the dependency-generation program, thus allowing the O(n)
scripts to be reduced to their smallest possible size.  Indeed, when
used with a good dependency-generation program, the O(n) effort is so
small that it is easily handled by the source code developers
themselves.

Theoretically if a software system is "sufficiently uniform" than a
feature as simple as templates could allow ANT or MAKE to be used
without a dependency-generation program; but of course as software
systems grow in size, their degree of uniformity inevitably lessens
due to the increasing need for automation and other advanced build
features, so there is always a point at which the use of a separate
dependency-generation program is easier.

Ultimately, software build systems should provide the most advanced
build features to the end-user (the software developer) while reducing
the O(n) build script maintainence effort to its minimal value.  And
this is precisely why using the two programs in combination is so
effective: coding the advanced features of a build system in the
Constant-time part (the dependency-generation program) will always
require less effort than coding them in the O(n) part (the dependency
scripts).

What this means for the future direction of ANT is that we shouldn't
repeat the mistakes of MAKE by continuing to pile on more and more
features of dubious usefullness.  Instead we should focus our efforts
on providing an ANT file generator that is sufficiently general to be
useful to the software community at large.

The irony of using a dependency-generator program is that when you
have one you only need very basic features in the dependency-reading
program.  ANT doesn't need any more features, it needs a companion ANT
file generator program!

---

Jerry Huth
Sun Microsystems
(650) 786-4658
jerry.huth@sun.com



-------------------------------------------------------------------------
Jason Rosenberg wrote:
> 
> > On 1/6/01 9:40 PM, "Jason Rosenberg" <jason@squaretrade.com> wrote:
> >
> > > Ant is procedural, and that is what I want.  It is close to being
useful,
> > > to date, but just needs to add a very small set of features to close
the
> > > case.  Simply admitting that it is procedural would really clear the
way.
> > > Let's stop beating around the bush.
> >
> > Nope. Let's not. There are things that Ant needs. IMHO, turning into
> > something procedural isn't one of them. I'd rather just write my
> > buildscripts in JavaScript if that were the case.
> >
> 
> Well, I got into this debate because I wanted to have reusable templates
> which are applied across a large set of like modules, etc.  And, as we
have
> seen, Ant 1.2 is still not adequate in terms of templating, etc.  So, this
> leaves us with having to use JavaScript, via the script task, if we want
> to have any sort of elegance with Ant.  So, for now, not only are you
> right in saying that if you want to do anything procedural, you should
> use JavaScript, you also need to add that you really end up doing
> everything in JavaScript anyway, even when you are using Ant.
> 
> > I come down to the opinion that calling something data or code is pretty
> > tough. After all, software is just data at some point. :) However there
is a
> > visceral line drawn about what Ant is good for, and at what point it's
not.
> > That line has been labeled with the somewhat, but sort of useful terms
of
> > "procedural vs. declarative". Neither term is totally appropriate. But
we
> > use them anyway :)
> >
> 
> Ant is a build management tool.  It's purpose is to build software.  This
> means doing things like javac and javadoc and copy and ejbjar, etc.
> These are all procedural tasks.  If you want to be able to represent
> a software build module declaratively, then you need to be able
> to define it as a data object, with attributes which define how to
> build it.  In order to do this constructively, you simply have to have
> templates or sub-routines, etc.
> 
> > > Yes, I think the beauty of Ant is that it has the power to keep
> > > things simple and human readable.  I like the <execute-task>
> > > idea mentioned by someone on another topic, or possibly a
> > > simple case:
> > >
> > > <case property="caseProperty">
> > >   <if value="1" execute="doMainCompile"/>
> > >   <if value="2" execute="doPartialBuild"/>
> > >   <default execute="showErrorAndFaile"/>
> > > </case>
> >
> > But here you are saying you want a "if" target implementation that could
> > take any set of attributes and do something. "<execute-target>" only
does
> > just that. It's a difference. And, imho, it's a big one.
> >
> 
> I don't understand what you said here.

---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org

Mime
View raw message