[ disclaimer: I am a fan of keeping the source separate from the outputs,
but in the interest of fairness, I feel I must point out a few items ]
Craig R. McClanahan wrote:
>
> > 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.
I'd like to point out that the lines between "jakarta", "java", and "xml"
Apache projects is a bit arbitrary. As a concrete example, there is a lot
more in common between the xml-soap and the jakarta-tomcat build processes
(in terms of names of targets, where output is placed, etc) than there is
between jakarta-tomcat and jakarta-regexp.
Many developers have their own ideas of related projects, and mine includes
a few project not only at working-dogs, but also at exolab and even IBM
developerworks.
Even more importantly, the distinction between significant versions of a
project needs to be factored into this. In particular, the versions of the
servletapi project need to be handled as easily as the versions of the
tomcat project.
> > 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*.
There is a technological solution to this problem: .cvsignore files
http://www.cvshome.org/docs/manual/cvs_18.html#SEC173
- Sam Ruby
