removing config/..../bits/ (was Re: need finer-grained "C" header scheme information)
Phil Edwards
phil@jaj.com
Mon Jun 24 01:07:00 GMT 2002
On Fri, Jun 21, 2002 at 09:01:36PM -0400, Phil Edwards wrote:
>
> The "bits" layer is in there because we used to do things like include
> "bits/cpu_limits.h" and then pass -Isource_dir/config/cpu/<variable>.
>
> Now that we're creating symbolic links to the headers directly, there's
> no need for the "bits" layer in the config directories. We don't use bits
> in the newer io and locale directories, because there's no point.
>
> Anybody object if I move the files up a level and get rid of bits?
Nobody objected, Benjamin also thinks it's a good idea, so I've done it.
Minimal adjustments required in the configury and documentation. Tested on
i686-pc-linux-gnu.
Since it's all a bunch of file moving, 98% of the diff would consist of
patches against /dev/null, so I've left those out of what's below.
2002-06-24 Phil Edwards <pme@gcc.gnu.org>
* config/cpu/*/bits/*: Move header files up a level. Remove bits.
* config/os/*/bits/*: Likewise.
* configure.in: Update.
* configure: Regenerate.
* configure.target: Update.
* docs/html/17_intro/porting.texi: Update.
Index: configure.target
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.target,v
retrieving revision 1.44
diff -u -3 -r1.44 configure.target
--- configure.target 20 Jun 2002 19:08:09 -0000 1.44
+++ configure.target 24 Jun 2002 05:40:22 -0000
@@ -19,9 +19,9 @@
# cpu_include_dir CPU-specific directory, defaults to cpu/generic
# if cpu/target_cpu doesn't exist. This is
# used to set the next two:
-# ATOMICITYH location of bits/atomicity.h,
+# ATOMICITYH location of atomicity.h,
# defaults to cpu_include_dir
-# CPULIMITSH location of bits/cpu_limits.h,
+# CPULIMITSH location of cpu_limits.h,
# defaults to cpu_include_dir
#
# os_include_dir OS-specific directory, defaults to os/generic.
@@ -106,14 +106,14 @@
# choices for those if they haven't been explicitly set already.
_cpu_incdir_fullpath=${glibcpp_srcdir}/config/${cpu_include_dir}
if test x${ATOMICITYH+set} != xset; then
- if test -f ${_cpu_incdir_fullpath}/bits/atomicity.h; then
+ if test -f ${_cpu_incdir_fullpath}/atomicity.h; then
ATOMICITYH=$cpu_include_dir
else
ATOMICITYH="cpu/generic"
fi
fi
if test x${CPULIMITSH+set} != xset; then
- if test -f ${_cpu_incdir_fullpath}/bits/cpu_limits.h; then
+ if test -f ${_cpu_incdir_fullpath}/cpu_limits.h; then
CPULIMITSH=$cpu_include_dir
else
CPULIMITSH="cpu/generic"
@@ -131,7 +131,7 @@
case "${target_os}" in
aix4.[3456789]* | aix[56789]*)
# We set os_include_dir to os/aix only on AIX 4.3 and newer, but
- # os/aix/bits/atomicity.h works on earlier versions of AIX 4.*, so we
+ # os/aix/atomicity.h works on earlier versions of AIX 4.*, so we
# explicitly duplicate the directory for 4.[<3].
os_include_dir="os/aix"
ATOMICITYH="os/aix"
Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.in,v
retrieving revision 1.98
diff -u -3 -r1.98 configure.in
--- configure.in 20 Jun 2002 19:08:09 -0000 1.98
+++ configure.in 24 Jun 2002 05:40:22 -0000
@@ -357,9 +357,9 @@
# Propagate the target-specific source directories through the build chain.
# (Nothing currently uses cpu_include_dir directly; only ATOMICITYH and
# CPULIMITSH [might] use it, and they only get used here.)
-OS_INC_SRCDIR=config/${os_include_dir}/bits
-ATOMICITY_INC_SRCDIR=config/${ATOMICITYH}/bits
-CPU_LIMITS_INC_SRCDIR=config/${CPULIMITSH}/bits
+OS_INC_SRCDIR=config/${os_include_dir}
+ATOMICITY_INC_SRCDIR=config/${ATOMICITYH}
+CPU_LIMITS_INC_SRCDIR=config/${CPULIMITSH}
AC_SUBST(OS_INC_SRCDIR)
AC_SUBST(ATOMICITY_INC_SRCDIR)
AC_SUBST(CPU_LIMITS_INC_SRCDIR)
Index: docs/html/17_intro/porting.texi
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/17_intro/porting.texi,v
retrieving revision 1.5
diff -u -3 -r1.5 porting.texi
--- docs/html/17_intro/porting.texi 18 Jun 2002 19:07:09 -0000 1.5
+++ docs/html/17_intro/porting.texi 24 Jun 2002 05:40:23 -0000
@@ -110,7 +110,7 @@
@code{sparc-sun-solaris2.8}.
The first file to create in this directory, should be called
-@file{bits/os_defines.h}. This file contains basic macro definitions
+@file{os_defines.h}. This file contains basic macro definitions
that are required to allow the C++ library to work with your C library.
This file should provide macro definitions for @code{__off_t},
@code{__off64_t}, and @code{__ssize_t}. Typically, this just looks
@@ -161,7 +161,7 @@
#endif
@end example
-We recommend copying an existing @file{bits/os_defines.h} to use as a
+We recommend copying an existing @file{os_defines.h} to use as a
starting point.
@c ---------------------------------------------------------------------
@@ -204,20 +204,20 @@
The library requires that you provide three header files to implement
character classification, analogous to that provided by the C libraries
@file{<ctype.h>} header. You can model these on the files provided in
-@file{config/os/generic/bits}. However, these files will almost
+@file{config/os/generic}. However, these files will almost
certainly need some modification.
-The first file to write is @file{bits/ctype_base.h}. This file provides
+The first file to write is @file{ctype_base.h}. This file provides
some very basic information about character classification. The libstdc++-v3
library assumes that your C library implements @file{<ctype.h>} by using
a table (indexed by character code) containing integers, where each of
these integers is a bit-mask indicating whether the character is
-upper-case, lower-case, alphabetic, etc. The @file{bits/ctype_base.h}
+upper-case, lower-case, alphabetic, etc. The @file{ctype_base.h}
file gives the type of the integer, and the values of the various bit
masks. You will have to peer at your own @file{<ctype.h>} to figure out
how to define the values required by this file.
-The @file{bits/ctype_base.h} header file does not need include guards.
+The @file{ctype_base.h} header file does not need include guards.
It should contain a single @code{struct} definition called
@code{ctype_base}. This @code{struct} should contain two type
declarations, and one enumeration declaration, like this example, taken
@@ -259,9 +259,9 @@
example, using the values from your native @file{<ctype.h>}. They can
be given symbolically (as above), or numerically, if you prefer. You do
not have to include @file{<ctype.h>} in this header; it will always be
-included before @file{bits/ctype_base.h} is included.
+included before @file{ctype_base.h} is included.
-The next file to write is @file{bits/ctype_noninline.h}, which also does
+The next file to write is @file{ctype_noninline.h}, which also does
not require include guards. This file defines a few member functions
that will be included in @file{include/bits/locale_facets.h}. The first
function that must be written is the @code{ctype<char>::ctype}
@@ -337,7 +337,7 @@
@}
@end example
-You must also provide the @file{bits/ctype_inline.h} file, which
+You must also provide the @file{ctype_inline.h} file, which
contains a few more functions. On most systems, you can just copy
@file{config/os/generic/ctype_inline.h} and use it on your system.
@@ -416,11 +416,11 @@
are two distinct approaches. One is to provide a version for your CPU,
using assembly language constructs. The other is to use the
thread-safety primitives in your operating system. In either case, you
-make a file called @file{bits/atomicity.h}, and the variable
+make a file called @file{atomicity.h}, and the variable
@code{ATOMICITYH} must point to this file.
If you are using the assembly-language approach, put this code in
-@file{config/cpu/<chip>/bits/atomicity.h}, where chip is the name of
+@file{config/cpu/<chip>/atomicity.h}, where chip is the name of
your processor (@pxref{CPU}). No additional changes are necessary to
locate the file in this case; @code{ATOMICITYH} will be set by default.
@@ -438,7 +438,7 @@
see the @file{atomicity.h} file for AIX.
With those bits out of the way, you have to actually write
-@file{bits/atomicity.h} itself. This file should be wrapped in an
+@file{atomicity.h} itself. This file should be wrapped in an
include guard named @code{_BITS_ATOMICITY_H}. It should define one
type, and two functions.
More information about the Gcc-patches
mailing list