why not #include "config.h"?

[Steffen Dettmer-2]

I hope I don't ask a FAQ. If so, an URL would be appreciated.

I've read here that someone could (should?) write
  #include <config.h>
specifying a system header instead of the IMHO correct
  #include "config.h"

As far as I know the difference is that in the first version
system directories are searched but user directories in the
second.

Is this a kind of trick for something?
Is is guaranteed that all compilers search the user path after
the system path if the file was not found?

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Patrick Welche-4]

On Tue, Sep 22, 2009 at 10:49:58AM +0200, Steffen Dettmer wrote:

> I hope I don't ask a FAQ. If so, an URL would be appreciated.
>
> I've read here that someone could (should?) write
>   #include <config.h>
> specifying a system header instead of the IMHO correct
>   #include "config.h"
>
> As far as I know the difference is that in the first version
> system directories are searched but user directories in the
> second.
>
> Is this a kind of trick for something?
> Is is guaranteed that all compilers search the user path after
> the system path if the file was not found?

I think this is the relevant part of the autoconf info file:

4.9 Configuration Header Files
==============================
...
   To provide for VPATH builds, remember to pass the C compiler a `-I.'
option (or `-I..'; whichever directory contains `config.h').  Even if
you use `#include "config.h"', the preprocessor searches only the
directory of the currently read file, i.e., the source directory, not
the build directory.

   With the appropriate `-I' option, you can use `#include <config.h>'.
