cvs commit: hugs98/src version.h.in Makefile.in version.h
lewie 2002/10/03 21:16:42 PDT Modified files: src Makefile.in Added files: src version.h.in Removed files: src version.h Log: Automatically generate dates for version strings. Override automatic dates by editing version.h.in. Revision Changes Path 1.25 +6 -0 hugs98/src/Makefile.in
On Thu, Oct 03, 2002 at 09:16:42PM -0700, Jeff Lewis wrote:
lewie 2002/10/03 21:16:42 PDT
Modified files: src Makefile.in Added files: src version.h.in Removed files: src version.h Log: Automatically generate dates for version strings. Override automatic dates by editing version.h.in.
Wouldn't it be better if version.h were generated by configure rather than make? And if you used the 3-letter month name, there'd be room for RC1 etc.
On Friday 04 October 2002 02:56 am, Ross Paterson wrote:
On Thu, Oct 03, 2002 at 09:16:42PM -0700, Jeff Lewis wrote:
lewie 2002/10/03 21:16:42 PDT
Modified files: src Makefile.in Added files: src version.h.in Removed files: src version.h Log: Automatically generate dates for version strings. Override automatic dates by editing version.h.in.
Wouldn't it be better if version.h were generated by configure rather than make? And if you used the 3-letter month name, there'd be room for RC1 etc.
If it were generated by configure, it would most certainly be out of date most of the time (but perhaps you re-run configure more than I do ;-). For RC1-ish things, those will be the least common form of version name, and in that case, I'd just override by tweaking version.h.in. But, we could have another switch in that file that generates an `RC' form of release string which uses the 3-letter form. --Jeff
On Fri, Oct 04, 2002 at 06:09:13AM -0700, Jeffrey R Lewis wrote:
On Friday 04 October 2002 02:56 am, Ross Paterson wrote:
Wouldn't it be better if version.h were generated by configure rather than make? And if you used the 3-letter month name, there'd be room for RC1 etc.
If it were generated by configure, it would most certainly be out of date most of the time (but perhaps you re-run configure more than I do ;-).
I see your point. Still, your scheme has a couple of defects: - if anything is changed, hugs.c and server.c get recompiled - if only those two are changed, the version number is unaffected How about a little version.c with nothing in it but a getVersion() function, and making that depend on everything else?
On Wednesday 09 October 2002 12:10 pm, Ross Paterson wrote:
On Fri, Oct 04, 2002 at 06:09:13AM -0700, Jeffrey R Lewis wrote:
On Friday 04 October 2002 02:56 am, Ross Paterson wrote:
Wouldn't it be better if version.h were generated by configure rather than make? And if you used the 3-letter month name, there'd be room for RC1 etc.
If it were generated by configure, it would most certainly be out of date most of the time (but perhaps you re-run configure more than I do ;-).
I see your point. Still, your scheme has a couple of defects: - if anything is changed, hugs.c and server.c get recompiled - if only those two are changed, the version number is unaffected
How about a little version.c with nothing in it but a getVersion() function, and making that depend on everything else?
C'mon, Ross, admit it, ya just like pickin' nits ;-) Don't worry, we love ya for it. Your first point is of course correct, but is purely an optimization. If the shoe pinches, your suggestion of creating version.c is the way to go. Your second point is just plain wrong. If I touch hugs.c, and type `make', the version gets regenerated. --Jeff
Your second point is just plain wrong. If I touch hugs.c, and type `make', the version gets regenerated.
It seems like that is about as close as we can get to automatically generating version numbers. Indeed, the only reason I ever use commands like 'touch' is to trigger new version numbers, recompilation, etc. - it's not something I would do for some other reason and then wonder why recompilation, new version numbers, etc. happened. btw Are we anywhere close to doing a release? Each week I think 'ok, it'll surely go out this week' but, instead, some more fixes happen and the release doesn't. -- Alastair
Whatever you end up deciding to do here, could you
make sure that this works across platforms & doesn't introduce
unnecessary dependencies on platform-specific tools?
(As is, win32 builds are broken.)
version.h has the benefit of being simple..
--sigbjorn
----- Original Message -----
From: "Jeffrey R Lewis"
On Friday 04 October 2002 02:56 am, Ross Paterson wrote:
On Thu, Oct 03, 2002 at 09:16:42PM -0700, Jeff Lewis wrote:
lewie 2002/10/03 21:16:42 PDT
Modified files: src Makefile.in Added files: src version.h.in Removed files: src version.h Log: Automatically generate dates for version strings. Override automatic dates by editing version.h.in.
Wouldn't it be better if version.h were generated by configure rather than make? And if you used the 3-letter month name, there'd be room for RC1 etc.
If it were generated by configure, it would most certainly be out of date most of the time (but perhaps you re-run configure more than I do ;-).
For RC1-ish things, those will be the least common form of version name, and in that case, I'd just override by tweaking version.h.in.
But, we could have another switch in that file that generates an `RC' form of release string which uses the 3-letter form.
--Jeff _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
participants (5)
-
Alastair Reid -
Jeff Lewis -
Jeffrey R Lewis -
Ross Paterson -
Sigbjorn Finne