ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: Can someone tell me what is so great about Ant?
Date Wed, 07 Feb 2001 06:59:04 GMT
Well said Tim!  I agree completely.  As a CM, build engineering has
been a key part of my responsibilities for quite a while.  With GNUmake
I have written a single engine makefile (~ 1000 lines) that was used
by all makefiles in the project.  Each makefile in the project averages
to less than 10 lines and is capable of building (depending on command 
line choices) for over 30 different target environments:
	real hardware
	simulated hardware (cycle-accurate sim)
	simulated hardware (fast sim)
	simulated VM (replacing real HW calls with library calls, building
		a win32 executable instead of an executable for the real HW)
	
	windows
	linux
	mac
	
	debug or release for all of the above

	Visual C++ 4, 5, or 6

	Eval/Release


Ant doesn't come anywhere near this kind of power.  On the other hand,
most java projects don't need this sort of power.  But I think it is
very important to understand that make gets a bad rap from a lot of
people who really have no idea how to abstract a build.

Also, if one avoids recursive make (one of the most common "make" 
blunders) GNUmake is blindingly fast (< 2 seconds to determine that
a build involving over 100 directories doesn't need to rebuild anything
on a PIII 500MHz) and otherwise just compile speed (typically process
start time is in the noise relative to actual compile time).

It really comes down to this:

In make, one writes key abstractions into a central makefile which is then
used by client makefiles which are typically quite small, and describe only
what the end target(s) are, and detail the files (usually via wildcards)
that belong to the build.  The central makefile handles generation of 
dependency information, etc.  The language of "task" abstraction for make
is make and shell (and PERL on occasion).  The core functionality is not 
optimized for any language in particular, and make often makes developers
uncomfortable because it is unlike most languages (other than, perhaps, 
PROLOG) and therefore carries its own learning curve.  Make's performance
suffers in comparison to many other build tools due to the large number
of process starts involved in the typical build.

In Ant, one writes key abstractions into a series of java classes that 
implement "tasks" which are utilized by the overall build.  These classes
handle generation of dependencies, compiles, etc.  The language of "task"
abstraction for ant is Java.  The core functionality implements the bare
basics needed for Java-based projects, and the whole system is very
appealing
to developers of Java/Web-based projects because it works within the same
framework (Java/XML) that those developers use daily.  A downside is that
the extensions to Ant that are project specific must be recompiled and 
ant restarted to re-load those extensions.

In CONS, one writes key abstractions into PERL functions and/or packages
that implement "tasks" which are utilized by the overall build.  The core
functionality implements the basics needed for C/C++, but it can easily be
extended to support other languages (like Java).  Many developers who are
familiar with Perl like CONS because it is easily extended via perl, but
those who are not familiar with perl eye cons with almost the same suspicion
as make.  Extensions to CONS that are project-specific can be loaded
dynamically
and do not need to be recompiled prior to proceeding with the project build.
Because almost everything is done in perl, other than calls to the compiler,
etc.
it shares many of the same performance advantages over make as Ant.  A key
benefit
to CONS is it's use of MD5 to sign each derived object to determine
accurately
if ANYTHING that should cause a rebuild (compiler options, compiler version,
include files, etc.) might have changed.

In other words, the "right" choice depends a lot on the complexity of the
project
itself and whether or not the project has CM/Build Engineer resources
responsible
for ensuring a consistent, reproducible build, etc.  Ant, Make, and CONS all
have
their place in the grand scheme of things...  

I look forward to Ant2, I think it has a lot of potential, as long as the
attitude
of distaste complexity is tempered with an understanding that advanced
functionality
occasionally introduces complexity.  The key being that the complexity can
be avoided
if the build situation does not require it...

-Peter
--
Peter A. Vogel
Manager, Configuration Management
Arsin Corporation
4800 Great America Parkway Suite 425, Santa Clara, CA 95054


	

