Malcolm and all,
On Thursday, November 27, 2003, at 03:30 PM, Malcolm J. Currie wrote:
> I can see some benefit in distinguishing two checkouts for application
> users and application developers.
I didn't mean quite that, if I understand what you mean -- just that we
might usefully reserve a bit of the tree for components which were not
usefully distributable. I had the notion that SST was semi-deprecated,
which is why I suggested it as an example of what might go there.
However I have no particular opinion on SST as such, and if folk think
it has the same status as other applications, I will make absolutely no
dispute, as long as it ends up in the repository somewhere.
David earlier said:
> > In any case, there needs to be some place for autoconf macros.
>
> What about an "autoconf/" tree?
The first thing is that `autoconf' would look like it ought to contain
a local version of autoconf, which it wouldn't, and that would be
confusing. However, even `autoconf-macros' would be bad, because...
Such macros really are absolutely useless outside the tree, though they
have to be in the tree somewhere. Similarly, the tools that Steve uses
to do the nightly builds, or to construct the CDs, should be in the
tree somewhere, but are undistributable, since they are meaningless to
anyone not working with a checked-out version of the code. As such,
these don't fall into any of the categories `applications, buildlog,
docs, java, libraries, pubs, thirdparty' -- the autoconf macros are
not an `application', and if we force them into that category, we'll
just confuse ourselves and others, and be obliged to have a separate
way of recording which `applications' are sanely distributable and
which are not.
C'mon, folks -- is this really this contentious?
How about
buildsupport
build
devtools
repositorymaintenancetools (only teasing, Mark)
By the way, I would think that Steve's `buildlog' should be relocated
into this category as well, before too many other tools start depending
on its location. It's important, but as part of a larger maintenance
whole.
See yez,
Norman
--
----------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow [log in to unmask]
|