Bruce Momjian <br...@momjian.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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers