Re: Version numbers on libpq.dll

Started by Magnus Haganderover 21 years ago12 messagespatches

magnus@hagander.net

over 21 years ago

Second, if two installers are created during beta2, they are
going to have the same version numbers and will not be
updated, so a fix to libpq will not get propogated. I see no
way to manage that except having the installer do it.

Like I've said repeatedly, we do not plan to put out installers with
in-between-beta builds. We've done so in the past for some

reasons, but

now that both pg for win32 and the installer is more mature,

we're not

going to do that. And if we are required to do that for some

reason at

some point, I'm sure we can bribe someone to bump the version number
between betas as well. Since that is definitly an

*exception*, and not

the rule.

I don't think this is an issue.

I question whether any of us will remember to modify libpq.rc if you
happen to be making a new installer twice in the same beta. As a group
we forget even simpler things regularly. And we would be adding an
additional change for each beta and each RC for only the installer. I
am not inclined to add more work to a process that already is pretty
complex.

However, that is Marc's roll and he can answer whether he can do it
reliably. I am not involved in that process.

Is there any way to get it into the build process? The same place where
it builds the other files in interfaces/libpq that are used in the MSVC
build - the .def files. Perhaps the "last number" could be the cvs
version number of configure.in or something? (This may be way off, I
don't really know how those files are generated. But it should be
possible to do with some fairly sinmple sed magic, I would think.)

That would take away the manual step, so they wouldn't be forgotten.

If this can't be done for now, could we accept doing it manually as a
temporary step until an automatic step can be put in place for 8.1? I'm
sure there are ppl who can help out by reminding Marc ;-)

The libpq.dll in SYSTEM32 and /lib will be different in that
SYSTEM32 will have the updated version stamp, but it is my
understanding only the installer cares about those version
numbers, so that seems OK.

Not sure that I follow this part completely. If you build

from cvs and

follow the default stuff, you will have the libs for the cvs

version in

that versions local directories and those apps are not affected by
what's in SYSTEM32 (assuming you copy it from lib to bin,

which you will

probably know to do if you're building off cvs. We are

trying to solve

the problem for the "big masses", not for the developers. Developers
will probably not use the installer)

My point is that installing from CVS will always overwrite libpq.dll in
/lib, so it doesn't care what the version stamp is in the binary. Only
the installer cares about the internal version stamp.

Right on the first. Wrong on the second.
Not "only the installer". *any* installer (if somebody embeds
postgresql). *any* deployment program (such as Systems Management
Server) used in an enteprise to distribute products. The "official MSI"
is just one of several possibilities. If we make it good enough it will
get rid of some others (for example, SMS could use it in silent mode to
install - but depending on corporate policy that may not be acceptable),
but there will be others.

I agree very much with Toms comment about the fact that the installer
project should *NOT* modify the files unless absolutely unavoidable.

Only the installer cares about the version stamp so the most reliable,
clearest place to set that value is in the installer build.

See above - not only the installer.

