Re: [PATCHES] [pgsql-hackers-win32] Patch to add version numbers to libpq.rc

2004-12-16 Thread Bruce Momjian

OK, I have created a final version of the patch, attached, and a new
libpq.rc.in 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
/port.

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
libpq.rc.in 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 libpq.rc.in 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
 Makefile.global.in 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 [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: src/Makefile.global.in
===
RCS file: /cvsroot/pgsql/src/Makefile.global.in,v
retrieving revision 1.207
diff -c -c -r1.207 Makefile.global.in
*** src/Makefile.global.in  16 Dec 2004 18:13:07 -  1.207
--- src/Makefile.global.in  16 Dec 2004 23:36:45 -
***
*** 415,423 
  PGICOSTR=$(subst /,\/,IDI_ICON ICON 
\$(top_builddir)/src/port/$(PGAPPICON).ico\)
  endif
  win32ver.rc: $(top_builddir)/src/port/win32ver.rc
!   sed -e 's;FILEDESC;$(PGFILEDESC);' -e 's;VFT_APP;$(PGFTYPE);' -e 
's;_ICO_;$(PGICOSTR);' $(top_builddir)/src/port/win32ver.rc  win32ver.rc
  win32ver.o: $(top_builddir)/src/port/win32ver.rc
!   sed -e 's;FILEDESC;$(PGFILEDESC);' -e 's;VFT_APP;$(PGFTYPE);' -e 
's;_ICO_;$(PGICOSTR);' $(top_builddir)/src/port/win32ver.rc  win32ver.rc
windres -i win32ver.rc -o win32ver.o 
--include-dir=$(top_builddir)/src/include
rm -f win32ver.rc
  endif
--- 415,423 
  PGICOSTR=$(subst /,\/,IDI_ICON ICON 
\$(top_builddir)/src/port/$(PGAPPICON).ico\)
  endif
  win32ver.rc: $(top_builddir)/src/port/win32ver.rc
!   sed -e 's;FILEDESC;$(PGFILEDESC);' -e 's;VFT_APP;$(PGFTYPE);' -e 
's;_ICO_;$(PGICOSTR);' -e 's;\(VERSION.*\),0 *$$;\1,'`date '+%y%j'`';' 
$(top_builddir)/src/port/win32ver.rc  win32ver.rc
  win32ver.o: $(top_builddir)/src/port/win32ver.rc
!   sed -e 's;FILEDESC;$(PGFILEDESC);' -e 's;VFT_APP;$(PGFTYPE);' -e 
's;_ICO_;$(PGICOSTR);' -e 's;\(VERSION.*\),0 *$$;\1,'`date '+%y%j'`';' 
$(top_builddir)/src/port/win32ver.rc  win32ver.rc
windres -i win32ver.rc -o win32ver.o 
--include-dir=$(top_builddir)/src/include
rm -f win32ver.rc
  endif
Index: src/interfaces/libpq/Makefile
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/Makefile,v
retrieving revision 1.122
diff -c -c -r1.122 

Re: [PATCHES] [pgsql-hackers-win32] Patch to add version numbers to libpq.rc

2004-12-16 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 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
 libpq.rc.in so libpq.rc is rebuilt on the next compile.  That seemed
 like the cleanest solution.

... except CVS will not like it at all.  Why don't you just remove the
libpq.rc file instead?

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] [pgsql-hackers-win32] Patch to add version numbers to libpq.rc

2004-12-16 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
 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
 libpq.rc.in so libpq.rc is rebuilt on the next compile.  That seemed
 like the cleanest solution.
 
 ... except CVS will not like it at all.  Why don't you just remove the
 libpq.rc file instead?

 I am going to remove libpq.rc from CVS because it is now a derived file
 from libpq.rc.in.  I don't remove via 'clean' because if someone wants
 to build VC or BCC and Win32 with the same tarball then once they do a
 'clean' they can't do a VC or BCC compile anymore.

 Does that answer your question?

Not in the least.

What I'm complaining about is that you can't simply touch a file that
is under CVS control; CVS will think it's been modified.

Perhaps it would work to make libpq.rc depend on both libpq.rc.in and
src/Makefile.global; then any re-configure would force it to be rebuilt.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster