Horton

Re: narwhal and PGDLLIMPORT

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Janes <jeff.janes@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-04T23:02:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. MinGW: Link with shell32.dll instead of shfolder.dll.

  2. Centralize getopt-related declarations in a new header file pg_getopt.h.

  3. Get rid of use of dlltool in Mingw builds.

  4. Export a few more symbols required for test_shm_mq module.

  5. Export set_latch_on_sigusr1 symbol for Windows.

  6. Use SHGetFolderPath instead of SHGetSpecialFolderPath to find the

On 02/04/2014 05:47 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 02/04/2014 03:08 PM, Jeff Janes wrote:
>>> Having an AMI would help, but even with an AMI in place, MinGW is
>>> still insanely slow.  Running "make" on already made PostgreSQL (so
>>> there was nothing to actually do) takes 1.5 minutes.  And a make after
>>> a "make clean" takes half an hour.  This is on an actual desktop, not
>>> an AWS micro instance.  So doing a git bisect is just painful.  Is the
>>> MSVC build faster?
>> Would have to check with the same build options (cassert and debug have
>> major timing effects.) I agree it's not lightning fast like "make -j 4"
>> on a decent linux box.
> I wonder if ccache exists for Mingw.  That thing makes a huge difference
> in the perceived build speed ...
>
> 			


Indeed. But it's not really, AFAIK. Certainly it's not in the list of 
packages known to mingw-get on the machine i checked on (jacana).

cheers

andrew