On the toplevel configure and build system

Joseph S. Myers
2011-03-29T21:52:31Z

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