>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
