improving on pgrminclude / pgcompinclude ?
От | Robert Haas |
---|---|
Тема | improving on pgrminclude / pgcompinclude ? |
Дата | |
Msg-id | CA+TgmoboL1YJiw=sjn5wZnNKb=z9q3Gu28c32Kz-0az2_Vi4cA@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: improving on pgrminclude / pgcompinclude ?
|
Список | pgsql-hackers |
Amit's complaint about unnecessary headers got me thinking about src/tools/pginclude. I think the the stuff in this directory is trying to do something useful, because I think extra #include directives that we don't need are a useful thing to eliminate. However, in practice the contents are very hard for anybody to use except maybe Bruce, who wrote it with his own environment in mind. On my system, any attempt to rerun pgcompinclude -- which is described as a prerequisite to running pgrminclude -- produces enormous numbers of bogus errors and warnings, both because of the attempt to call every defined macro with made-up arguments and because I configure with stuff like --with-includes=/opt/local/include which pgcompinclude knows nothing about. I wonder if we can do better. The attached patch is the rest of a couple of hours of hacking on a "see whether all of our includes compile separately" project. Directions: 1. configure 2. go to src/tools/pginclude 3. make test-compile-include It strikes me that if we could make this robust enough to include in the buidlfarm, that would be good. And maybe we could then have a pgrminclude tool which is a bit smarter also, and something that anyone can easily run. I don't think pgrminclude should be part of the buildfarm, but being able to run it every release cycle with relatively minimal pain instead of every 5 years with extensive fallout seems like it would be a win. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: