On Tue, 3 Jul 2001 18:39, Peter Vogel wrote:
> It's interesting that you say this. Because the same is true for
> me, and has been for the 12 or so years I've been implementing
> builds for one thing or another -- developers (whether C, C++,
> Java or otherwise) generally consider build automation "beneath"
> them (though they could not live without it) and so do not want to
> be bothered with the intricacies of *any* build tool, whether it
> be make, Ant, or (God forbid) shell scripts. Therefore, to me the
> *key* requirement for a build tool is that it supports the construction
> of an "infrastructure" which defines a project/company specific
> environment of *conceptually simple* constructs that are reusable from
> project to project within the company and where a project build file is
> a "no brainer" for the developers -- the intelligence is embedded in the
> infrastructure, where it can be explained to the small cadre of people who
> care or have interest in such things, and where it can be appropriately
> grown to meet the evolving needs of the company.
Similar arguements are made for things like TCL or lisp. Given a few basic
operations (5-6 in those cases) all the rest of infrastructure comes for free
(or via add in modules).
Neither really took off commercially (well except for maybe tcl but some
would argue that is because of tk) not because they weren't good. But because
to use it effectively required substantial knowledge and understanding.
Things that people weren't willing to invest in to PLs. Do you think they are
even more likely to invest it in a build infrastructure? (Before you answer
that look at how most non-build engineers deal with Make).
> So, here's my problem with all your "template" concepts: they require that
> I (and, more importantly, others who will inherit the infrastructure that
> I construct, whether it be 6 weeks or 6 years from now) study and
> understand yet another tool/language/etc. to do what can be done neatly and
> cleanly within
> the core of ant in a far simpler manner conceptually.
So let me see if I have got this correct. Build engineers want to do complex
things. Hence you want complexity imported into ant "language" making it
possible to do what you want. Because in your situation you have some one
that can be dedicated to maintiang build process. It doesn't matter to you
that other projects that don't need a build engineer will be paying for
complexity because you will never be in that situation.
And this is all to avoid learning a templating language. Even though that
language is potentially a standard language whos basics could be understood
in .... what about 40 minutes? Well all I can say is ... boo hoo.
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 |
*-----------------------------------------------------*
