Обсуждение: Changes to handling version numbers internally
I'd like to change some things about how the code handles the information about its own version number. The version number would be set in configure.in as in VERSION='1.2.3' (Keep it in configure.in because it would be nice to have this information available globally. One fine day we might even automatically make tarballs with this.) config.h defines the symbol PG_VERSION (VERSION is probably too prone to clashes) as "1.2.3", which applications can then use to display --version information of whatever. The canonical string "PostgreSQL x.y.z compiled by zz" is still available. Applications that want to test for "release compatibility" like 7.0.1 vs 7.0.2 can use strtod(PG_VERSION, NULL) and then use a simple `==' or `<', etc. (Of course you're free to parse yourself "number"-"dot"-"number". That's not hard.) Right now I think we should set it to '7.1devel', later to '7.1b1', etc. It's really quite wrong to label it '7.1' already now. I also think that we could scrap the pg_version program. Its function is to create a file PG_VERSION in the directory given as argument, and it's called by initdb. Why not just substitute the version number into initdb at build time and just `echo > PG_VERSION'? One less level of redirection. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Fri, 30 Jun 2000, Peter Eisentraut wrote: > I'd like to change some things about how the code handles the information > about its own version number. > > The version number would be set in configure.in as in > > VERSION='1.2.3' > > (Keep it in configure.in because it would be nice to have this information > available globally. One fine day we might even automatically make tarballs > with this.) So, we have to change and autoconf that periodically, instead of just having a simple 'version.h' file that we vi? It doesn't sound to me like something that *belongs* in configure.in, as it is not required for any tests that configure requires ...
Peter Eisentraut <peter_e@gmx.net> writes:
> The version number would be set in configure.in as in
Makes sense to me. Right now there is a list someplace of all the
places that have to be edited to update the version number :-(.
If configure could help centralize/automate that, it'd be great.
I also concur that supporting non-numeric suffixes on the version
string would be a big improvement.
> I also think that we could scrap the pg_version program.
Yes, it seems like dead weight to me too. I think that it
predates our use of configure, so at the time it might have
been necessary mechanism, but now...
regards, tom lane
Two issues with the new versioning ideas:
- The version number would be set in configure.in as in VERSION='1.2.3'
- So, we have to change and autoconf that periodically, instead of just having a simple 'version.h' file that we vi?
It doesn't sound to me like something that *belongs* in configure.in, as it is not required for any tests that
configurerequires ...
What about having a single file (e.g., VERSION) somewhere that
contains the relevant information (e.g., it only contains 1.2.3). Any
Makefiles that need it could cat the value into a make variable and
use it; any C files that need it could include it as appropriate.
Alternatively, though probably not so cleanly in some ways, configure
itself could use the value to define a variable that would be
propagated as needed (probably only Makefile.global and config.h).
Another point:
Right now I think we should set it to '7.1devel', later to '7.1b1', etc. It's really quite wrong to label it '7.1'
alreadynow.
I suggest a numbering sequence that is strictly orderable. This is
really useful for the versioning of the NetBSD code, because the
location of each version within a largaer sequence is immediately
obvious. The sequence goes something like:
trunk -+--> 1.4A ---> 1.4B ---> 1.4C ---> ... -+--> 1.5A ---> 1.5B ---> ... |
| | |
releases +--> 1.4Alpha ---> 1.4Beta ---> 1.4 +--> 1.5Alpha ---> 1.5Beta ---> 1.5
| | +--> ... ---> 1.4.1 --->
...
This may not exactly correspond to the NetBSD scheme, but the general
points should be clear: the main trunk versions are incremented in a
nicely sortable order whenever major interfaces change (corresponding
presumably to our need for initdb), and the branches have a similar
clear ordering. This seems preferable to using versions like 7.1devel
or 7.1b1 which are less formalized and less sortable.
Cheers,
Brook
The Hermit Hacker writes: > It doesn't sound to me like something that *belongs* in configure.in, > as it is not required for any tests that configure requires ... This way we can also make it available to shell scripts and make files. The next autoconf version will have built-in support for this setup, so it's not like I'm making this up. :) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Sat, 1 Jul 2000, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > It doesn't sound to me like something that *belongs* in configure.in, > > as it is not required for any tests that configure requires ... > > This way we can also make it available to shell scripts and make > files. The next autoconf version will have built-in support for this > setup, so it's not like I'm making this up. :) I see you've already committed the changes, which I still disagree with ... I don't like the fact that someone has to remember to update the configure.in and autoconf it to change the version number. We already have the mess with template files, why not create a VERSION file that could just as easily be read in by configure, without having to do an autoconf, to change the version?
The Hermit Hacker <scrappy@hub.org> writes:
>> This way we can also make it available to shell scripts and make
>> files. The next autoconf version will have built-in support for this
>> setup, so it's not like I'm making this up. :)
> I see you've already committed the changes, which I still disagree with
> ... I don't like the fact that someone has to remember to update the
> configure.in and autoconf it to change the version number.
It's a lot better than it was before ;-)
> We already have the mess with template files, why not create a VERSION
> file that could just as easily be read in by configure, without having
> to do an autoconf, to change the version?
Gilding the lily. The people who are likely to be bumping the version
number are all perfectly familar with autoconf. Also, we've already
got bad-enough problems with dependencies (see nearby thread) without
introducing a dependency from a file that's read by configure to
who-knows-where --- a dependency that can't be handled by 'make depend'.
regards, tom lane
On Sun, 2 Jul 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > >> This way we can also make it available to shell scripts and make > >> files. The next autoconf version will have built-in support for this > >> setup, so it's not like I'm making this up. :) > > > I see you've already committed the changes, which I still disagree with > > ... I don't like the fact that someone has to remember to update the > > configure.in and autoconf it to change the version number. > > It's a lot better than it was before ;-) > > > We already have the mess with template files, why not create a VERSION > > file that could just as easily be read in by configure, without having > > to do an autoconf, to change the version? > > Gilding the lily. The people who are likely to be bumping the version > number are all perfectly familar with autoconf. Ya, I've been fighting myself internally on this point ... I just hate the though of embed'ng it into configure, that's all ... peter mentioned something about next version of autoconf doing this?
On Mon, 3 Jul 2000 eisentrp@csis.gvsu.edu wrote: > On Sun, 2 Jul 2000, The Hermit Hacker wrote: > > > peter mentioned something about next version of autoconf doing this? > > Yeah, you write AC_INIT(Package, Version) and that creates the VERSION > variable and substitutes it, just like I did. (It also creates the PACKAGE > variable, in case you ever want to rename the package. :) > > If you don't like it in configure.in, I understand, but it seems like that > would be just one more file to find. To me, it just seems that it will more often be forgotten then putting it into a VERSION text file ... but it isn't something that I'm going to turn blue in face over ... since its as 'clean' as above, leave it ... One thought, and with all your recent changes you may have done this, but is there any way of putting some sort of text file as part of the install procedure that "stores" the ./configure command line? Something that, if I were to remove all sources but decide later that I want to add, let's say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the system is already compiled?
On Sun, 2 Jul 2000, The Hermit Hacker wrote: > peter mentioned something about next version of autoconf doing this? Yeah, you write AC_INIT(Package, Version) and that creates the VERSION variable and substitutes it, just like I did. (It also creates the PACKAGE variable, in case you ever want to rename the package. :) If you don't like it in configure.in, I understand, but it seems like that would be just one more file to find. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
The Hermit Hacker <scrappy@hub.org> writes:
> One thought, and with all your recent changes you may have done this, but
> is there any way of putting some sort of text file as part of the install
> procedure that "stores" the ./configure command line? Something that, if
> I were to remove all sources but decide later that I want to add, let's
> say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the
> system is already compiled?
config.status has always done this.
regards, tom lane
The Hermit Hacker writes: > One thought, and with all your recent changes you may have done this, but > is there any way of putting some sort of text file as part of the install > procedure that "stores" the ./configure command line? Something that, if > I were to remove all sources but decide later that I want to add, let's > say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the > system is already compiled? config.status stores the current configuration. To reuse it, run `./config.status --recheck'. If you just want to *know* what the current configuration is, then `head config.status' should answer that pretty well. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
The Hermit Hacker <scrappy@hub.org> writes:
> you guys missed the key part of my message "if I were to remove all
> sources but decide later ..." :) if I remove sources, I no longer have
> config-status to work with :)
No, I didn't miss it. IMHO "make distclean" should remove every file
created by configure --- that would include any specialized "CONFIGURE"
output file you might want it to create. So there's no advantage to
having that over the existing config.status output file.
If you don't want to lose the configure outputs then do "make clean",
not "make distclean".
regards, tom lane
The Hermit Hacker writes: > you guys missed the key part of my message "if I were to remove all > sources but decide later ..." :) if I remove sources, I no longer have > config-status to work with :) Well, if you remove everything, then where is that configure command line saving file going to survive? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Thu, 6 Jul 2000, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > you guys missed the key part of my message "if I were to remove all > > sources but decide later ..." :) if I remove sources, I no longer have > > config-status to work with :) > > Well, if you remove everything, then where is that configure command line > saving file going to survive? that is what I'm kinda asking for ... maybe some POSTGRES/etc directory can be created, or create a file under lib that just contains that one command? think about Lamar's RPMs ... might not be many that would, but some might like to be able to look at a file and see what args he used to configure it, in case they want to keep what is currently there, but add an option that he didn't put in ...
you guys missed the key part of my message "if I were to remove all sources but decide later ..." :) if I remove sources, I no longer have config-status to work with :) On Wed, 5 Jul 2000, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > One thought, and with all your recent changes you may have done this, but > > is there any way of putting some sort of text file as part of the install > > procedure that "stores" the ./configure command line? Something that, if > > I were to remove all sources but decide later that I want to add, let's > > say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the > > system is already compiled? > > config.status stores the current configuration. To reuse it, run > `./config.status --recheck'. If you just want to *know* what the current > configuration is, then `head config.status' should answer that pretty > well. > > -- > Peter Eisentraut Sernanders v�g 10:115 > peter_e@gmx.net 75262 Uppsala > http://yi.org/peter-e/ Sweden > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker writes: > that is what I'm kinda asking for ... maybe some POSTGRES/etc directory > can be created, or create a file under lib that just contains that one > command? > > think about Lamar's RPMs ... might not be many that would, but some might > like to be able to look at a file and see what args he used to configure > it, in case they want to keep what is currently there, but add an option > that he didn't put in ... Good point. (Although the RPMs do way too much custom patching right now for this to be very useful.) Someone recently asked for a utility along the lines of gnome-config so they can get the installation paths for the libraries and include files for their package. Maybe we can work the configure command line into that. $ pg-config --includedir /usr/local/pgsql/include $ pg-config --libdir /usr/local/pgsql/lib $ pg-config --configure --enable-debug --with-CXX Comments? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> Someone recently asked for a utility along the lines of gnome-config so
> they can get the installation paths for the libraries and include files
> for their package. Maybe we can work the configure command line into that.
> $ pg-config --includedir
> /usr/local/pgsql/include
> $ pg-config --libdir
> /usr/local/pgsql/lib
> $ pg-config --configure
> --enable-debug --with-CXX
> Comments?
I like it. We can still say that make distclean wipes the source tree
clean of configure output ... but the install tree retains documentation
about how it was built.
Aside from configure options, it'd at least be important to save the
selected OS template name. Not sure what else.
regards, tom lane
On Sat, 8 Jul 2000, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > that is what I'm kinda asking for ... maybe some POSTGRES/etc directory > > can be created, or create a file under lib that just contains that one > > command? > > > > think about Lamar's RPMs ... might not be many that would, but some might > > like to be able to look at a file and see what args he used to configure > > it, in case they want to keep what is currently there, but add an option > > that he didn't put in ... > > Good point. (Although the RPMs do way too much custom patching right now > for this to be very useful.) > > Someone recently asked for a utility along the lines of gnome-config so > they can get the installation paths for the libraries and include files > for their package. Maybe we can work the configure command line into that. > > $ pg-config --includedir > /usr/local/pgsql/include > $ pg-config --libdir > /usr/local/pgsql/lib > $ pg-config --configure > --enable-debug --with-CXX > > Comments? That would be perfect also