//Magnus

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Magnus Hagander (#1)

Magnus Hagander wrote:

I question whether any of us will remember to modify libpq.rc if you
happen to be making a new installer twice in the same beta. As a group
we forget even simpler things regularly. And we would be adding an
additional change for each beta and each RC for only the installer. I
am not inclined to add more work to a process that already is pretty
complex.

However, that is Marc's roll and he can answer whether he can do it
reliably. I am not involved in that process.

Is there any way to get it into the build process? The same place where
it builds the other files in interfaces/libpq that are used in the MSVC
build - the .def files. Perhaps the "last number" could be the cvs
version number of configure.in or something? (This may be way off, I
don't really know how those files are generated. But it should be
possible to do with some fairly sinmple sed magic, I would think.)

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.

My point is that installing from CVS will always overwrite libpq.dll in
/lib, so it doesn't care what the version stamp is in the binary. Only
the installer cares about the internal version stamp.

Right on the first. Wrong on the second.
Not "only the installer". *any* installer (if somebody embeds
postgresql). *any* deployment program (such as Systems Management
Server) used in an enteprise to distribute products. The "official MSI"
is just one of several possibilities. If we make it good enough it will
get rid of some others (for example, SMS could use it in silent mode to
install - but depending on corporate policy that may not be acceptable),
but there will be others.

I see. So you imagine other people building and doing installs,
especially client-only ones. That makes sense, though as I mentioned
above this does not work for VC or BCC builds, on MinGW.

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

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Bruce Momjian (#2)

Patch to add version numbers to libpq.rc

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.

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. VC and BCC aleady require a prepdist build so we should
be OK with having this built at that time always. 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.

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

Magnus Hagander

magnus@hagander.net

over 21 years ago

In reply to: Bruce Momjian (#3)

Re: Patch to add version numbers to libpq.rc

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

Import Notes

Resolved by subject fallback

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Magnus Hagander (#4)

Re: Patch to add version numbers to libpq.rc

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

Tom Lane

tgl@sss.pgh.pa.us

over 21 years ago

In reply to: Bruce Momjian (#5)

Re: [PATCHES] Patch to add version numbers to libpq.rc

Bruce Momjian <pgman@candle.pha.pa.us> 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

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Tom Lane (#6)

Re: [PATCHES] Patch to add version numbers to

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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?

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

Tom Lane

tgl@sss.pgh.pa.us

over 21 years ago

In reply to: Bruce Momjian (#7)

Re: [PATCHES] Patch to add version numbers to libpq.rc

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Tom Lane (#8)

Re: [PATCHES] Patch to add version numbers to

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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.

Really? If I touch a file and do a commit I don't see anything happen.
There might be a problem that cvs is going to check that file over and
over again when it doesn't need to and I certainly don't like the touch
solution.

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.

Oh, so make it dependent on a file derived from a configure run. New
patch attached.

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

#10

Tom Lane

tgl@sss.pgh.pa.us

over 21 years ago

In reply to: Bruce Momjian (#9)

Re: [PATCHES] Patch to add version numbers to libpq.rc

Bruce Momjian <pgman@candle.pha.pa.us> writes:

+ # Force rebuild on re-run of configure
+ $(srcdir)/libpq.rc: $(top_srcdir)/src/Makefile.global libpq.rc.in
+ 	sed -e 's/\(VERSION.*\),0 *$$/\1,'`date '+%y%j'`'/' < $< > $@

Put Makefile.global second, else $< refers to the wrong file.
Also, it has to be $(top_builddir)/src/Makefile.global, not top_srcdir.
The comment would probably be more useful if a little more verbose:
# depend on Makefile.global to force rebuild on re-run of configure

regards, tom lane

#11

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Tom Lane (#10)

Re: [PATCHES] Patch to add version numbers to

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:
+ # Force rebuild on re-run of configure
+ $(srcdir)/libpq.rc: $(top_srcdir)/src/Makefile.global libpq.rc.in
+ 	sed -e 's/$VERSION.*$,0 *$$/\1,'`date '+%y%j'`'/' < $< > $@
Put Makefile.global second, else $< refers to the wrong file.
Also, it has to be $(top_builddir)/src/Makefile.global, not top_srcdir.
The comment would probably be more useful if a little more verbose:
# depend on Makefile.global to force rebuild on re-run of configure

OK, new version attached with adjustments. I do like the
Makefile.global dependency idea!

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

#12

Bruce Momjian

bruce@momjian.us

over 21 years ago

In reply to: Bruce Momjian (#11)

Re: [PATCHES] Patch to add version numbers to

Applied, version attached. Magnus tested it.

---------------------------------------------------------------------------

Bruce Momjian wrote:

Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
+ # Force rebuild on re-run of configure
+ $(srcdir)/libpq.rc: $(top_srcdir)/src/Makefile.global libpq.rc.in
+ 	sed -e 's/$VERSION.*$,0 *$$/\1,'`date '+%y%j'`'/' < $< > $@
Put Makefile.global second, else $< refers to the wrong file.
Also, it has to be $(top_builddir)/src/Makefile.global, not top_srcdir.
The comment would probably be more useful if a little more verbose:
# depend on Makefile.global to force rebuild on re-run of configure
OK, new version attached with adjustments. I do like the
Makefile.global dependency idea!
-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

Re: Version numbers on libpq.dll

Attachments:

Attachments:

Attachments:

Attachments:

Attachments: