ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Uther <wi...@cs.cmu.edu>
Subject Re: What flavour of scripting?
Date Tue, 29 Feb 2000 19:32:42 GMT
I think discussing Sam Rudy's last mail is going to be more fruitful than
continuing this line, but there are some thing in here I wanted to respond
to.  Feel free to ignore :).


Stefano Mazzocchi wrote:

> Now: if you don't like the solution and have something better... great.
> I asked before doing it and nobody answered.

The "if" attribute seems like a fine short-term solution.  It feels rather
ad-hoc for a long-term solution though.

At the moment "if" is an existance test.  If you're going to conditionally
compile on the OS, then you're going to want some sort of equality test.
You could copy the idea of <available /> and make a new task:

 <equal left="${OS}" right="Win*" property="WindowsOS" />

which sets the associated property if the equality holds.  I think I'd
prefer the equality in the 'if' though.

> But Costin is right: there is a big difference between <switch> or <if>
> and the attribute if="": elements define tasks, tasks SHOULD NOT be
> programming tokens. Attributes are what the word says: the attribute
> some behavior to the task that includes them.

Tasks are already programming tokens.  They are java functions that are
executed in listed order within a target.  I don't know how much more
procedural/programming token-ish you can get.  Now, you can argue that they
tags shouldn't have procedural control logic in them.  In an ideal world
I'd agree with you.  I haven't seen a solution I prefer yet.

> We could use the ant: namespaces for programmatic attributes something
> like
> 
>  <task ant:if="...">
> 
> or simply don't care and do like Sam's proposal:
> 
>  <task unless="...">

I think it would be bad if this required changing every task.  If you
implement it so default behaviour is in the Task class and is inherited by
all tasks that would be ok.

If the "if" becomes more complex then the namespace would be useful for
separating various arguments:

 <task taskArg="Huey" includes="Dewey" excludes="Louey" if:property="OS"
if:value="Win*" />

although I have a hard time seeing why you prefer that to:

 <if property="OS" value="Win*">
	<task taskArg="Huey" includes="Dewey" excludes="Louey" />
 </if>

>> Why do you see this [xml-make] as bad?  What are the symptoms of it
>> "being the monster it is today"?
>
> When you can't create your makefile by examples. This is the ultimate
> definition of a monster language. This is also why I don't like hidden
> things (like the hidden call to the init task): you can't tell without
> reading the docs.

I agree.  I don't think adding <switch> or <if> would have this effect.  I
DO think this is a strong argument for fixing the semantics of properties
:).

(I also believe the tag-if is much more understandable than the
argument-if.)

> Do you understand why HTML was such a powerful language? How long did it
> took you to write your first HTML page by looking at somebody else's? 10
> seconds?

And I would argue that was largely because A) HTML is not symbol soup.  It
was designed to be relativly verbose.  And, B) the task was simple.  I
wasn't trying to make web page that did anything conditional.

> How long did it took you to write your first makefile after looking at
> somebody else's? much longer.

Yes.  Mainly because I had to look up what the symbols meant.  And because
the syntax wasn't as clean.

> The final goal: provide enough flexibility inside Ant to do everything
> that is required inside the apache projects. If we can match that
> building complexity, everything else is plain simple.
> 
> But the constraint is: one should be able to clone their build file from
> mine in less than 10 minutes and possibly without looking at the
> documentation. If this is not possible, we did a mistake, but if we use
> this as our quality meter, we can go back and fix this.
> 
> Usability is a feature. Lack of usability is a bug. It's about time to
> enforce this with every possible mean and I know that almost all the
> people on this project have my same vision.

I agree too :).

>> I've already posted my pet peeves with make: Symbol soup,
>> non-cross-platform, non-guiable.
> 
> Yes, these are part of the problem, but not the problem itself. Ant is
> using the same exact simbols that make is using

If Ant ever starts using symbols like:

%.class : %.java
	javac $^

Then it will certainly have become a "monster language".  Luckily it
doesn't.  So I would argue that Ant is NOT using the same symbols Make is
using.  It is using XML tags.

> and make is probably
> more cross platform than ant (gnu tools have been ported to all existing
> operating systems, this is not the case for java).

Oh please.  GNU tools have been ported to Windows and Unix.  I know of no
non-command-line system that has a decent set of GNU tools.  JVM's have
been ported to more platforms than make. (counting 'unix' as a platform)

>> How is this for a suggestion:  we have a task that calls BeanShell

> This is better, but adds unnecessary (IMO) complexity to the build file.
> 
> Remember, I should be able to clone your build file without looking at
> docs. If I don't know your scripting language, this is not possible.

I tend to agree.  I am just throwing out ideas trying to find a solution we
haven't considered yet.

David Bullock's two build-file concept is something that we already have
(in some sense).  You use .java and .XML files to build a project.
Scripting Ant by writing tasks is a little heavyweight for some
applications though.

later,

\x/ill             :-}


Mime
View raw message