[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More on CVS layout
From: |
Peter Simons |
Subject: |
Re: More on CVS layout |
Date: |
20 Jan 2005 02:56:51 +0100 |
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
- macro obsoletion (was: File names), (continued)
- Re: File names (and synchronization), Guido Draheim, 2005/01/19
- Having the same contents on gnu.org and sf.net (was: File names), Peter Simons, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Guido Draheim, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Peter Simons, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Guido Draheim, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Peter Simons, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Peter Simons, 2005/01/19
Re: More on CVS layout, Guido Draheim, 2005/01/19
- Re: More on CVS layout,
Peter Simons <=
Re: More on CVS layout, Tom Howard, 2005/01/19
Re: More on CVS layout, Tom Howard, 2005/01/25