This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Sat, 26 Aug 2000 09:31:37 -0700
From: bkorb@cruzio.com (Bruce Korb)
Subject: A truely ugly hack...
Hi all,
I got a little time to think about the problem of generated
files in the CVS archive (viz. the "contrib" branch).
The files were removed from the main GCC hierarchy on the theory that
it is a pain to maintain them and most developers have the relevant
tools. The problem arises when there are developers that do not have
the relevant tools handy and there is no backup mechanism in place.
This gets us to an easily proved corollary: moving the generated files
into an obscure side hierarchy will be even less often maintained.
What to do? How about some kludgery? :-)
The goal would be to automatically commit updates to the generated
files whenever there are changes to their predecessor files.
There are several approaches:
1. A daemon process. This leaves a time delay between the commit
and the updated archive. Probably better than not having the
generated files available at all, but possibly inconvenient
for some.
2. The CVS config file does not work very well for this purpose
3. The CVS commitinfo file works a little better, but has interesting
problems, too. See below.
4. Try to maintain it all by hand. It will get out-of-date, but
developers ought to have the tools anyway. [[gag! ;-( ]]
5. Don't have the tools? Tough bounce. (current scheme)
So, of these, #3 has the most pleasing promise. But, there are problems..
The ugliest is that in order to generate the updated file, you have to
have access to the predecessor files that are not being checked in.
(Those are are available.) In order to get access, you have to be
able to: cvs -d xxx get -r dir-path/mumble -- Oops. You cannot because
'dir-path' is locked during the processing of the commitinfo command
by a parent processes. Isn't *that* special? That renders #3 (and
#2) completely impossible. Unless you implement a Truely Ugly Hack.
The Truely Ugly Hack:
Determine if the "dir-path/.#cvs?*" refers to an ancestor process and,
if so, move the .#cvs* files & dirs aside, do what you gotta do, and
move them back. (Recursively, of course :-) Yummy.
I have played with a prototype of this enough to know it is a computable
problem. (I actually got it mostly working.) Before actually finishing,
though, I wanted a little feedback. Finishing it would be too much work
to just throw away.
Cheers,
Bruce
P.S. I cc-ed info-cvs so those folks can suggest a Better Method :-)
x-uunet-gateway: wodc7mr0.ffx.ops.us.uu.net from info-cvs to gnu.cvs.help; Sat, 26 Aug 2000 16:40:27 GMT
Subject: Re: A truely ugly hack...
References: <39A7F0E9.2AD8323E@cruzio.com>
X-Mailer: Mew version 1.94b25 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-URL: http://www.codesourcery.com
Organization: CodeSourcery, LLC
From: mark@codesourcery.com (Mark Mitchell)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20000826094016U.mitchell@codesourcery.com>
Date: Sat, 26 Aug 2000 09:40:16 -0700
===
From: mrs@windriver.com (Mike Stump)
Date: Sat, 26 Aug 2000 09:59:11 -0700
Subject: Re: A truely ugly hack...
> Date: Sat, 26 Aug 2000 09:31:37 -0700
> From: Bruce Korb <bkorb@cruzio.com>
> 3. The CVS commitinfo file works a little better, but has interesting
> problems, too. See below.
> So, of these, #3 has the most pleasing promise. But, there are problems..
I think you can solve the problem my doing the processing
asynchronously, jut spawn it off during a modification, and it'll test
to see if a new .[ch] file would be generated, and if so, it'll check
out the file, and modify it, then check it back in. If there is a
lock, have it sleep for 20 seconds (or so), and try again.
Would that work?
> The Truely Ugly Hack:
> Determine if the "dir-path/.#cvs?*" refers to an ancestor process and,
> if so, move the .#cvs* files & dirs aside, do what you gotta do, and
> move them back. (Recursively, of course :-) Yummy.
No, please don't consider this.
x-uunet-gateway: chi6sosrv11.alter.net from info-cvs to gnu.cvs.help; Mon, 28 Aug 2000 17:57:37 GMT
===
Date: Mon, 28 Aug 2000 13:57:40 -0400
From: rsalz@caveosystems.com (Rich Salz)
Subject: Re: A truely ugly hack...
This is a multi-part message in MIME format.
--------------D502BD8D8038996BA889CEFD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> The goal would be to automatically commit updates to the generated
> files whenever there are changes to their predecessor files.
I use the commitinfo file to force developers to maintain it all by
hand. For example, here's a line from a commitinfo in one of our
repositories:
^conf$ ${CVSROOT}/CVSROOT/run-autoconf.pl
Attached is the run-autoconf perl script. I can think of a more general
approach (use an assoc array that is eval'd into the perl script to
maintain dependencies and add them to the "must be found" list) which I
could throw together if there's interest.
/r$
--------------D502BD8D8038996BA889CEFD
Content-Type: application/x-perl;
name="run-autoconf.pl"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="run-autoconf.pl"
#! /usr/bin/perl
## Turn off setgid
$) = $(;
## Set defaults
$cvsroot = $ENV{'CVSROOT'};
$module = shift @ARGV || die "No module!?";
exit(0) if $module ne "$cvsroot/conf";
$found_dotin = 0;
$found_conf = 0;
foreach $f ( @ARGV ) {
$found_dotin++ if $f eq 'configure.in';
$found_conf++ if $f eq 'configure';
}
if ( $found_dotin && ! $found_conf ) {
print STDERR "Cannot change/commit configure.in and not configure\n";
exit(1);
}
if ( ! $found_dotin && $found_conf ) {
print STDERR "Warning -- shouldn't change/commit configure and not configure.in\n";
exit(0);
}
exit(0);
--------------D502BD8D8038996BA889CEFD--
x-uunet-gateway: dfw7sosrv11.alter.net from info-cvs to gnu.cvs.help; Mon, 28 Aug 2000 23:22:21 GMT
===
Date: Mon, 28 Aug 2000 16:23:53 -0700
From: bkorb@cruzio.com (Bruce Korb)
Subject: Re: A truely ugly hack...
Gerald Pfeifer wrote:
>
> On Sun, 27 Aug 2000, Bruce Korb wrote:
> >> Have you tried `cvs -n update`? This might solve the locking issue...
> > `-n'
> > Do not change any files. Attempt to execute the `cvs_command',
> > but only to issue reports; do not remove, update, or merge any
> > existing files, or create any new files.
>
> Hmm, you're right.
>
> What you could do if you want to access any given revision in the
> repository is something like
>
> cvs annotate -r 1.37 filename | cut -c36- > /tmp/some/where/filename
>
> Of course this is a hack, but it works! ;-)
>
> Gerald
Unless and until CVS puts proper support for automated handling
of generated files, *ANY* method is pure kludgery. I like it. :-)
Since the new location for generated files in GCC is off in an
obscure directory, there should be no locking conflicts.
(Assuming that people are not ever checking in generated files now.)
Cool.