Обсуждение: Re: [COMMITTERS] pgsql: Sigh ...

Andrew Dunstan <andrew@dunslane.net> writes:
> This fix is surely wrong for several reasons:
> . the configure changes only broke MSVC builds, not all Windows builds 
> (see narwhal, for example), but this change applies to both.
> . fixing a change that adds a configure option by hardcoding it in 
> pg_config.h.win32 is simply the wrong fix - the right fix is to add the 
> equivalent logic to src/tools/Solution.pm.

Well, maybe the right answer is to take a step back and figure out what
pg_config.h.win32's excuse for living is at all.  I do not understand
our Windows configuration setup, and what I do understand is is that
it's a pile of horrid kluges that break anytime anyone looks at them
sideways.

I will be quite happy to never touch any Windows configuration stuff
again.  If you want me to, you had better redesign and/or document it
so that people other than you and Magnus have some idea of what connects
to what.
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> This fix is surely wrong for several reasons:
>> . the configure changes only broke MSVC builds, not all Windows builds 
>> (see narwhal, for example), but this change applies to both.
>> . fixing a change that adds a configure option by hardcoding it in 
>> pg_config.h.win32 is simply the wrong fix - the right fix is to add the 
>> equivalent logic to src/tools/Solution.pm.
>>     
>
> Well, maybe the right answer is to take a step back and figure out what
> pg_config.h.win32's excuse for living is at all.  I do not understand
> our Windows configuration setup, and what I do understand is is that
> it's a pile of horrid kluges that break anytime anyone looks at them
> sideways.
>
> I will be quite happy to never touch any Windows configuration stuff
> again.  If you want me to, you had better redesign and/or document it
> so that people other than you and Magnus have some idea of what connects
> to what.
>
>             
>   

Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the 
mistake about that.

However, all the values are hardcoded, so nothing in it should relate to 
settings that come from configure, I believe. These should be dealt with 
in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Well, maybe the right answer is to take a step back and figure out what
>> pg_config.h.win32's excuse for living is at all.

> Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the 
> mistake about that.

Well, I'm still wondering why it is an input for MSVC.  If we have a
configure substitute for MSVC, why isn't it working off pg_config.h.in?

The original idea of pg_config.h.win32 was to support the pre-8.0
method for building native libpq.dll.  I'd like to see us obsolete that
method altogether and get rid of pg_config.h.win32.

> However, all the values are hardcoded, so nothing in it should relate to 
> settings that come from configure, I believe. These should be dealt with 
> in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).

FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_SIZE
into the domain of configurable stuff, too.
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> Tom Lane wrote:
>>     
>>> Well, maybe the right answer is to take a step back and figure out what
>>> pg_config.h.win32's excuse for living is at all.
>>>       
>
>   
>> Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the 
>> mistake about that.
>>     
>
> Well, I'm still wondering why it is an input for MSVC.  If we have a
> configure substitute for MSVC, why isn't it working off pg_config.h.in?
>
> The original idea of pg_config.h.win32 was to support the pre-8.0
> method for building native libpq.dll.  I'd like to see us obsolete that
> method altogether and get rid of pg_config.h.win32.
>   


That makes sense - I'll look at that after I have cleaned up the current 
stuff.

>   
>> However, all the values are hardcoded, so nothing in it should relate to 
>> settings that come from configure, I believe. These should be dealt with 
>> in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).
>>     
>
> FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_SIZE
> into the domain of configurable stuff, too.
>
>             
>   

So I gathered. I'll pick those up as part of the fixes I'm currently coding.

cheers

andrew