Обсуждение: 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

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

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