diff mbox

PATCH RFA: New configure option --with-native-system-header-dir

Message ID mcrzkhcbftp.fsf@coign.corp.google.com
State New
Headers show

Commit Message

Ian Lance Taylor Oct. 7, 2011, 10:24 p.m. UTC
I would like to bring Simon's patch for the
--with-native-system-header-dir configure option from the
google/integration branch into gcc mainline.  This patch permits
changing the system header directory from /usr/include to something
else.  It's mainly useful in conjunction with sysroot, so that the
header files don't have to live in usr/include under the sysroot.

Simon's original patch:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01811.html

Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK for mainline?

Ian


2011-10-07  Simon Baldwin  <simonb@google.com>

	* configure.ac: Add --with-native-system-header-dir option.
	* configure: Rebuild from configure.ac.
	* Makefile.in: Support --with-native-system-header-dir.
	* doc/install.texi: Document --with-native-system-header-dir.

Comments

Joseph Myers Oct. 7, 2011, 10:37 p.m. UTC | #1
On Fri, 7 Oct 2011, Ian Lance Taylor wrote:

> 2011-10-07  Simon Baldwin  <simonb@google.com>
> 
> 	* configure.ac: Add --with-native-system-header-dir option.
> 	* configure: Rebuild from configure.ac.
> 	* Makefile.in: Support --with-native-system-header-dir.
> 	* doc/install.texi: Document --with-native-system-header-dir.

How does this end up affecting the paths in cppdefault.c, and which of the 
macros there does it affect?  (I don't see how STANDARD_INCLUDE_DIR, the 
normal /usr/include path, gets affected by this patch; I can only see how 
it affects the paths used to find inputs to fixincludes.)
Ian Lance Taylor Oct. 8, 2011, 12:34 a.m. UTC | #2
"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Fri, 7 Oct 2011, Ian Lance Taylor wrote:
>
>> 2011-10-07  Simon Baldwin  <simonb@google.com>
>> 
>> 	* configure.ac: Add --with-native-system-header-dir option.
>> 	* configure: Rebuild from configure.ac.
>> 	* Makefile.in: Support --with-native-system-header-dir.
>> 	* doc/install.texi: Document --with-native-system-header-dir.
>
> How does this end up affecting the paths in cppdefault.c, and which of the 
> macros there does it affect?  (I don't see how STANDARD_INCLUDE_DIR, the 
> normal /usr/include path, gets affected by this patch; I can only see how 
> it affects the paths used to find inputs to fixincludes.)

Hmmm, you're quite right.  Simon's patch works because of a subsequent
patch of his, which adds a --with-runtime-root-prefix configure option.

It looks like we currently have NATIVE_SYSTEM_HEADER_DIR in Makefile
fragments and STANDARD_INCLUDE_DIR and SYSTEM_INCLUDE_DIR in tm.h files.

The documentation for NATIVE_SYSTEM_HEADER_DIR says that it should match
SYSTEM_INCLUDE_DIR.  However, in fact, nothing in the tree defines
SYSTEM_INCLUDE_DIR.

NATIVE_SYSTEM_HEADER_DIR is defined by five Makefile fragments:
  config/i386/t-djgpp
  config/i386/t-mingw-w64
  config/i386/t-mingw-w32
  config/i386/t-mingw32
  config/t-gnu
  config/spu/t-spu-elf

STANDARD_INCLUDE_DIR is defined by:
  config/i386/djgpp.h
  config/i386/mingw32.h
  config/spu/spu-elf.h
  config/gnu.h
  config/vms/xm-vms.h

The uses in DJGPP and Mingw support all match.  config/gnu.h is only
used on i[34567]86-*-gnu* while config/t-gnu is used on *-*-gnu*; this
mismatch appears to be an error.  The use of STANDARD_INCLUDE_DIR in
config/vms/xm-vms.h without defining NATIVE_SYSTEM_HEADER_DIR appears to
be an error.

The configure script uses "/usr/include" when setting
target_header_dir.  This is incorrect when NATIVE_SYSTEM_HEADER_DIR is
defined by a Makefile fragment.

So, it seems to me that we should:

  * Remove SYSTEM_INCLUDE_DIR, which is undefined and unnecessary.

  * Move the definition of NATIVE_SYSTEM_HEADER_DIR into config.gcc
    (named native_system_header_dir).  The default is /usr/include.
    This appears to be necessary since the configure script itself needs
    to know this value.

  * Have the configure script use NATIVE_SYSTEM_HEADER_DIR when setting
    target_header_dir.

  * Arrange for Makefile to define NATIVE_SYSTEM_HEADER_DIR when
    compiling cppdefault.c (i.e., add it to PREPROCESSOR_DEFINES in
    Makefile.in).

  * Replace STANDARD_INCLUDE_DIR in cppdefault.c with
    NATIVE_SYSTEM_HEADER_DIR.

  * Remove STANDARD_INCLUDE_DIR.

  * Add the --with-native-system-header-dir option.

This will remove the setting in vms/xm-vms.h; people using VMS as a host
should be advised to use --with-sysroot instead.

I think this will get us to a consistent state where the name of the
header file directory is defined in one place and is used everywhere it
is appropriate.

Ian
Joseph Myers Oct. 8, 2011, 4:10 p.m. UTC | #3
On Fri, 7 Oct 2011, Ian Lance Taylor wrote:

