[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why not #include "config.h"?

From: Ralf Wildenhues
Subject: Re: why not #include "config.h"?
Date: Sun, 27 Sep 2009 09:43:06 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

* Steffen Dettmer wrote on Wed, Sep 23, 2009 at 11:26:33AM CEST:
> On Tue, Sep 22, 2009 at 10:35 PM, wrote:
> > * Steffen Dettmer wrote on Tue, Sep 22, 2009 at 05:06:41PM CEST:
> > > - with -I (and gcc), #include <config.h> is not correct but works
> > >   anyway, because gcc searches system headers in user directories
> > >   if it was not found in system directories
> >
> > Not AFAIK.  It works because automake adds -I. by default.
> Yes, unfortunately it adds it.

You can avoid that with the 'nostdinc' option.

> >> - other compilers may not distinguish that much or that flexible
> >>   or not configurable where <file.h> is searched
> >
> > Which compiler(s) are you thinking of?  Thanks.
> If I remember correctly, KEILs C51 COMPILER X4.13 (also 3.07,
> 5.02 and 6.14) had some limitations like that. I couldn't test
> because at the moment I don't have a dongle here, because not
> using it at the moment (and was never used with autoconf anyway).

Well, if it's feasible to use for portable software, and used widely
enough, one can think about whether it's easier to write a compiler
wrapper (that works the way autotools expect) or extend autotools to
cope with the compiler oddities.  (Getting the test suites of Autoconf
and Automake to pass with this compiler is a good strategy.)

> We had issues with a platform (toolchain) that had a config.h in
> system includes (right beside string.h and so on). In the end we
> renamed it and patched the include files to use the new name.

Yes, this can be a problem, if the public system headers include that
config.h somewhere.

> > This means,
> >  #include "config.h"
> >
> > would, even with
> >  c99 -I. -I$(srcdir) -c $(srcdir)/foo.c
> >
> > try to open $(srcdir)/config.h before trying to open ./config.h.  That
> > would be wrong, however unlikely it would be to have config.h files in
> > both the build and the source tree.
> Is this just unlikely? I though it would be forbidden, because
> then it would be required to build with builddir != srcdir but I
> though this is optional? Well, but a detail only.

I haven't seen a report with config.h, but IIRC there was at least one
report where a package relied on another header to be searched in the
build tree before picking up the default version of the header in the
source tree.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]