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

Re: Patch to add version numbers to libpq.rc

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Patch to add version numbers to libpq.rc
Date: 2004-12-16 23:38:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32pgsql-patches
OK, I have created a final version of the patch, attached, and a new file that goes into src/interfaces/libpq.  It uses date
'+%y%j' to stamp the libpq.rc file, and does the same for win32ver.rc in

One difficulty was generating a new version of libpq.rc at the proper
time.  I added a prepdist rule just like *.def.  I also added code so
every time you do a 'make clean' or distclean it does a 'touch' on so libpq.rc is rebuilt on the next compile.  That seemed
like the cleanest solution.


Magnus Hagander wrote:
> >Bruce Momjian wrote:
> >> We could do "date '+%y%j' to output 04349.  How many bits do 
> >we have for
> >> that last comma value?  This would work unless you put out two
> >> installers in the same day.  However, this would not work 
> >for VC and BCC
> >> because they don't have 'date'.  This would give us an 
> >ever-increasing
> >> value for each release.
> >
> >Here is a sample patch for automatically adding the year/julian date to
> >the libpq.rc file.  It requires moving libpq.rc to and then
> >making the Makefile modifications attached.  I also included how
> >libpq.rc changes so you can see the numbers added.
> Patch works as intended - in case you hadn't tested it on win32. I
> assume using "%j" will always return "001" and never "1"? My man page
> says it does, but I'm not sure if it's portable everywhere.
> >I have used the existing *.def build method but for a final version I
> >think I have to make it its own rule so it is recreated on every MinGW
> >build rather than just when exports.txt changes or a package prepdist
> >build is made.  
> Yes! This is very important! 
> >VC and BCC aleady require a prepdist build so we should
> >be OK with having this built at that time always. 
> Yes, we no longer support building from cvs on vc/bcc unless you do the
> "distprep" step manually using mingw (or unix) first.
> > I can see pginstaller
> >building from CVS and would like to make sure it has an updated day
> >stamp so I am thinking it should be recreated every time libpqrc.o is
> >created.
> Yes, please!
> Thanks a lot for fixing this. 
> Question: Would it be trivial to add the same thing to the rest of the
> DLLs/EXEs? (No need in distprep, just in the general rule). Check
> around line 405. Since we already have build rules
> that 'sed' on the rc file...
> If it's a lot of work, leave it for later. But if it's not too much, it
> would be quite helpful on these DLLs/EXEs as well.
> //Magnus
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>       message can get through to the mailing list cleanly

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2004-12-17 00:35:19
Subject: Re: [PATCHES] Patch to add version numbers to libpq.rc
Previous:From: Bruce MomjianDate: 2004-12-16 18:13:45
Subject: Re: Threading with non-shared libraries

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-12-17 00:22:35
Subject: Re: [PERFORM] scalability issues on win32
Previous:From: Magnus HaganderDate: 2004-12-16 18:06:24
Subject: Re: Patch to add version numbers to libpq.rc

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