On the toplevel configure and build system

["Joseph S. Myers" <joseph at codesourcery dot com>]

Having been cleaning up the toplevel configure.ac in various ways 
following removing deprecated targets for GCC 4.7, I would like to propose 
some principles relating to the toplevel configure and build system.  
These are intended as principles to guide future development and indicate 
the directions in which this system should develop - not something I have 
any immediate plans to implement most of.

1. The toplevel configure and build system exists to build the components 
in the GCC and src repositories.  These include GCC, binutils, GDB, newlib 
and some other components such as cgen and winsup, as well as libraries 
used by these components.

Additional tools for the build (not host) system may be built (not 
installed) when present in the source tree, if of direct use in building 
and testing the components in those repositories, and likewise additional 
libraries used by build or host tools or target libraries in those 
repositories may also be built.  But support for tools and libraries that 
do not meet that criterion should be considered obsolete and removed.

Specifically, I propose removal of all support for building: ash autoconf 
automake bash byacc bzip2 diff dosutils fileutils findutils find gawk 
gettext gnuserv gzip hello indent libiconv libtool make mmalloc patch perl 
prms rcs release recode sed send-pr shellutils tar textutils time uudecode 
wdiff zip expect guile target-gperf target-examples target-qthreads.  See 
<http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01674.html> and followups 
regarding reasons to keep a few packages in my original list that aren't 
in the list above.

Furthermore, the system is for the *current code* in those repositories.  
The existence of some out-of-tree version with additional or different 
target support is irrelevant; such trees should include their own local 
toplevel patches as needed.

2. If you put directories from the GCC repository into your build, you 
should expect GCC and its libraries to be built; toplevel should not 
disable GCC on the grounds that GCC does not support a given target.  
Similarly, if you put the src repository or part thereof into your build, 
you should expect at least something from the src repository to be built, 
so if nothing there has support for a target then toplevel should not try 
to disable everything from src.  However, since you may well have a 
checkout with both supported and unsupported parts of src, it is useful 
(for example) to disable gdb if a target has a binutils port but not a gdb 
port.

If in future the src repository is split up into separate repositories for 
different projects, this principle will apply in a more fine-grained way - 
so if there is a "binutils+gdb" repository then toplevel should not try to 
disable the whole of binutils+gdb for targets supporting none of it, only 
subsets for targets supporting a nonempty subset.

3. If it is known that GCC's libraries for a given language do not build 
for a given target, it is generally appropriate to disable that language 
(via unsupported_languages) instead of disabling the libraries directly, 
unless there is some reason the front end is considered useful without the 
libraries.  If it is not known, then the language and libraries should not 
be disabled (subject to some languages not being built by default anyway).  
Various reasons were advanced in reply to 
<http://gcc.gnu.org/ml/gcc/2011-03/msg00326.html> for the default 
disabling of libgcj on many targets, but I think we can reasonably 
conclude that a more carefully considered set of disablings is 
appropriate.

4. It would be desirable to get the information about supported 
directories out of the toplevel configure.ac altogether, and into 
subdirectories.  Subdirectories with known code with portability issues 
should provide configure fragments that can be sourced both at toplevel 
and within that subdirectory, and that set variables in an appropriate 
namespace that indicate the state of support for that directory.  Toplevel 
should then use these fragments to disable directories or GCC languages as 
appropriate.  For example, libffi might provide a fragment defining 
libffi_target and libffi_targetdir (where libffi/configure.ac presently 
defines TARGET and TARGETDIR), and toplevel would source it, and, if 
libffi_targetdir ended up as "unknown", disable languages (java and go) 
that use target-libffi.  Since libffi is the most obvious source of 
portability issues for libgcj, perhaps this could be an initial 
replacement for the ${libgcj} disabling.  Such things as libgloss_dir 
should also come from subdirectories.

5. Similarly, it is unfortunate that a lot of knowledge about how to 
configure GCC with various host libraries such as PPL is embedded in the 
toplevel configure script, and it would be better for this to be in the 
gcc/ subdirectory if possible.  Both this and the previous principle would 
reduce the frequency with which logically GCC-specific changes need 
toplevel changes synced to the src repository.

6. Splitting up the src repository into multiple separate repositories 
would be desirable as part of moving components away from CVS; different 
projects should not be tied so closely to each other.  I propose the 
following as a natural division (moving anything out is complicated, with 
various scripts, documentation etc. to update, but as noted here it should 
be possible to move cgen and rda without any dependencies on other 
projects):

(a) toplevel.  Master repository for the shared toplevel files, config/, 
include/, intl/, libdecnumber/, libiberty/, texinfo/.  Changes merged from 
here to other repositories in whatever way is convenient (depending on the 
version control systems etc. for each repository).

(b) binutils+gdb.  Includes the cpu, etc, libgui, readline and sim 
subdirectories of the src repository (could consider putting libgui and 
other gdbtk code only in a separate repository or branch rather than the 
main binutils+gdb one).  I think the parts of include/ in the src 
repository that aren't shared by GCC can also go here, not in the master 
toplevel repository (although a separate directory for those would be 
better than the present system of having different sets of files in 
include/ in different places).

(c) newlib.  Includes newlib and libgloss.

(d) winsup/Cygwin.  Includes the winsup directory; may need to be based on 
the newlib repository.

(e) cgen.  Does not appear to use libiberty or other toplevel code so need 
not have any relation to the shared toplevel, and if moved out then 
toplevel need no longer support it except maybe as a build tool.  (Where 
cgen descriptions are used to generate code in binutils, those 
descriptions should go in cpu/ in the binutils+gdb repository, not 
cgen/cpu/ in the cgen repository.)

(f) rda.  Again, appears completely independent and toplevel support could 
be removed if it moves out.

(g) sid.

(h) utils - I don't know what to do with this directory or where it best 
goes.

(i) I specifically propose not moving tcl, tk or itcl to any new 
repositories; they would better be removed from HEAD with the expectation 
being that people use preinstalled copies (though the option of building 
the libraries in-tree could be kept if necessary).  It would be good to 
get readline to this state as well (support building sources dropped in 
but don't include a local copy).


Any comments on these principles?

-- 
Joseph S. Myers
joseph@codesourcery.com