Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Actually, I believe that the *main* problem with pgrminclude is that
> >> it fails to account for combinations of build options other than those
> >> that Bruce uses. In the previous go-round, the reason we were still
> >> squashing bugs months later is that it took that long for people to
> >> notice and complain "hey, compiling with LOCK_DEBUG no longer works",
> >> or various other odd build options that the buildfarm doesn't exercise.
> >> I have 100% faith that we'll be squashing some bugs like that ... very
> >> possibly, the exact same ones as five years ago ... over the next few
> >> months. Peter's proposed tool would catch issues like the CppAsString2
> > The new code removes #ifdef markers so all code is compiled, or the file
> > is skipped if it can't be compiled. That should avoid this problem.
> It avoids it at a very large cost, namely skipping all the files where
> it's not possible to compile each arm of every #if on the machine being
> used. I do not think that's a solution, just a band-aid; for instance,
> won't it prevent include optimization in every file that contains even
> one #ifdef WIN32? Or what about files in which there are #if blocks
> that each define the same function, constant table, etc?
> The right solution would involve testing each #if block under the
> conditions in which it was *meant* to be compiled.
Right. It is under the "better than nothing" category, which is better
than nothing (not running it). ;-)
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ It's impossible for everything to be true. +
In response to
pgsql-hackers by date
|Next:||From: Martijn van Oosterhout||Date: 2011-09-24 17:37:52|
|Subject: Re: Re: memory barriers (was: Yes, WaitLatch is
vulnerable to weak-memory-ordering bugs)|
|Previous:||From: Andrew Dunstan||Date: 2011-09-24 17:17:58|
|Subject: Re: Large C files|