On Sat, Aug 09, 2003 at 12:32:02PM -0400, David Dawes wrote: > On Sat, Aug 09, 2003 at 05:41:25PM +0200, Sven Luther wrote: > >On Fri, Aug 08, 2003 at 03:53:00PM -0400, David Dawes wrote: > >> On Fri, Aug 08, 2003 at 10:14:58AM +0200, Sven Luther wrote: > > >> >Using a CVS date variable or something such, which the XFree86CustomVersion > >> >would be set to when taking it out of CVS, and which you would remove > >> >before doing the snapshots ? > >> > >> Do you have a specific example? Preferrably one that doesn't unnecessarily > >> complicate things. > > > >Err, i was thinking of putting an > > > >#define XFree86CustomVersion $Date > > > >per default in one of the .cf files, and erase this lines when doing the > >export for the snapshots. Either by hand after having done the export, > >or with a special option to cvs export. I believe you would have to > >use another variable ($CheckoutDate ?) which you would usually have set > >to $Date, and which you would then set to nothing when doing the export. > >I believe there is a cvs option that can override one of the keyword > >expansions, but i am not familiar enough with cvs to tell you which, and > >if it doesn't work, it can be done by hand. > > I don't think it is either necessary or desirable to make exceptions > for snapshots. Snapshots are defined simply by tags, and not by > the way they are later checked out or exported.
Yep, manual manipulation is not nice and will most assuredly cause mistakes some days or others. > >Now, the problem is probably that the $Date will give a string prefixed > >by the $Date: string, and include the hour probably also, so maybe some > >kind of postreatment is needed, but i don't know if it is feasible in > >cpp. > > > >It was just an idea anyway. > > Well, I asked for a specific example because I can't think of one that > will give consistent results without intruding on the commit process. > > The problem with $Date is that it expands to the commit date of > the file, not the checkout date (or the -D date). If there was a Effectively, i didn't think of that. This would not work i guess. > solution like this, it could go in xf86Date.h, and it wouldn't > require exceptions for the snapshots/releases. What about using the date of the CHANGELOG file ? > The only thing I can see that would give a consistent and predictable > result in all cases (cvs co, cvs co -D <date>, cvs -r <tag>) would > be to have xf86Date.h automatically modified with every single > commit. This wouldn't be the checkout date, but a date representing > the last commit in the checked out tree. The only ways I can think > of doing that right now would cause more inconvenience than I think > it's worth, but if someone has a specific tested solution, with > documented impact and side-effects, let me know. Alternatively, we could use the almost same effect by somehow having the XFree86.0.log include the latest CHANGELOG entry number. This could be done by some preprocessing. If the date in the first XFree86 line is full, and we have a normal release, or it is marked as xx or some other sign, and we are facing a CVS checkout. In this case, we use the first number in the line just below the XFree86 line, and embed that number in the log message writing code. A little sed or awk or whatever processing in the Imakefile should produce the desired effect at build time. This would enable us to easily spot when the tree was checked out, and would not need us to fool with CVS stuff or so. Naturally this supposes that the CHANGELOG file is updated regularly between comits, but this is the case anyway. Friendly, Sven Luther _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
