Re: narwhal and PGDLLIMPORT

On 13/02/2014 00:17, Craig Ringer wrote:
> On 02/13/2014 12:39 AM, Tom Lane wrote:
>> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>>> On 2014-02-12 11:26:56 -0500, Tom Lane wrote:
>>>> Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT,
>>>> we ought to actually remove that, so that the Cygwin build works more like
>>>> the other Windows builds?
>>
>>> Hm, I don't see a big advantage in detecting the errors as It won't
>>> hugely increase the buildfarm coverage. But --auto-import seems to
>>> require marking the .text sections as writable, avoiding that seems to
>>> be a good idea if we don't need it anymore.
>>
>> Given the rather small number of Windows machines in the buildfarm,
>> I'd really like them all to be on the same page about what's valid
>> and what isn't. Having to wait ~24 hours to find out if they're
>> all happy with something isn't my idea of a good time. In any case,
>> as long as we have discrepancies between them, I'm not going to be
>> entirely convinced that any of them are telling the full truth.
>>
>> I'm going to go remove that switch and see if brolga starts failing.
>> If it does, I'll be satisfied that we understand the issues here.
>
> I wouldn't assume that _anything_ Cygwin does makes sense, or is
> consistent with anything else.

Of course, I disagree ;-)

> Its attempts to produce UNIX-like behaviour on Windows cause some truly
> bizarre behaviour at times.

unfortunately our baseground (Windows) is limiting us.

> It is not totally unfair to compare the level of weirdness of Cygwin to
> that of WINE, though they operate in completely different ways. I
> wouldn't suggest making any conclusions about the _other_ platforms
> based on Cygwin.

My personal experience is that a UNIX-vanilla source build 99% right
on recent cygwin.
The problem with postgreql make/build system is that it tries to guess
platform behavior and that is not fix in time.
Porting a new platform to postgresql from scratch will be a
very hard effort

Automake/Autoconf makes it much more simple; as its aim is to
test features not platforms.
Cmake also makes it right, now. We teach it that cygwin is a unix
platform not a win32 platform

I am biased, of course.

Marco