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 jos...@codesourcery.com
