With most of the Win32 code done, I expected this type of review to see
how we could clean things up further. It would probably be helpful for
folks to poke around and suggest cases where we can generalize or move
things to /port or /backend/port.
> I'm not expecting to see zero ifdefs --- certainly not in the port
> modules ;-). But Bruce's search, further up in the thread, showed that
> #ifdef WIN32's are sneaking into a lot of modules that probably
> shouldn't have any platform dependencies.
For the most part, I disagree (in fact, I
On Thu, Mar 25, 2004 at 07:57:19PM -0500, Tom Lane wrote:
> I'm not expecting to see zero ifdefs --- certainly not in the port
> modules ;-). But Bruce's search, further up in the thread, showed that
> #ifdef WIN32's are sneaking into a lot of modules that probably
> shouldn't have any platform d
Tom Lane said:
>
> I'm not expecting to see zero ifdefs --- certainly not in the port
> modules ;-). But Bruce's search, further up in the thread, showed that
> #ifdef WIN32's are sneaking into a lot of modules that probably
> shouldn't have any platform dependencies. I don't think that's a good
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Every "#ifdef WIN32" I see reduces my opinion of the quality of work
>> being done for this port.
> At risk of getting (further? :-) on your bad side, IMHO that is a specious
> metric.
Well, it's surely not the only interesting metri
Tom Lane wrote:
> If the problem is that we need PKGLIBDIR not to be frozen at compile
> time, then let's fix the problem for everybody, not add a pile of
> undocumented #ifdef WIN32 hacks. (And it is a problem for everybody;
Happy to go with whatever you can suggest. However, will point out tha
Andrew Dunstan wrote:
> >Every "#ifdef WIN32" I see reduces my opinion of the quality of work
> >being done for this port.
> >
> >
> >
>
> Tom,
>
> I think in defense of Claudio and company, it should be noted that there
> has been a desire not to disturb existing functionality more than
>
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> writes:
Supplement to previous win32 patch for dfmgr. Win32 replacement for
configure time constants like PKGLIBDIR.
This is exactly the sort of cruft I was hoping we would not get saddled
with by a Windows port.
If the problem is that we
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Supplement to previous win32 patch for dfmgr. Win32 replacement for
> configure time constants like PKGLIBDIR.
This is exactly the sort of cruft I was hoping we would not get saddled
with by a Windows port.
If the problem is that we need PKGLIBDIR not
Peter Eisentraut said:
> Claudio Natoli wrote:
>> For application to HEAD, following community review.
>>
>> Supplement to previous win32 patch for dfmgr. Win32 replacement for
>> configure time constants like PKGLIBDIR.
>
> + /*
> + * Determine the directory of installed files, on the assumption
Claudio Natoli wrote:
> For application to HEAD, following community review.
>
> Supplement to previous win32 patch for dfmgr. Win32 replacement for
> configure time constants like PKGLIBDIR.
+ /*
+ * Determine the directory of installed files, on the assumption that
+ * win32 will have a common
11 matches
Mail list logo
