Tom Lane wrote: > 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.
Right. It is under the "better than nothing" category, which is better than nothing (not running it). ;-) -- 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
