Re: More on CVS layout

[Peter Simons]

Guido Draheim writes:

 > [A flat organization] is not compatible with additional
 > personal aclocal archives as well as third-party
 > experimental aclocal archives.

Why not? aclocal doesn't know anything about directories.
You have to tell it: -I/usr/share/ac-archive -- or whatever
-- and then it will find all macros in there. I thought the
_hierarchical_ organization was incompatible with aclocal?
("Incompatible" meaning: you have to give lots of -I flags.)


 > Think of it as per-project m4/ subdirectory that
 > sometimes get shared with other projects [...]

I consider the "ac-archive" tree in CVS to be one such
project. We can, however, create any number of additional
trees in CVS. You could have "guidos-macros" or
"wild-experiments" or whatever you like, yet the macros
would be fully integrated into the archive. Ever since we
have @category, file locations are irrelevant for the
formatting engine.

My reason why I think a flat organization is better is that
it is just simpler handle. You can say "grep python *",
instead of needing "find . -type f | xargs grep python". In
addition, you wouldn't have the problem that you'd have to
move the file -- what isn't possible in CVS --, if it
changes categories or gets a new maintainer.


 > Therefore, I would rather see to make subdirectories by
 > source - in sfnet I was often using the authors name as
 > the directory name [...].

What do you do when a macro changes owners? A macro that Joe
Doe used to maintain is taken over by Jane Doe now?


Tom Howard writes:

 > Flat makes most sense to me as well, but it would require
 > a migration step, where everything is moved from their
 > directories. Can we put it down as a to-do item?

Yes, that reorganization isn't going to happen for at least
a week or two. I'd like to get it right this time. ;-)

Ideally, moving the files would coincide with some serious
maintenance of the contents (such as editing macros to fit
policy).


 > cvs co ac-archive
 > cvs co ac-archive-build
 > cd ac-archive-build
 > ln -s ../ac-archive/legacy m4-src
 > ln -s ../ac-archive/COPYING .
 > ln -s ../ac-archive/README .
 > ./boostrap

This is the part where it fails right now: I can't find
"booststrap" and "autoreconf -i" doesn't seem to work.


 > Ideally the make step will build the docs, but I'll work
 > on that as soon as the licence changes are done.

Just so that we don't duplicate any effort: I have a pretty
sophisticated GNUmakefile that builds the entire archive.
That stuff isn't in CVS right now, but I'll make a version
available ASAP, probably when doing the CVS layout changes.

The thing that is missing right now is a mechanism to build
(and test!) a versioned release archive. I see that is what
your stuff can do already? If we could share the effort so
that you worry about packaging and I worry about building,
then the result should be pretty darn cool. Is that alright?

How about having a "make install-current" target that
fetches all files on-line from cvs.gnu.org directly before
it installs them? I think that would be what most people
really want, and it would be an incredibly small tar.gz
file. ;-) Is that possible?

Peter