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