On Sat, Aug 09, 2003 at 06:57:50PM +0200, Sven Luther wrote:
>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.
I think I can extract the date from the '$XFree86' line in the
CHANGELOG file and add it to the auto-generated xf86Build.h. While
I'm at it, I can adjust the auto-generation of xf86Build.h so that
its modification time doesn't change when its contents don't change.
I've attached a patch for this.
>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.
It gets updated for most commits, but not necessarily every trivial one.
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
Index: Imakefile
===================================================================
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/Imakefile,v
retrieving revision 3.150
diff -u -r3.150 Imakefile
--- Imakefile 19 May 2003 14:47:33 -0000 3.150
+++ Imakefile 9 Aug 2003 18:28:05 -0000
@@ -62,6 +62,8 @@
EXT_MODULES_DEFINES = $(GLX_DEFINES)
#endif
+CHANGELOGFILE = ../CHANGELOG
+
#if UseMemLeak
MDEBUGDEFS = -DMEMDEBUG
#endif
@@ -256,11 +258,24 @@
clean::
RemoveFile(xf86Build.h)
+ RemoveFile(build.new)
#if defined(BuildDate)
xf86Build.h: FRC
- RemoveFile($@)
- echo "#define BUILD_DATE $(BUILD_DATE)" > $@
+ RemoveFile(build.new)
+ echo "#define BUILD_DATE $(BUILD_DATE)" > build.new
+ @(set +e; str=`tail $(CHANGELOGFILE) | grep -F '$$XFree86:'`; \
+ if [ X"$$str" != X ]; then \
+ clog=`echo $$str | \
+ sed s,'.* \([0-9][0-9]*\)/\([0-9][0-9]*\)/\([0-9][0-9]*\).*,\1\2\3,'`
&& \
+ set -x; echo "#define CLOG_DATE $$clog" >> build.new; \
+ fi)
+ @if cmp -s build.new $@; then :; \
+ else \
+ (set -x; RemoveFile($@); \
+ $(MV) build.new $@); \
+ fi
+ RemoveFile(build.new)
FRC:
#else
Index: xf86Init.c
===================================================================
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Init.c,v
retrieving revision 3.199
diff -u -r3.199 xf86Init.c
--- xf86Init.c 25 Mar 2003 04:18:21 -0000 3.199
+++ xf86Init.c 9 Aug 2003 18:16:04 -0000
@@ -1676,6 +1676,20 @@
ErrorF("Build Date: %s\n", buf);
}
#endif
+#if defined(CLOG_DATE) && (CLOG_DATE > 19000000)
+ {
+ struct tm t;
+ char buf[100];
+
+ bzero(&t, sizeof(t));
+ bzero(buf, sizeof(buf));
+ t.tm_mday = CLOG_DATE % 100;
+ t.tm_mon = (CLOG_DATE / 100) % 100 - 1;
+ t.tm_year = CLOG_DATE / 10000 - 1900;
+ if (strftime(buf, sizeof(buf), "%d %B %Y", &t))
+ ErrorF("Changelog Date: %s\n", buf);
+ }
+#endif
#if defined(BUILDERSTRING)
ErrorF("%s \n",BUILDERSTRING);
#endif
