Bootstrapping et al.

[Peter Donald <do...@apache.org>]

Hi,

I been thinking that to actually accomplish the flexability in the build
process that everyone seems to want we are going to either end up with a
forest of mangled scripts. For a while now I have been using another set of
bootstrap scripts that bootstrap the bootstrap ;) so as to enable all the
things that I want/don't want and to actually make it compile (ie define
CLASSPATH, define ANT_HOME, define JAVA_HOME, define JAVAC, define ... etc)

Ages ago bootstrapping current ant with an old ant was vetoed IIRC but I
would like to make a case for it. I would like to see an old version of ant
kept in CVS (say last released version). This would give us all heaps of
flexability and it would void the need for maintaining the complex
platforms specific scripts that we currently use. The main reason this was
vetoed last time was because it involved keeping jars in CVS and as this is
no longer  so taboo maybe we could change it ?

The only real other option is to build a Bootstrap.java that we use to
bootstrap the process. However this would be just as brittle and
unmaintainable as the other techniques - just in java. 

thoughts?


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               |
*-----------------------------------------------------*

Re: Bootstrapping et al.

[Peter Donald <do...@apache.org>]

At 01:16  26/1/01 +1100, Conor MacNeill wrote:
>I think the suggestion that these files are unmaintainable or brittle is
>questionable. If we look at the CVS activity on these files after July
>(when I rewrote most of them) up until the recent changes we have

but thats only because people work around the build files instead of
integrating them into their build process. The fact that I have to have
extra wrapper scripts so ant will build is kinda indicative of this.

>I presume you are not suggesting doing away with ant.bat and so, the only
>other script with any meat it was the bootstrap script. I wouldn't have
>called it a "forest of mangled scripts".

as I said it doesn't support both a low barrier of entry (my concern) and a
custom build environment (your concern). Thats why it is less painful atm.

>What do we go now? I am getting uncomfortable about the churn in the build
>process as we run up to a new release. I would vote to roll back the
>scripts but look at retaining the build.xml changes for the new build
>locations, etc.

Yer screw it ;) I don't think everyone will be happy so we may aswell roll
back till Ant2.0.


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               |
*-----------------------------------------------------*

Re: Bootstrapping et al.

[Conor MacNeill <co...@cortexebusiness.com.au>]

Pete,

> Hi,
>
> I been thinking that to actually accomplish the flexability in the build
> process that everyone seems to want we are going to either end up with a
> forest of mangled scripts. For a while now I have been using another set
of
> bootstrap scripts that bootstrap the bootstrap ;) so as to enable all the
> things that I want/don't want and to actually make it compile (ie define
> CLASSPATH, define ANT_HOME, define JAVA_HOME, define JAVAC, define ...
etc)
>
> Ages ago bootstrapping current ant with an old ant was vetoed IIRC but I
> would like to make a case for it. I would like to see an old version of
ant
> kept in CVS (say last released version). This would give us all heaps of
> flexability and it would void the need for maintaining the complex
> platforms specific scripts that we currently use. The main reason this
was
> vetoed last time was because it involved keeping jars in CVS and as this
is
> no longer  so taboo maybe we could change it ?

-1

The reason using an old ant.jar is bad is that it would prevent us having
an ant build file with any new features. For example, would you have been
happy to release an ant 1.2 which had to build with ant 1.1's ant.jar,
therefore using a build.xml file which included all the deprecated copy,
delete tasks etc.

It is important to be able to build ant completely from source. I am
strongly against an ant.jar in CVS. Putting other jars in CVS is one thing
(which I still do not support), but ant.jar is another.

>
> The only real other option is to build a Bootstrap.java that we use to
> bootstrap the process. However this would be just as brittle and
> unmaintainable as the other techniques - just in java.

I am happy to play with the AntEater bootstrap concept but we are a little
away from using that in a real build.

In truth the previous scripts have been happily building ant for many
months. If you look at the old build.bat, you will see that it was a very
thin wrapper for ant.bat which is part of the distribution anyway. This
file was only 15 lines long. Bootstrap.bat did not call build.bat, but
simply invoked Ant directly with Java. There was careful separation between
the ant being built and the one doing the build (the bootstrapped ant). The
present situation is very much different. build.bat is 3 times bigger and
duplicates most of ant.bat. build.bat calls bootstrap.bat which then calls
build.bat. The classes being run and also being written on.

I think the suggestion that these files are unmaintainable or brittle is
questionable. If we look at the CVS activity on these files after July
(when I rewrote most of them) up until the recent changes we have

build.bat 2 changes
build.sh no changes
bootstrap.bat 6 changs
bootstrap.sh 14 changes
ant.bat 10 changes
ant 10 changes

If we compare build.xml over the same timeframe there are about 70 changes.

I presume you are not suggesting doing away with ant.bat and so, the only
other script with any meat it was the bootstrap script. I wouldn't have
called it a "forest of mangled scripts".

What do we go now? I am getting uncomfortable about the churn in the build
process as we run up to a new release. I would vote to roll back the
scripts but look at retaining the build.xml changes for the new build
locations, etc.

Conor

Re: Bootstrapping et al.

[Jesse Glick <Je...@netbeans.com>]

Peter Donald wrote:
> [snip]
> Ages ago bootstrapping current ant with an old ant was vetoed IIRC but I
> would like to make a case for it. I would like to see an old version of ant
> kept in CVS (say last released version). This would give us all heaps of
> flexability and it would void the need for maintaining the complex
> platforms specific scripts that we currently use. The main reason this was
> vetoed last time was because it involved keeping jars in CVS and as this is
> no longer  so taboo maybe we could change it ?
> [snip]

BTW I tried to build current Ant with 1.2, assuming it would work, and
it seemed to at first...but defaults.properties and maybe other stuff
was missing from the resulting ant.jar. The bootstrapped version was
fine. If it's not a burden, it would certainly be nice for the current
build.xml to work with the most recent released binary.

-Jesse

-- 
Jesse Glick   <ma...@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR