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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
