Stuart Roebuck wrote:
> On Friday, December 15, 2000, at 03:24 PM, [EMAIL PROTECTED] 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 !
> >
>
Building to a separate place has been my preference as well. Where the build actually
goes is controlled by Ant properties such as "tomcat.build" that can be customized.
>
> 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 that:
>
> 1. developers have write access to the parent directory
If you follow the recommended approach (create a "Jakarta" directory in your home
directory or wherever, and install all the project source distros inside it), this is
a given.
By the way, sharing development source trees across developers is not a good idea -
each developer should have their own copy of the source tree checked out. Otherwise,
you have cases where developers modifying things at the same time are stepping on each
other.
>
> 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.
If you follow the recommended approach (you will hear that a few times :-), this
directory ends up by default inside your "Jakarta" directory, completely segregated
from anything else on your disk.
>
> 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 the projects are really different, you should be building them someplace other than
in your "Jakarta" build directory. Then there are no clashes.
>
> 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".
>
See above -- the recommended development approach is there for a reason.
>
> 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 require?
>
Try doing a "cvs commit" or "cvs update" in your source directory -- are the files
marked with "?" ones that I forgot to register with CVS or are they just outputs of
the build process? You have to think about that *every single time*.
And no, I am not willing to avoid this by doing a "build clean" every time I want to
do a check-in, and then waste the time to rebuild from scratch again. I will rebuild
when *I* want to or need to.
>
> 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 above.
>
The recommended development approach avoids the problems you have described, without
requiring building inside the source directory.
It also means you have control over which versions of dependent packages you use to
build Tomcat, even though you might be using a different version of Ant or an XML
parser on some other project.
>
> Stuart.
>
Craig McClanahan
