ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@mad.scientist.com>
Subject Re: Why Properties became immutable
Date Tue, 25 Jul 2000 14:14:53 GMT
At 09:38  25/7/00 -0400, you wrote:
>And that's what I'm saying I personally don't want to see Ant become - so
>declarative that you don't know what you're getting.

The point with ant is you always know what you are getting becuase the
dependancy rules are always explicit. 

>Yes, Ant is pretty easy to read today.  But step back and think about it
>honestly.  There is a lot of power in tasks to perform common things - like
>compiling an entire source tree at once.  I like that quite a bit.  But the
>expressiveness of the build.xml file is still that of very simple makefiles.
>If I put together makefiles at this level, with only explicit targets,
>dependencies and commands, I guarantee that anyone could read them just as
>easily as Ant files.  (No slights intended guys, I *do* use it after all.)
 But
>neither is efficient to create or maintain for big systems.

not really - how could you include all the functionality of some these
tasks (namely javac) in make and still keep it simple ? Damn near
impossible I would say....

>The taskdef extension mechanism is a beautiful innovation, but lets face it,
>it's not for everyone.  I sincerely doubt you are going to see build novices
>creating their own taskdefs.  And what a mess we would have if they did....

you would be surprised. I found peeps doing just that after I explained
philosophy of Ant to them :P

>You can rest easy - I'm not a committer.  I don't write the Ant code.  But
I do
>use it every day to run production builds and I do have cases that it cannot
>handle cleanly.  The "solutions" we're seeing here on the list involve
>scripting languages, XSLT, sub-builds, etc.  All ugly, ugly, ugly.  And all
>leading to the sort of complex build *systems* you're complaining about in
>make.

I agree there needs to be something like this. I maintain about 6-7
build.xml files - all reaching close to 800 lines region with some files
having excessive number of targets and others with an excessive number of
tasks. Most of these files are very very similar and it seems wasteful.
Compare this to my top level makefiles that look something like

#include rules.mk

###########################################################################
# Java libraries
###########################################################################

JAVA.DESCRIPTION       = Java libraries
JAVA.DEPEND            =
JAVA.JAVA              = $(wildcard $(JAVADIR)/*/*.java
$(JAVADIR)/*/*/*.java $(
JAVADIR)/*/*/*/*.java )
JAVA.CLASSPATH.EXTRA   =
/usr/local/jars/xerces.jar:/usr/local/bml-2.4/lib/bmlal
l.jar:/home/donaldp/junit/test.jar:/home/donaldp/log4j/log4j-v0.8.4d/log4j.jar

###########################################################################
# Scripting Support library
###########################################################################

SCRIPT.TYPE          = exe
SCRIPT.NAME          = script
SCRIPT.DESCRIPTION   = Scripting Support library
SCRIPT.DEPEND        =
SCRIPT.DEFINES       = -DSCRIPTAPI=EXPORT
SCRIPT.SRC           = $(wildcard $(SRCDIR)/script/*.cpp )
SCRIPT.LIB.EXTRA     =

###########################################################################
# Cross Platform library
###########################################################################

XP.NAME              = xp
XP.DESCRIPTION       = Cross Platform Services
XP.DEPEND            =
XP.DEFINES           = -DXPAPI=EXPORT
XP.SRC               = $(wildcard $(SRCDIR)/sys/$(OS)/xp*.cpp )
XP.LIB.EXTRA         = $(LIB.XPSHLIB)

etc...

This kind of simplity is great and I guess is what you are aiming for. It
will never ever become that easy in Ant thou and I thank good for that (Or
at least I would if I believed in him :P). The reason is giving enough
power to do the above will lead people off the straight and narrow. I would
much much much rather see a tool ontop of that that used some form of
template build files plus parameters to build a build.xml. Ant should do
one thing and do it well. This other task of iteration/looping/nested
property expansion etc would be needed but add so much complexity Ant
became make in xml.

>I like Ant quite a bit, which is precisely why I feel the need to argue my
>points.  I want to see it become even more powerful than it is today - but
not
>more complicated.  And my opinion - and that's all it is - is that by stating
>it should be 100% declarative, you're aiming at creating complexity in
order to
>gain power.

Well feel free to give a sample XSLT or <insert favourite
templating/procedural language> and perhaps that could form basis of the
meta-Ant however don't count on it becoming part of Ant. There has been a
number of requests to do this so if you feel up to the job go for it :P It
may result in something more widely used than even ant :P



Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Mime
View raw message