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(at)gmx(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)gmx(dot)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