This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Target C++ header file location rationale?
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: Bart Veer <bartv at eCosCentric dot com>
- Date: Mon, 20 Jan 2003 16:16:56 +0000
- Subject: Target C++ header file location rationale?
Hi all,
Since the list archive is still off-line ( "Unable to read word database
file '/sourceware/htdig/gcc/db/db.words.db'" ) I may as well ask direct...
In a cross-compilation build with 3.2.1, target headers get installed in
$(prefix)/include with target-specific additions going under the bits/
subdir therein. What is the rationale for them living here for cross builds?
By installing in $(prefix)/include they get mixed up with a bunch of host
header files in a complete toolchain like, say, tcl.h (if you were
configuring a full toolchain that included gdb and insight, say). This can
cause confusion since that is associated with the host, and there is no
tcl port for the target.
Less relevant to me but significant is that the same applies in reverse -
if you wanted to include that directory on the host, header files only
really appropriate for the target could be pulled in. This could be
relevant if this directory was ahead of others on the include path.
As you know, they used to be installed in $(prefix)/$(target)/include, and
that still makes sense.
What if we configure with
--with-gxx-include-dir=$(prefix)/$(target)/include, is there any potential
for things to go wrong now, or in the future? Is that something we can use
without fear?
Now while in general I think it's better to go with whatever the defaults
are, it's difficult to see why in this case, especially when there are
disadvantages.
Ta for any insights,
Jifl
--
eCosCentric http://www.eCosCentric.com/ <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine