On Sun, Sep 16, 2012 at 11:52 AM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Gurjeet Singh <
singh.gurjeet@gmail.com> writes:
> I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
> directly or indirectly.
postgres.h or postgres_fe.h (as appropriate) first;
Thankfully, this IDE provides for me to specify preprocessor directives that are processed before parsing any source files, so it was easy for me to #include "c.h" in every file.
So, that solved the problem for me, but other IDEs may not be so flexible.
I understand that I am supposed to include postgres.h in backend files, and postgres_fe.h in frontend files, like those of psql, pg_dump, ecpg, etc., but I didn't bother with that for now. If I proceed with this IDE, then I think it'll make sense to have a project per client program, so that I can include postgres_fe.h for those projects, and postgres.h for the main backend project.
and practically
all of them have far more dependencies on that than you mention here.
If we were to decorate them with explicit inclusions such as you propose,
we would accomplish little except to bloat the sources and slow down
compilation.
True, it would affect the compilation times, but I think if one is using ccache, then they would be sheilded from this on second and subsequent runs.
The general rule about that is "thou shalt have no other gods before
c.h" --- that is, it is *necessary* that c.h be included before anything
else, in *every* Postgres file. Otherwise you can run into
platform-specific problems. An example I remember is individual files
having different ideas of whether 64-bit or 32-bit filesystem APIs are
in use, as a consequence of <stdio.h> being read before pg_config_os.h
has defined symbols controlling that. Needless to say, this doesn't
work well at runtime. You can find actual examples of that sort of
thing in the archives from years ago, before we began to enforce the
rule rigidly.
I'm glad that we have this rule in place.