[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] Re: CVS Bug? or User error?

From: Paul Eggert
Subject: Re: [Bug-gnulib] Re: CVS Bug? or User error?
Date: Tue, 01 Jun 2004 12:13:52 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Derek Robert Price <address@hidden> writes:

> The issue isn't what happens when the files are checked out of CVS,
> the issue is what happens when they end up being compiled on a
> system where we don't control the environment.

Isn't the issue actually a combination of the two?  For example, the
cvs-1.12.8.tar.bz2 tarball contains two files getdate.c and getdate.y
that have exactly the same timestamp:

$ gtar tvjf cvs-1.12.8.tar.bz2 | grep 'getdate.[cy]'
gtar: Record size = 10 blocks
-rw-r--r-- 500/500       59474 2004-05-15 17:39:25 cvs-1.12.8/lib/getdate.c
-rw-rw-r-- 500/500       25621 2004-05-15 17:39:25 cvs-1.12.8/lib/getdate.y

My understanding is that if you had arranged for getdate.c to be newer
than getdate.y, your user wouldn't have had a problem, as the broken
'make' rebuilt getdate.c only because its time stamp equaled
getdate.y's.  I suspect that the timestamps came from your CVS
checkins of getdate.y and getdate.c, which is why I mentioned that

> We already distribute getdate.c, why try and regenerate it,

But the proposed solution applies to all .y files, not just getdate.y.
That seems a bit overkill, as many .y files should work just fine with
traditional yacc, and maintainers of those packages won't necessarily
want this workaround.

Here's another way to think about it.  Any package maintainer could
run into with a similar problem with any file that's shipped with the
package but is automatically generated by "make".  For example, they
might run into the problem with a .info file, if the user's texinfo
version is too old.  So, from an Automake point of view, perhaps it'd
be better to have a general solution: one where the package maintainer
says "I don't want to have files X, Y, and Z generated by the user,
unless they're a maintainer".

This more-general solution might be a pain to implement, but in the
meantime it appears that there's a simple solution to your particular
problem: just make sure that you ship a getdate.c newer than
getdate.y.  Similarly for .info versus .texi files, etc.  (Come to
think of it, it'd be nice if "make distcheck" did this

If shipping the correct time stamps is not enough for some reason,
there's another possible solution: namely, edit gnulib/modules/getdate
to specify an explicit rule for building getdate.c from getdate.y that
works only in maintainer mode.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]