Re: Large C files

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
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +