Обсуждение: libpq.rc make rule
The libpq.rc make rule says: # depend on Makefile.global to force rebuild on re-run of configure $(srcdir)/libpq.rc: libpq.rc.in $(top_builddir)/src/Makefile.global sed -e 's/\(VERSION.*\),0 *$$/\1,'`date '+%y%j'| sed 's/^0*//'`'/' < $< > $@ However, libpq.rc is also included in the distribution, so whenever a distribution is built, the distributed file would be overwritten, which is not a nice thing to do. Could someone explain what the requirement behind this is? The '+%y%j' changes every day. Why is libpq the only subsystem that needs a daily version number? -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Mon, Feb 25, 2008 at 7:21 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > The libpq.rc make rule says: > > # depend on Makefile.global to force rebuild on re-run of configure > $(srcdir)/libpq.rc: libpq.rc.in $(top_builddir)/src/Makefile.global > sed -e 's/\(VERSION.*\),0 *$$/\1,'`date '+%y%j' | sed 's/^0*//'`'/' < $< > $@ > > However, libpq.rc is also included in the distribution, so whenever a > distribution is built, the distributed file would be overwritten, which is > not a nice thing to do. > > Could someone explain what the requirement behind this is? The '+%y%j' > changes every day. Why is libpq the only subsystem that needs a daily > version number? It's used on Windows to ensure that installers can do the right thing when replacing a copy of libpq.dll. The daily build number was the most maintenance-free way of getting a fourth value for the version resource. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Dave Page wrote: > It's used on Windows to ensure that installers can do the right thing > when replacing a copy of libpq.dll. The daily build number was the > most maintenance-free way of getting a fourth value for the version > resource. Isn't that what the shared library version numbers are for? Do you need finer resolution than that? -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Mon, Feb 25, 2008 at 10:03 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > Dave Page wrote: > > It's used on Windows to ensure that installers can do the right thing > > when replacing a copy of libpq.dll. The daily build number was the > > most maintenance-free way of getting a fourth value for the version > > resource. > > Isn't that what the shared library version numbers are for? Do you need finer > resolution than that? Yes, because newer builds may be linked against updated runtime versions. We need to be sure the installer will upgrade the file so it definitely matches any runtimes (or other dependencies) that we're also installing/upgrading. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Dave Page wrote: > Yes, because newer builds may be linked against updated runtime > versions. We need to be sure the installer will upgrade the file so it > definitely matches any runtimes (or other dependencies) that we're > also installing/upgrading. If it is so very important to update this file for every build, why are we shipping it in the distribution tarball, which is done under the assumption that it never has to be updated? Something doesn't fit here. Also, does this theory apply to all shared libraries? What about the ecpg libraries? -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Mon, Feb 25, 2008 at 11:48 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > Dave Page wrote: > > Yes, because newer builds may be linked against updated runtime > > versions. We need to be sure the installer will upgrade the file so it > > definitely matches any runtimes (or other dependencies) that we're > > also installing/upgrading. > > If it is so very important to update this file for every build, why are we > shipping it in the distribution tarball, which is done under the assumption > that it never has to be updated? Something doesn't fit here. That I can't answer. > Also, does this theory apply to all shared libraries? What about the ecpg > libraries? All user-facing binaries should be affected, both executables and libraries. iirc, we don't bother with contrib dlls or conversion libraries etc as they are far less likely to cause problems. I can't help thinking there's something else I'm forgetting as well... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
On Tue, Feb 26, 2008 at 12:15:05AM +0000, Dave Page wrote: > On Mon, Feb 25, 2008 at 11:48 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > > Dave Page wrote: > > > Yes, because newer builds may be linked against updated runtime > > > versions. We need to be sure the installer will upgrade the file so it > > > definitely matches any runtimes (or other dependencies) that we're > > > also installing/upgrading. > > > > If it is so very important to update this file for every build, why are we > > shipping it in the distribution tarball, which is done under the assumption > > that it never has to be updated? Something doesn't fit here. > > That I can't answer. It is to make it possible to build libpq "the old way" using nmake or borland c++ - not requiring mingw or the perl stuff in src/tools/msvc. //Magnus