tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)
Date Fri, 15 Dec 2000 15:45:01 GMT

On Friday, December 15, 2000, at 03:24 PM, wrote:

> > > 
> > > /jakarta-tomcat/ shouldn't then create ../build/ - it's 
> > > not nice! 
> >  
> > An alternate perspective - I like the fact that building a cvs checkout 
> > does not modify the checkout itself. 
> +1 ! 

I would be inclined to change 'not nice' to 'potentially dangerous', because any build script
that alters files outside the checkout by default may cause harm.  It relies on assumptions

1.	developers have write access to the parent directory
2.	creating a "build" directory in the parent directory is not a problem or nuisance to the
management of other files on the hard-disc.
3.	different projects will create subdirectories of the "build" directory and these subdirectory
names will never clash, despite the huge number of open source projects in existence.

If you have a directory of open source projects on your hard drive, lets call it "opensource".
 Inside that you put all your open source work in separate checkout directories:  "jakarta-tomcat",
"jakarta-ant", "argouml", "xml-cocoon", "omega", "build", "somethingelse".

You make them all and...  disaster... All the jakarta projects have put their builds into
named directories inside the directory with my favourite "build" build tool - messing it up
with extra files that are nothing to do with it.  Then "omega" completely wiped my build directory
when I did a clean build - it doesn't use subdirectories of "../build".

I don't want to knock the neatness of keeping everything in a cvs checkout clean and identical
to the original, but what are the practical disadvantages of having the build directory inside
the checkout, especially if a 'clean' build cleans out the build stuff automatically if you

Being able to build outside of the checkout is an option some users may prefer, but I don't
think we should be providing this as a default unless we can be sure of the 3 assumptions


Stuart Roebuck                        
Lead Developer                                  Mac OS X, Java, XML, etc.
View raw message