> The uses in DJGPP and Mingw support all match.  config/gnu.h is only
> used on i[34567]86-*-gnu* while config/t-gnu is used on *-*-gnu*; this
> mismatch appears to be an error.  The use of STANDARD_INCLUDE_DIR in

There are no other *-*-gnu* targets (the others were all removed as 
bitrotten).

> So, it seems to me that we should:

These proposals generally seem reasonable (with "remove" taken to be 
"remove and poison in system.h" as usual for removed target macros).
diff mbox

Patch

Index: configure.ac
===================================================================
--- configure.ac	(revision 179665)
+++ configure.ac	(working copy)
@@ -725,6 +725,23 @@  AC_ARG_ENABLE(shared,
 ], [enable_shared=yes])
 AC_SUBST(enable_shared)
 
+# The use of native_system_header_dir here is for the value (optionally)
+# configured here.  Uses of NATIVE_SYSTEM_HEADER_DIR in this file refer
+# to the make variable defined in Makefile or in target make fragments.
+AC_ARG_WITH([native-system-header-dir],
+  [  --with-native-system-header-dir=dir
+                          use dir as the directory to look for standard
+                          system header files in.  Defaults to /usr/include.],
+[
+ case ${with_native_system_header_dir} in
+ yes|no) AC_MSG_ERROR([bad value ${withval} given for native system include directory]) ;;
+ /*) ;;
+ *) AC_MSG_ERROR([${withval} should be an absolute directory]) ;;
+ esac
+ native_system_header_dir="${withval}"
+], [native_system_header_dir=/usr/include])
+AC_SUBST(NATIVE_SYSTEM_HEADER_DIR, $native_system_header_dir)
+
 AC_ARG_WITH(build-sysroot, 
   [AS_HELP_STRING([--with-build-sysroot=sysroot],
                   [use sysroot as the system root during the build])],
@@ -4515,14 +4532,14 @@  if test x$host != x$target || test "x$TA
   elif test "x$with_sysroot" = x; then
     target_header_dir="${exec_prefix}/${target_noncanonical}/sys-include"
   elif test "x$with_build_sysroot" != "x"; then
-    target_header_dir="${with_build_sysroot}/usr/include"
+    target_header_dir="${with_build_sysroot}${native_system_header_dir}"
   elif test "x$with_sysroot" = xyes; then
-    target_header_dir="${exec_prefix}/${target_noncanonical}/sys-root/usr/include"
+    target_header_dir="${exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
   else
-    target_header_dir="${with_sysroot}/usr/include"
+    target_header_dir="${with_sysroot}${native_system_header_dir}"
   fi
 else
-  target_header_dir=/usr/include
+  target_header_dir=${native_system_header_dir}
 fi
 
 # Test for stack protector support in target C library.
Index: Makefile.in
===================================================================
--- Makefile.in	(revision 179665)
+++ Makefile.in	(working copy)
@@ -455,7 +455,7 @@  LINKER_PLUGIN_API_H = $(srcdir)/../inclu
 LTO_SYMTAB_H = $(srcdir)/../include/lto-symtab.h
 
 # Default native SYSTEM_HEADER_DIR, to be overridden by targets.
-NATIVE_SYSTEM_HEADER_DIR = /usr/include
+NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@
 # Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
 CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
 
Index: doc/install.texi
===================================================================
--- doc/install.texi	(revision 179665)
+++ doc/install.texi	(working copy)
@@ -903,6 +903,18 @@  ideas of what it is for.  People use it 
 install part of GCC@.  Perhaps they make this assumption because
 installing GCC creates the directory.
 
+@item --with-native-system-header-dir=@var{dirname}
+Specifies that @var{dirname} is the directory that contains native system
+header files, rather than @file{/usr/include}. This option is most useful
+if you are creating a compiler that should be isolated from the system
+as much as possible.  It is most commonly used with the
+@option{--with-sysroot} option and will cause GCC to search
+@var{dirname} inside the system root specified by that option.
+
+Please note that for certain targets, such as DJGPP, this value is
+ignored. If the target specifies a default value for native system
+header files then this option is ignored.
+
 @item --enable-shared[=@var{package}[,@dots{}]]
 Build shared versions of libraries, if shared libraries are supported on
 the target platform.  Unlike GCC 2.95.x and earlier, shared libraries
@@ -1736,6 +1748,10 @@  target libraries (which runs on the buil
 installed with @code{make install}; it does not affect the compiler which is
 used to build GCC itself.
 
+If you specify the @option{--with-native-system-header-dir=@var{dirname}}
+option then the compiler will search that directory within @var{dirname} for
+native system headers rather than the default @file{/usr/include}.
+
 @item --with-build-sysroot
 @itemx --with-build-sysroot=@var{dir}
 Tells GCC to consider @var{dir} as the system root (see
@@ -1750,6 +1766,10 @@  This option affects the system root for 
 target libraries (which runs on the build system); it does not affect
 the compiler which is used to build GCC itself.
 
+If you specify the @option{--with-native-system-header-dir=@var{dirname}}
+option then the compiler will search that directory within @var{dirname} for
+native system headers rather than the default @file{/usr/include}.
+
 @item --with-headers
 @itemx --with-headers=@var{dir}
 Deprecated in favor of @option{--with-sysroot}.