Clean up MinGW def file generation
I was mystified by this comment in Makefile.shlib:
# We need several not-quite-identical variants of .DEF files to build
# DLLs for Windows. These are made from the single source file
# exports.txt. Since we can't assume that Windows boxes will have
# sed, the .DEF files are always built and included in distribution
# tarballs.
ifneq (,$(SHLIB_EXPORTS))
distprep: lib$(NAME)dll.def lib$(NAME)ddll.def
...
This doesn't make much sense (anymore?) since MinGW surely has sed and
MSVC doesn't use this (and has Perl). I think this is a leftover from
various ancient client-only ad-hoc Windows build provisions (those
win32.mak files we used to have around). Also, the ddll.def (debug
build) isn't used by anything anymore AFAICT.
I think we can clean this up and just have the regular ddl.def built
normally at build time if required.
Does anyone know more about this?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Clean-up-MinGW-def-file-generation.patchtext/plain; charset=UTF-8; name=0001-Clean-up-MinGW-def-file-generation.patch; x-mac-creator=0; x-mac-type=0Download+13-36
On Tue, Oct 15, 2019 at 09:00:23AM +0200, Peter Eisentraut wrote:
This doesn't make much sense (anymore?) since MinGW surely has sed and
MSVC doesn't use this (and has Perl). I think this is a leftover from
various ancient client-only ad-hoc Windows build provisions (those
win32.mak files we used to have around). Also, the ddll.def (debug
build) isn't used by anything anymore AFAICT.
sed is present in MinGW for some time, at least 2009 if you look here:
https://sourceforge.net/projects/mingw/files/MSYS/Base/sed/
Cygwin also includes sed, so this cleanup makes sense.
I think we can clean this up and just have the regular ddl.def built
normally at build time if required.Does anyone know more about this?
This comes from here, but I cannot see a thread about this topic
around this date:
commit: a1d5d8574751d62a039d8ceb44329ee7c637196a
author: Peter Eisentraut <peter_e@gmx.net>
date: Tue, 26 Feb 2008 06:41:24 +0000
Refactor the code that creates the shared library export files to appear
only once in Makefile.shlib and not in four copies.
--
Michael
On 2019-Oct-17, Michael Paquier wrote:
On Tue, Oct 15, 2019 at 09:00:23AM +0200, Peter Eisentraut wrote:
I think we can clean this up and just have the regular ddl.def built
normally at build time if required.Does anyone know more about this?
This comes from here, but I cannot see a thread about this topic
around this date:
commit: a1d5d8574751d62a039d8ceb44329ee7c637196a
author: Peter Eisentraut <peter_e@gmx.net>
date: Tue, 26 Feb 2008 06:41:24 +0000
Refactor the code that creates the shared library export files to appear
only once in Makefile.shlib and not in four copies.
Well, yes, but that code originates from much earlier. For example
2a63c1602d9d (Tom Lane, Oct. 2004) is the one that created the libpq
ones. But even that ancient one seems to be just refactoring some stuff
that was already there, namely something that seems to have been created
by commit 53cd7cd8a916:
commit 53cd7cd8a9168d4b2e2feb52129336429cc99b98
Author: Bruce Momjian <bruce@momjian.us>
AuthorDate: Tue Mar 9 04:53:37 2004 +0000
CommitDate: Tue Mar 9 04:53:37 2004 +0000
Make a separate win32 debug DLL along with the non-debug version:
Currently, src/interfaces/libpq/win32.mak builds a statically-linked
library "libpq.lib", a debug dll "libpq.dll", import library for the
debug dll "libpqdll.lib", a release dll "libpq.dll", import library for
the release dll "libpqdll.lib". To avoid naming clashes, I would make
the debug dll and import libraries "libpqd.dll" and "libpqddll.lib".
Basically, the debug build uses the cl flags: "/MDd /D _DEBUG", and the
release build uses the cl flags "/MD /D NDEBUG". Usually the debug
build has a "D" suffix on the file name, so for example:
libpqd.dll libpq, debug build
libpqd.lib libpq, debug build, import library
libpq.dll libpq, release build
libpq.lib libpq, release build, import library
David Turner
This stuff was used by win32.mak, but I don't know if that tells anyone
anything.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2019-Oct-17, Michael Paquier wrote:
On Tue, Oct 15, 2019 at 09:00:23AM +0200, Peter Eisentraut wrote:
I think we can clean this up and just have the regular ddl.def built
normally at build time if required.
Does anyone know more about this?
Well, yes, but that code originates from much earlier. For example
2a63c1602d9d (Tom Lane, Oct. 2004) is the one that created the libpq
ones.
Yeah, the comment that Peter complained about is mine. I believe the
desire to avoid depending on "sed" at build time was focused on our
old support for building libpq with Borland C (and not much else).
Since this makefile infrastructure is now only used for MinGW, I agree
we ought to be able to quit shipping those files in tarballs.
I think there could be some .gitignore cleanup done along with this.
Notably, I see exclusions for /exports.list in several places, but no
other references to that name --- isn't that an intermediate file that
we used to generate while creating these files?
regards, tom lane
On 2019-10-18 15:00, Tom Lane wrote:
Yeah, the comment that Peter complained about is mine. I believe the
desire to avoid depending on "sed" at build time was focused on our
old support for building libpq with Borland C (and not much else).
Since this makefile infrastructure is now only used for MinGW, I agree
we ought to be able to quit shipping those files in tarballs.
Yeah, it all makes sense now. I have committed my patch now.
I think there could be some .gitignore cleanup done along with this.
Notably, I see exclusions for /exports.list in several places, but no
other references to that name --- isn't that an intermediate file that
we used to generate while creating these files?
exports.list is built from exports.txt on non-Windows platforms and
AFAICT it is not cleaned up as an intermediate file. So I think the
current arrangement is correct.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-10-20 10:26, Peter Eisentraut wrote:
On 2019-10-18 15:00, Tom Lane wrote:
Yeah, the comment that Peter complained about is mine. I believe the
desire to avoid depending on "sed" at build time was focused on our
old support for building libpq with Borland C (and not much else).
Since this makefile infrastructure is now only used for MinGW, I agree
we ought to be able to quit shipping those files in tarballs.Yeah, it all makes sense now. I have committed my patch now.
Very related, I believe the file libpq-dist.rc is also obsolete; see
attached patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Remove-libpq-dist.rc.patchtext/plain; charset=UTF-8; name=0001-Remove-libpq-dist.rc.patch; x-mac-creator=0; x-mac-type=0Download+1-8
On 2019-10-21 00:07, Peter Eisentraut wrote:
On 2019-10-20 10:26, Peter Eisentraut wrote:
On 2019-10-18 15:00, Tom Lane wrote:
Yeah, the comment that Peter complained about is mine. I believe the
desire to avoid depending on "sed" at build time was focused on our
old support for building libpq with Borland C (and not much else).
Since this makefile infrastructure is now only used for MinGW, I agree
we ought to be able to quit shipping those files in tarballs.Yeah, it all makes sense now. I have committed my patch now.
Very related, I believe the file libpq-dist.rc is also obsolete; see
attached patch.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services