Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-ID: <20010516170711.34675.qmail@web9304.mail.yahoo.com>
Date: Wed, 16 May 2001 10:07:11 -0700 (PDT)
From: Roger Vaughn <rogervaughn@yahoo.com>
Reply-To: rvaughn@pobox.com
Subject: RE: if and unless attributes for all Tasks
To: ant-dev@jakarta.apache.org
In-Reply-To: <3.0.6.32.20010517005618.01ed6b70@mail.alphalink.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Peter Donald <donaldp@apache.org> wrote:
> Look to any good design principle in anything from
> building bridges to
> software design. And they all emphasize one thing -
> monolithic designs
> where implementors need to know all aspects of task
> are impossible to
> maintain. Think modular - think maintainable. 

I never said a single thing about abandoning
modularity.  Explain to me how conditionals require
losing modularity.  If you will recall, I did in fact
propose an (albeit off-the-wall) solution that was
entirely modular.  Even ifs-on-all-tasks can be made
modular if you embrace a decorator-pattern approach.

> >deal with, and in the end make it harder for the
> build
> >scripter to understand the system as a whole.  
> 
> this is false.

Pretty bold statement there, Peter.  I'm glad you're
the authority on this.  Perhaps you can explain why
most people I encounter don't understand build
scripting at all - in Ant *or* make.

> You see the absurdity of that arguement - it is the
> same as the one you are
> offering ;)

Ah, yes, I love it when people take sane discussions
and drive them to extremeism.

> Why do people choose ant over make? If you want all
> this then I suggest
> using make or more likely a python/javascript script
> with a few "modules"
> defined.

I'll tell you why - it has nothing to do with
scripting or "tabs before commands".  It has
everything to do with the javac task.  This one task
simplifies the Java dependency checking that is nearly
impossible to do in make (unless you want to write a
rule for every Java file in your system.)

> I am not sure you understand the situation quite
> correctly. Everything that

No, of course I don't.  I'm just an idiot.  I've just
been bumbling my way around build systems for over 15
years.

> Actually you are the one who is proposing to follow
> in makes path. You want
> us to integrate everything into one tool. This will
> force all our users to
> deal with the complexity and eventually tools will
> be built to reduce the
> complexity (enter auto-*). Before too long there
> will be little reason to
> use Ant because it would just be a java version of
> make - and makes been
> around for ever - so why not use that.

This is the one outrageous claim you guys keep making
that your arrogance won't let you see through.  Which
make tool is the most popular?  Vanilla make?  Nmake? 
or GNU make?  From what I can see the answer is GNU
make - because it gives the developer more features
and thus more power.

And by the way, I do in fact still use make for C
builds - I tried this in Ant and it just isn't up to
the task.  (Not cleanly, anyway.)

> Tool chains are layered for a purpose - I suggest
> you look carefully at the
> reasons because you seem to have some funny
> opinions.

Well, I guess if asking a build tool to fulfill its
charter and actually perform a complete system build
is asking too much, then yeah, I guess I do have some
funny opinions.

If you will recall, I pushed heavily for XSLT
preprocessing of Ant scripts months ago, but got
shouted down for it then, too.

Damned if you do, damned if you don't.  I'm outta
here.


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/