Feedback on -iquote

[Carlo Wood <carlo at alinoe dot com>]

Perhaps a bit late - but I just now ran into this change.

Quoted from http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00154.html

<quote>
  In GCC 3.5, we are considering replacing the -I- command line option
  with a new -iquote option.

  The -I- option had two effects.  It caused all -I switches earlier
  on the command line to be considered only for headers included with
  #include "file" (not #include <file>), and it disabled the normal
  behavior of searching the directory containing the current file for
  headers included with #include "file".

  The proposed -iquote option, by contrast, simply takes its argument
  as a directory to search for headers included with #include "file".
  The directory containing the current file is still searched first.
  There would no longer be any way to disable that behavior.

  We are considering this change because some of our users have asked
  us for a way to augment the set of directories searched for
  #include "file", without suppressing the directory containing the
  current file.  It is our belief that that suppression is not
  useful in practice, because it tends to break system headers.  We
  would like to hear whether this is true.

  Please send comments on this issue to <gcc@gcc.gnu.org>.
</quote>

I have, and used, the following setup:

A library (libcw, under development) has two (directory) levels:

  ...src/include

which contains the headers needed to compile the library itself,
but which are not needed to compile something that uses the library.

  ...src/include/libcw

which contains all headers that will be install, that are needed
by the user.  The user would use #include <libcw/headername.h>
rather than #include <headername.h> for obvious reasons (the install
is done to PREFIX/include/libcw thus.)

Some headers in include/libcw need other headers, so - also these
headers contain #include <libcw/headername.h>.

However, as per design since many years now - I have released already
34 versions (used by hunderds of developers) of a library called libcwd
that uses as convention that, in order to get the canonical debug
declarations one must include "debug.h".  This file is then a user-
defined header.  libcwd has been set up in a way that it can be
used by arbitrary (other) libraries - and also in that case these
need to follow the same convention and #include "debug.h".

As a result, I am having two 'debug.h' files:

  ...src/include/debug.h

The "debug.h" that should be used while compiling the library itself
(which in turn does an #include <libcw/debug.h>), and

  ...src/include/libcw/debug.h

Which should *ONLY* be included when there is a #include <libcw/debug.h>,
and never when there is a #include "debug.h" -- because the latter should
refer to either a user defined header, or the library-is-compiling itself
header.

The headers in src/include/libcw need to include "debug.h" however,
because they don't know (normally) if they are being included by a user
or not.

The problem that arises with the -iquote change is now that suddenly a
#include "debug.h" in a header inside ...src/include/libcw is including
the <libcw/debug.h> file instead of the 'custom' "debug.h" :/

The only way this can be "solved" is by renaming the header in
include/libcw, but I really don't like that :(.

Another "solution" might be to introduce a macro COMPILING_THE_LIBRARY_ITSELF_NOW
and have libcw/debug.h include "../debug.h" when that macro is set and
the gard macro of ../debug.h is not set yet.  Not very neat.

In other words, I don't like this change and I protest ;).

-- 
Carlo Wood <carlo@alinoe.com>

PS Please CC me.

PS2 CC To libcwd-devel in the hope of ideas to fix this (now) design problem;
    if you reply from this list then please remove gcc@gcc.gnu.org.