Actually, it's a good habit to use it, because in the rare case when
the source directory contains another `config.h', the build directory
should be searched first.


Cheers,

Patrick


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Tue, Sep 22, 2009 at 3:02 PM, Patrick Welche <prlw1@...> wrote:
> On Tue, Sep 22, 2009 at 10:49:58AM +0200, Steffen Dettmer wrote:
>> I've read here that someone could (should?) write
>>   #include <config.h>
>> specifying a system header instead of the IMHO correct
>>   #include "config.h"
>
> I think this is the relevant part of the autoconf info file:
> 4.9 Configuration Header Files
> ==============================

yeah, I knew this text (actually google did :)), but thought it
would be some mistake?

> ...
>   To provide for VPATH builds, remember to pass the C compiler a `-I.'
> option (or `-I..'; whichever directory contains `config.h').  Even if
> you use `#include "config.h"', the preprocessor searches only the
> directory of the currently read file, i.e., the source directory, not
> the build directory.
>
>   With the appropriate `-I' option, you can use `#include <config.h>'.
> Actually, it's a good habit to use it, because in the rare case when
> the source directory contains another `config.h', the build directory
> should be searched first.

I though this was a kind of lazyness; just used "" and <>
interchangingly without deeper meaning?

I tought correct is:

- with -I (and gcc), #include "config.h" is correct and works

- 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

- if #include <config.h> is really desired, I think for gcc it
  would be correct to use -isystem $(top_builddir)

- for other compilers, -I often is -I but -isystem can be -j

- other compilers may not distinguish that much or that flexible
  or not configurable where <file.h> is searched

- on other compilers, #include <config.h> may not even work
  (when they use a fixed system directory and support no fallback
  search to user directories)

Could * please correct my assumptions?

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Steffen Dettmer wrote on Tue, Sep 22, 2009 at 05:06:41PM CEST:
> I though this was a kind of lazyness; just used "" and <>
> interchangingly without deeper meaning?

You can do that only as long as there is at most one header file with
that name involved.

> I tought correct is:
>
> - with -I (and gcc), #include "config.h" is correct and works
>
> - 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.

> - if #include <config.h> is really desired, I think for gcc it
>   would be correct to use -isystem $(top_builddir)

No, don't use -isystem.  It is not intended for this situation.

> - for other compilers, -I often is -I but -isystem can be -j

-I is accepted by all unixoid compilers, not just GCC.  -isystem
is not standardized.

> - 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.

> - on other compilers, #include <config.h> may not even work
>   (when they use a fixed system directory and support no fallback
>   search to user directories)

Again, do you have examples?

> Could * please correct my assumptions?

Quoting the SUSv3 manpage for c99:

 -I  directory
      Change the algorithm for searching for headers whose names are not
      absolute pathnames to look in the directory named by the directory
      pathname before looking in the usual places. Thus, headers whose names
      are enclosed in double-quotes ( "" ) shall be searched for first in the
      directory of the file with the #include line, then in directories named
      in -I options, and last in the usual places. For headers whose names are
      enclosed in angle brackets ( "<>" ), the header shall be searched for
      only in directories named in -I options and then in the usual places.
      Directories named in -I options shall be searched in the order
      specified. Implementations shall support at least ten instances of this
      option in a single c99 command invocation.

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.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Thomas Dickey-2]

On Tue, 22 Sep 2009, Patrick Welche wrote:

> On Tue, Sep 22, 2009 at 10:49:58AM +0200, Steffen Dettmer wrote:
>> I hope I don't ask a FAQ. If so, an URL would be appreciated.
>>
>> I've read here that someone could (should?) write
>>   #include <config.h>
>> specifying a system header instead of the IMHO correct
>>   #include "config.h"
...

> 4.9 Configuration Header Files
> ==============================
> ....
>   To provide for VPATH builds, remember to pass the C compiler a `-I.'
> option (or `-I..'; whichever directory contains `config.h').  Even if
> you use `#include "config.h"', the preprocessor searches only the
> directory of the currently read file, i.e., the source directory, not
> the build directory.
>
>   With the appropriate `-I' option, you can use `#include <config.h>'.
> Actually, it's a good habit to use it, because in the rare case when
> the source directory contains another `config.h', the build directory
> should be searched first.

It doesn't mention the fact that the choice of starting directory for a
nested include using quotes depends upon the compiler (the C standard
leaves this as implementation-defined).  Given the source, it's
understandable that it only provides a comment specific to gcc - however,
that's the actual reason for preferring bracketed includes.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

Hi,

thank you for the detailed explanations.

It seems my assumption (which could be a common one) that <> are
for system includes and "" are for user includes, essentially is
wrong.

If I looked to the rigth place, the standard (ISO/IEC 9899:TC3
page 161) does not specify how this works (if I understand
correctly):

   # include <h-char-sequence> new-line
  searches a sequence of implementation-defined places for a
  header identified uniquely by the specified sequence between
  the < and > delimiters, and causes the replacement of that
  directive by the entire contents of the header

    # include "q-char-sequence" new-line
  causes the replacement of that directive by the entire contents
  of the source file identified by the specified sequence between
  the " delimiters. The named source file is searched for in an
  implementation-defined manner.

On Tue, Sep 22, 2009 at 10:35 PM, <Ralf.Wildenhues@...> 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.

>> - if #include <config.h> is really desired, I think for gcc it
>>   would be correct to use -isystem $(top_builddir)
>
> No, don't use -isystem.  It is not intended for this situation.

(yes sure, was an example only)

>> - 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).

I tested now gcc-2, gcc-3, gcc-4, CL.EXE-12, tcc 1.21 and all
work as you describe.

So at least in all practical relevant situations the
"implementation-defined places" of <> do work and have nothing to
do with system directories.

>> - on other compilers, #include <config.h> may not even work
>>   (when they use a fixed system directory and support no fallback
>>   search to user directories)
>
> Again, do you have examples?

I though even tcc, but I was wrong, at least for config.h. With
tcc a thing is that you can include e.g. string.h even if no such
file exists anywhere (built-in).

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.

> > Could * please correct my assumptions?
>
> Quoting the SUSv3 manpage for c99:

Thanks for this citation. So it seems what I considered "system
and user directories" actually is "-I specified directories and
the directory where the compiled file is in".

> 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.

Thanks a lot for you nice explanation. Now I will tell my team mates :-)

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* 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.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Sun, Sep 27, 2009 at 9:43 AM <Ralf.Wildenhues@...> wrote:
> * Steffen Dettmer wrote on Wed, Sep 23, 2009 at 11:26:33AM CEST:
> > On Tue, Sep 22, 2009 at 10:35 PM, wrote:
> > > Not AFAIK.  It works because automake adds -I. by default.
> >
> > Yes, unfortunately it adds it.
>
> You can avoid that with the 'nostdinc' option.

Ahh, now I see, it is an automake option, too; ok, thanks :)

> 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.

well... happy debugging in case something wents wrong :)
Maybe this was some system supporting some other build mechanism
beside autoconf.
  BTW, we had this in the past too. But when it is getting
  non-trivial (auto generated sources, libs with conditionals,
  dynamic things, "strange special steps that are needed"...) all
  "build environments" we used - except autoconf/automake - failed.

Thanks again for the explantions! It is very helpful.

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf