Skip site navigation (1) Skip section navigation (2)

Re: Changes to handling version numbers internally

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changes to handling version numbers internally
Date: 2000-07-04 17:40:32
Message-ID: Pine.BSF.4.21.0007041437241.833-100000@thelab.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 3 Jul 2000 eisentrp(at)csis(dot)gvsu(dot)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? 



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-07-04 17:46:44
Subject: Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Previous:From: Karel ZakDate: 2000-07-04 17:26:43
Subject: Re: Statistical aggregates

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group