This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Proposal for new organization of gcc
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Proposal for new organization of gcc
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 08 Jan 1998 22:18:49 -0200
- Cc: gcc2 at cygnus dot com, egcs at cygnus dot com
- References: <9801082336.AA26988@vlsi1.ultra.nyu.edu>
After so much discussion about the the hierarchical organization of
the gcc package in the gcc2 list, I thought I should try to make it
clearer what I'd expect from gcc after a major reorganization. Let's
assume the main tar-file decompresses into a gcs-3.0 directory (for
GNU Compiler System)
[I swear the similarity with egcs was not intentional, I just noticed
it when I was re-reading the message before sending!]
<---- gcc-3.0.tar.gz ---->
gcs-3.0/configure
it picks up information from the various languages front-ends
and builds Makefile that will build them all. It checks
whether the bkend
gcs-3.0/Makefile.in
Defines simple targets such as all, bootstrap and check
all will just do a one-pass build, in the sequence given
below, while bootstrap will loop three times from bkend to c
before proceeding to the other front-ends.
If the c front-end is not present, bootstrap is equivalent to
all. If the back-end is not present, the back-end library is
looked for in the standard library search path or whatever,
and this library will be used.
gcs-3.0/config
Currently known as gcc-x.x/config
gcs-3.0/bkend
Creates a static and/or shared library libgcsbe to be linked
against language front-ends. It would also contain libgcs
(currently known as libgcc.a), a language-independent
support library.
gcs-3.0/driver
this is what used to be the `gcc' program. It might be in a
subdirectory of bkend too, but I don't think it fits in there.
Perhaps it deserves another name, such as gcd. It might use
argv[0] to decide which language it should default to, so that
gcc, g++, g77, gpc, etc, could be all links to it. Or gcc,
g++ and g77 could be shell-scripts that would just invoke gcd
with an argument that sets the default language. It will
install basic specs in the specs *directory*, for handling
assembly sources, object files and libraries.
<---- gcs-c.3.0.tar.gz ---->
gcs-3.0/cpp
the C/C++ preprocessor. C include files might be `fixed' in
this pass, iff the gcc front-end is present. I'm not sure
whether this is the appropriate moment for that. If neither c
nor c++ front-ends are available, this directory will be
skipped.
gcs-3.0/c
this is the C front-end. It creates a C language
configuration file, that will be installed in the specs
directory. This file tells the driver how to handle .c and .i
files. A gcc shell-script or whatever is created too.
<---- gcs-c++.3.0.tar.gz ---->
gcs-3.0/c++
gcs-3.0/c++/libstdc++
this is the C++ compiler and standard library. It also
creates a C++ language specs file, that tells the driver how
to handle .cc, .cpp, .C and .ii files. A g++ shell-script is
created too.
<---- gcs-*.tar.gz ---->
gcs-3.0/f77
gcs-3.0/pasc
gcs-3.0/java
gcs-3.0/ada
gcs-3.0/objc
gcs-3.0/...
And so on, you got the idea.
binutils-3.0
gdb-5.1
Other packages might be siblings of gcs. Or gcs might have
special knowledge of a few packages and know how to handle
them. I'm not sure this would be a good idea.
...
Comments? Improvements? Suggestions?
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil