ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
Date Tue, 19 Dec 2000 01:11:59 GMT
At 04:06  18/12/00 -0800, Peter Vogel wrote:
>Good response Peter!  Some comments below...
;)

>> From: Peter Donald [mailto:donaldp@apache.org]
>> At 01:02  18/12/00 -0800, Peter Vogel wrote:
>> >I wonder, how many of the current ant developers have looked 
>> at "other"
>> >alternative build tools (by alternative, I mean non-"make" 
>> based) like
>> >CONS, etc.?
>> 
>> Not me ;) I may have to go do a search on google when I get 
>> some time thou ;)
>
>I'll save you some time: www.dsmit.com/cons/ 

thanks.

>> >it's also pretty Java-focused.  CONS
>> >is very powerful with the full expressive power of PERL, built-in and
>> 
>> you have to remember that Ant has deliberately sacraficed 
>> power in some
>> places to make it simple and easy to use. We still haven't 
>> found the exact
>> balance between power/ease/expressability but we try. Many of 
>> the things in
>> make (and I guess CONS ???) would never make it into ant as 
>> it is too complex.
>
>At times, it requires complexity to support a complex project :-)  I think
>the key, really, is to have a simple project have a simple build.xml file,
>and
>a complex project will necessarily require a more complex set of features.  
>To sacrifice functionality to KISS is not a long-term strategy for success!
>Projects tend to grow, organically, both in terms of size and complexity,
>the 
>build environment needs to support that growth.

true. Over time Ant will/has grown. I think we would like to control it for
as long as possible thou just to make sure we don't make any mistakes and
don't end up with just another make (but in java + xml). For the moment I
think we can push as much complexity as we can into tasks but keep core clean.

There is one thing that we can't do in a reasonable manner with ant1.0 (at
least at the moment). Something like

<target name="foo" depends"foo2" if="blah" />
<target name="foo2" if="blee" />

Currently if we only wanted to run foo2 if we were going to foo then we
would have to have some complex scripting before hand to make sure that if
blah is not defined then blee is not defined.

In the mymidon proposal <ant-call/> actually operates in current context
and without undue overhead so you could do something like

<target name="foo-runner" depends"blah">
  <ant-call target="foo"/>
</target>

<target name="foo" depends"foo2"/>
<target name="foo2" if="blee" />

to get around it. This keeps ants concepts simple but I think gives
everything we need to do what we want. Complex interdependencies between
properties are still an issue we have to resolve thou. ie rules like

if( a & B & ~C ) then d=false, e = true
else f ="meep, meep"

are near impossible to do without scripting at the moment - we have to
check how often these sorts of things arise thou.

>> >Support for detailed dependency checking, including 
>> "non-traditional" 
>> >dependencies such as which compiler is in use now vs. the last time 
>> >a compile was done in the tree.   
>> 
>> Okay - I think these should be placed in tasks rather than in core.
>> Delicate spiderwebs of dependencies that make builds are 
>> unacceptable - I
>> much prefer simplity of if/unless + tasks to set properties.
>
>No spiderwebs implied!  I was thinking in terms of CONS' (and several
>proprietary make-based tools') use of MD5 checksums on the files 
>and options involved in a build step to ensure that a change in something
>propagates appropriately through the tree.  (For example, if a library 
>changes, ensure that anything that links with that lib is re-linked).

kewl. I guess that means extra support classes to build tasks with which is
something we have decided we need.

>> >Support for building from anywhere in the tree, updating only what
>> >is necessary to build at that level and below.
>> 
>> Not sure I agree. I think I prefer AntFarms idea of small 
>> reusable project
>> files that depend on other projects is a better model. 
>> Directory sub-builds
>> is just make et als poor attempt to do the same. Make assumes that
>> sub-directories assume sub-components which is not always 
>> case especially
>> in some languages (ie java ;]).
>
>I didn't mean to imply a make-based concept here.  It's just that if you
>watch a developer work (especially when they aren't working within an IDE,
>you will see them change some files, rebuild, test, etc. if they have to CD
>to a top level (or switch terminal windows) in order to rebuild, it's an 
>interruption to the "flow".   

agreed they should convert to emacs instead ;) or alternatively just use
the -find flag ;)

