Thread: 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