> -----Original Message-----
> From: Tim Vernum [mailto:Tim.Vernum@macquarie.com.au]
> Sent: Tuesday, February 06, 2001 5:59 PM
> To: 'ANT-user'
> Subject: RE: Can someone tell me what is so great about Ant?
> 
> 
> > Let me get this straight. Complex ant files are ... complex 
> ... as are
> > complex makefiles. Not such a great point. Simple makefiles 
> > are ... simple.
> ine
> OK, so it's not rocket-science, but I thought it needed to be said.
> I'll explain below
> 
> > Well .. yer ... but how many simple Makefiles are actually 
> > useful.
> 
> Mine are.
> It depends on what you consider to be a "makefile"
> 
> I have a make-engine that is a makfile included within
>  each project's makefile. It basically gives you a lot of
>  what ant gives. (Not all, but a lot)
> In Ant the logic is in the tasks, written in java.
> In make the logic is in my "engine" makefile.
> It's rare for me to touch that file, and it only happens 
>  when I need to define, what to ant would be a custom
>  "task".
> 
> > Compare
> > the average makefile to compile and jar some classes vs 
> > average build file.
> > Makefile is a tad larger/more complex.
> 
> I'll take the time to write both later and see, but your
>  conclusion doesn't seem obvious to me at the moment.
> 
> > Arguements like -  complex build
> > processes are complex hence your build tool is irrelevent if 
> > you aim for simplicty is somewhat foolish, no?
> 
> That's not what I said/meant.
> What I mean is:
>  * Simple makefiles are not (IMO) hard to understand.
>  * Complex makefiles are hard to understand.
>  * Simple build files are not hard to understand.
>  * Complex build files are hard to understand.
> 
> I get the impression that people are comparing Simple-Ant
>  to Complex-Make.
> That is partly a result of the tools - ant does encourage
>  simple files, and make does encourage complex files,
>  but I don't think "ant files are easier to read" is universally
>  true.
> 
> > Then you argue that you believe there
> > should be a build engineer/process manager ...
> 
> Yes. 100%.
> But it's not (just) to maintain the build files.
> It's to guarantee the integrity of the final product.
> They need to have a good understanding of the build 
>  tools, but I don't think joe-coders does.
> 
> > The main advantages with ant is that it only
> > executes most tools once and if the tool is java based it 
> > usually executes
> > it in VM rather than creating a new VM (which is costly).
> 
> That is true.
> What I was thinking of is the trivial case of recompiling
>  only a small number of files.
> The overhead of make is in my experience smaller for
>  that than ant, and you would have to be compiling quite
>  a number of files to regain that time for ant.
> 
> For a full rebuild of a medium to large project, I would
>  expect Ant to win quite convincingly.
> 
> Hmm, I wonder if I could hack make to run everything
>  in one command...
> 
> > >> 5. Lot of custom tasks for Java related tasks such as jar, 
> > >> war, ear, javadoc,
> > >>    and a lot more. See
> > >>    http://jakarta.apache.org/ant/jakarta-ant/docs/
> > >>    for a list of all the Ant tasks.
> > >
> > >Which is just as easy in make.
> > 
> > not really.
> 
> I was thinking of writing shell scripts to handle the tasks.
> Anything that you can write a java task to do, you could
>  write a shell script to do (even if that script ran java).
> While ant is extended with java classes, make is extended
>  with shell commands.
> 
> > >Writing makefiles that work is a complicated process, but I 
> > don't find
> > > that writing ant files is much easier.
> > 
> > I would actually say that writing complex several project ant 
> > files is more
> > difficult in ant than it is in make. Hopefully this will 
> > change in Ant2.0
> > though. Not sure.
> 
> I have high hopes for Ant2.
> For the record, I like Ant better than make, but I do find make
>  more powerful, and I think it gets a bad rap, because there's
>  so many bad makefiles out there.
> 
>  
> 

Mime
View raw message