>So, if one implements the concept of an upward
>search for build.xml you're half-way there, then add the idea that if
>they are in the directory foo/bar/baz then they want to rebuild starting
>from the target foo.bar.baz (obviously checking dependencies, etc.) until a
>particular set of "goal" targets are completed, you have the right idea...

okay - this is appriate in some environments (ie c/c++) but is it a general
thing. I am not sure - when I want to test something I just run the whole
build process. I may be exceptional thou - I did spend a bit of time making
that onl appropriate tasks a run in my build files thou. Not sure - this
would need more discussion. If we broke down project idea more it would be
irrelevent IMHO but not sure.


>> I agree - essentially in Ant2.0 from what I understand the 
>> main build file
>> will be in the "ant" namespace and anyone can tack anything 
>> on in other
>> namespaces.
>
>I just wonder about the need to add the complexity of namespaces here...

reliability. The reason I use java over C++ is that java is more strongly
typed an will tell me (and possibly block me) if I am doing something
stupid. I like jikes even more on pedantic mode as it picks up a lot more
stylistic nits. Using namespaces makes buildfiles much more reliable. If a
build file is broken it won't work - fail hard and fail fast is my moto ;)
- much preferred than possibility of loose interpretations.

>The key here is for certain "standard and consistent" property value sets 
>to be available as named configurations, including the destination directory
>names, etc.  One of the nightmares of CM is the version of a build from
>an engineer's machine that "works for me" but the official CM-build version
>of the build fails in some way or another.  Sources are identical, what else
>changed?  By ensureing that there are known, understood, controlled
>configurations

right. At one stage I started writing up a doc that took the best build
process from Apache and formalized it (basically a cross between turbine
and cocoon build processes) but I never got around to finishing it ;(. We
could discuss and develope one of these standards docs and combined with
CJAN could provide a consistent and simple build process hopefully across
many build environments.

>> anything that can be programmed via a task(let) - sure.
>
>I guess this is where there is some philosophical difference: one should
>not have to program an extension to the build tool for every command one
>might need.  Otherwise, you run into a problem of extensions that do
>*almost*
>the same thing, etc.  CM nightmare!

right - however I don't think it is yet time to formalize this. Good takss
naturally generalize and bubble to top. It would be better if the ant-dev
team was just there to scoop them up at right time rather than try to
formalize/institutionalize everything now - we may end up being wrong ;)
>> What you are talking about here (templated build files) has 
>> been discussed.
>> While it is possible it is not something we will directly 
>> support (because
>> of added complexity). What I want to do is do templates via 
>> template file +
>> xslt --> build.xml. Not sure on viability yet.
>
>Again, don't fear complexity!  Just make sure that one needs to get
>complex only when one needs the functionality!  

right. It is more a steady as she goes kinda thing. We don't want to
introduce an error that is incredibly complex and impossible to revert ;)
>> The only thing you have to realize is that Ant is not meant to be a
>> cure-all it is waaaay to early in development to try to do that yet.
>
>I have to ask myself: Why build a build tool if it cannot meet the 
>needs of real projects?    Even if you don't implement features immediately,
>the tool must be *designed* to grow toward a powerful build tool that meets
>the needs of complex projects.

the beaty of it is that you can do almost anything - however through tasks
rather than ant-constructs. Hopefully Ant2 will provide ability for
end-users to replace bits they don't like - ie grab build file via
xslt/css/from a database/whatever and build it using extended versions of
Task/Target/Project objects (that have things like property veto/listener
support etc). When the best bits see use we may integrate back in the bits
that seem to be most widely accepted. Hard to tell now. At least thats my
vision - Myrmidon doesn't quite yet make it but it will eventually ;)

>> Simplicty and usability are key requirements unlike other 
>> build tools that often require a make wizard/CM to understand.
>
>Again, to the philosophical:  I can write a simple make file for a simple
>project, and it takes no wizard to understand what I did.  But if I have
>a complex project that I need to ensure is built in a repeatable and
>consistent fashion then I probably need a complex build tool to meet the
>needs of the project, and the project is probably complex enough to 
>imply the needs of a CM specialist who understands the build tools!

perhaps thou we are gonna fight against that idea kicking and screaming ;)
Most of my end-users are simple web-developers who think javascript is the
greatest thing ;) Luckily atm whatever file I build atm they can use and
modify easily. A few changes recently have made this a little more
difficult but it is still within their grasps and I hope it always will be.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message