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.
> failure, but it's still only going to exercise the build options you're
> testing with.
>
> If we could get pgrminclude up to a similar level of reliability as
> pgindent, I'd be for running it on every cycle. But I'm not sure that
> the current approach to it is capable even in theory of getting to "it
> just works" reliability. I'm also not impressed at all by the hack of
> avoiding problems by excluding entire files from the processing ---
> what's the point of having the tool then?
We remove the includes we safely can, and skip the others --- the
benefit is only for the files we can process.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +