Good, added to pginclude/README:
Also, tests should be done with configure settings of --enable-cassert
and EXEC_BACKEND on and off.
I think we had more problems this time just because our code is more
complex.
FYI, I updated pginclude/README to explain the complexity of
removing includes from include files:
pgfixinclude
sort include references
run multiple times:
pgcompinclude
pgrminclude /src/include
pgrminclude /
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, 527 include were removed from non-header C files in this run. That
is not something that can be easily done manually.
It's not so easily done automatically, either :-(. I'm not sure why
this go-round was so much more painful than the last, but it
Tom Lane wrote:
In combination with the amount of time wasted over the past two days,
it is now perfectly clear that the existing pginclude tools are not
NEARLY good enough to detect what they are breaking. I would like to
propose that we revert all the include-related changes of the past two
Andrew Dunstan [EMAIL PROTECTED] writes:
I agree with reverting. The tool looks pretty broken anyway, with
hardcoded paths and all sorts of stuff quite apart from logic problems.
Well, it's only intended to work on Bruce's system, so until someone
else takes over the position of chief
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I agree with reverting. The tool looks pretty broken anyway, with
hardcoded paths and all sorts of stuff quite apart from logic problems.
Well, it's only intended to work on Bruce's system, so until someone
else takes over the
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote:
After some reflection it seems that there is only one case where removal
of a needed include file would not lead to a compiler error or warning,
assuming gcc with
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I agree with reverting. The tool looks pretty broken anyway, with
hardcoded paths and all sorts of stuff quite apart from logic problems.
Well, it's only intended to work on Bruce's system, so
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, one of the remaining holes in pgrminclude is that it compiles with
-fsyntax-only, which apparently causes it to fail to detect some errors
of significance --- I assume that's how it managed to foul up lmgr.c,
On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote:
After some reflection it seems that there is only one case where removal
of a needed include file would not lead to a compiler error or warning,
assuming gcc with ordinary -W settings (notably -Wmissing-prototypes).
That case is exactly
On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote:
I would like to propose that we revert all the include-related changes
of the past two days, and that src/tools/pginclude be removed from the
CVS tree, until such time as it is rewritten to be much smarter about
what it is doing.
Rather than
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, one of the remaining holes in pgrminclude is that it compiles with
-fsyntax-only, which apparently causes it to fail to detect some errors
of significance --- I assume that's how it managed to foul up lmgr.c,
inet_net_ntop.c, etc.
Martijn van Oosterhout kleptog@svana.org writes:
On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote:
After some reflection it seems that there is only one case where removal
of a needed include file would not lead to a compiler error or warning,
assuming gcc with ordinary -W settings
Neil Conway [EMAIL PROTECTED] writes:
On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote:
I would like to propose that we revert all the include-related changes
of the past two days, and that src/tools/pginclude be removed from the
CVS tree, until such time as it is rewritten to be much smarter
14 matches
Mail list logo
