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

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Eggert wrote:

>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
>issue.


CVS only sets timestamps to the checkin time on checkout, not update.
Update always lets the timestamps be set "correctly" (the actual last
write time).  The alternative would break interoperation with make.
For instance, if the user had recently run a `make clean all', all *.o
files would have a recent timestamp.  If cvs update tried to set the
timestamp on a .c (or .y) file to the checkin time on update, it could
look incorrectly older than its object and the next build would fail
to rebuild the object.

Since I usually build from an existing workspace, checkin times of
files are irrlelvant to me when I roll CVS releases.  Assuming I
didn't make the modification to the file in the release workspace
myself, the timestamp is usually that of the last update of the file.

Neither do I want to change my release process to require a fresh
checkout of CVS.  My feeling is that `make distcheck' should Do the
Right Thing (tm) from any workspace, barring user error in file content.

>>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.


Ah, okay, you are saying that a working yacc installation is more
common tool than a working Autotool installation?  Common enough to
consider a broken yacc user error?

>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.  


My mistake.  For some reason, the *.texinfo version and stamp files
are only being rebuilt in maintainer mode and I had assumed that this
applied to the *.info files too, which I then used to draw the
conclusion that this was appropriate for *.y files.  Do you know why
version.texi files are only rebuilt in maintainer mode?  Is it the
unpredictably of the `ls' command used by mdate-sh?

>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,


This does sound like the most general solution.  I'll take a stab at
figuring how much work it will be, but more likely I'll go with the
solution below.

>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
>automatically....)


I like this Automake solution best.  I don't really want to check the
CVS source files by hand every time I roll a release and as long as I
am going to edit CVS's distcheck target, it probably won't be much
harder to fix this in Automake.  I'll try to take a stab at this in
the next week or two.

>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.


I really dislike creating targets which override Automake's...  then
when work-arounds are added to Automake targets for other build issues
as they are discovered, I always end up playing catch-up.  The fact
that Automake generated Makefiles generally increase in portability
over time without my necessarily having to work to solve each
individual portability issue is one of the reasons I like to use it.  :)

Incidentally, this most recent problem occurred with an old version of
getdate.y, not the newest one.  I had to back out the new getdate.y
before it made it into a released version of CVS since it is too
permissive about invalid dates.  I had considered leaving the
permissive getdate.y in for a few releases but I was overruled.  Which
reminds me, you asked me to ping you about that getdate.y fix in a
couple of weeks.  That was about three weeks ago.  :)

Thanks,

Derek

- --
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAvN8ZLD1OTBfyMaQRArcdAKDiOLKE4dR0roos+pAsZE3dhJBuogCgnTfm
Ywf83XLyijQism0tYMaBH2M=
=VV8N
-----END PGP SIGNATURE-----