Re: Proposal for new organization of gcc

Re: Proposal for new organization of gcc

[Alexandre Oliva]

Richard Kenner writes:

>     Having the C front-end in the base tar file is ok for me, but I don't
>     like to be required to build it just because I want to install the
>     front-end for one more language.  

> "one *more*"?

Let me be clearer.  Suppose I had installed gcc-2.7.2.3 and g77-0.5.19
with a few local patches some weeks ago.  Then I removed the sources
and the build tree.

Now I'd like to upgrade to g77-0.5.20.  In a good world, I wouldn't
have to bootstrap gcc again just to be able to build g77, I could
simply tell g77: hey, use that gcc installed in /usr/local/bin, it
will do.  In a perfect world, GCS would have already installed a
library and some include-files that would allow g77 to build *without*
a top-level GCS directory.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Proposal for new organization of gcc

[Alexandre Oliva]

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

Re: Proposal for new organization of gcc

[Michael Gschwind]

> <---- 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 
>[etc]

> Comments?  Improvements?  Suggestions?

Sounds good to me... There should be a big tarball with all of this
and all the test stuff included -- I don't use g77, pascal etc., but
I'd be happy enough to install and test them if its only a make test
away...

m.



-- 
Michael K. Gschwind
IBM T.J. Watson Research Center     phone (external): (914) 945-1675 	
PO Box 218                          phone (internal): T/L 862-1675
Yorktown Heights, NY 10598          e-mail: mikeg@watson.ibm.com

Re: Proposal for new organization of gcc

[Richard Stallman]

    <---- 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 
    ...

I think this is more or less what Kenner is already planning.
Whether the back end files are at top level
or in a subdirectory called bkend or backend
doesn't seem like a major issue to me; either way is probably ok.

    <---- gcs-c.3.0.tar.gz ---->

The C front end can be in a separate subdirectory,
but it has to be in the base tar file.
Everyone needs to build the C front end
so as to be able to bootstrap.
And cpp is needed for multiple languages
(at least C++ and Objective C, but maybe others),
so it has to be in the base tar file too.


Renaming GCC to GCS might be a good idea, since it is not
just a C compiler any more.

Re: Proposal for new organization of gcc

[Alexandre Oliva]

Richard Stallman writes:

> The C front end can be in a separate subdirectory,
> but it has to be in the base tar file.
> Everyone needs to build the C front end
> so as to be able to bootstrap.

Having the C front-end in the base tar file is ok for me, but I don't
like to be required to build it just because I want to install the
front-end for one more language.  In a perfect gcs, I'd be able to
download the gcs backend and the language front-end, build them with
the installed C compiler and install that, and I'm done.

I've considered this a very important feature since the first time I
tried to install g77 in an independent directory, and it took ages for
my SunOS 4.1.3 host to build the whole gcc archive and fix
include-files again, the ones it had just fixed one week before.

This is unnecessary, and I don't think it would be that hard to have
configure & Makefile set up so that they'd build the C compiler and
use it iff its sources are available.  If they're not, an already
installed C compiler should be used.

Obviously, if the C sources are not available, one is unable to
bootstrap the compiler, but then, the only reason for bootstrapping is
for building the C compiler, which wouldn't be built anyway in this
case.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Proposal for new organization of gcc

[Richard Stallman]

      In a perfect gcs, I'd be able to
    download the gcs backend and the language front-end, build them with
    the installed C compiler and install that, and I'm done.

I think that already works now.  However, we want to recommend that
people install the compiler built with itself, and therefore we will
include the source for the C front end with the back end.

Re: Proposal for new organization of gcc

[Alexandre Oliva]

Richard Stallman writes:

>       In a perfect gcs, I'd be able to
>     download the gcs backend and the language front-end, build them with
>     the installed C compiler and install that, and I'm done.

> I think that already works now.

I couldn't make it happen, but I can't say I've tried too hard.  All I
have to say is that it is not as easy as simply removing the back-end
and the C front-end directory from the source tree, or by issuing
configure flags such as --disable-back-end --disable-language-c

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Proposal for new organization of gcc

[Richard Stallman]

    >       In a perfect gcs, I'd be able to
    >     download the gcs backend and the language front-end, build them with
    >     the installed C compiler and install that, and I'm done.

    > I think that already works now.

    I couldn't make it happen, but I can't say I've tried too hard.  All I
    have to say is that it is not as easy as simply removing the back-end
    and the C front-end directory from the source tree,

I would have tried something simpler--just running Make with arguments
that tell it not to build cc1.  If that doesn't work, can you try to
find out why not?  It might be an easily corrected problem.

Re: Proposal for new organization of gcc

[Alexandre Oliva]

Richard Stallman writes:

>> In a perfect gcs, I'd be able to
>> download the gcs backend and the language front-end, build them with
>> the installed C compiler and install that, and I'm done.

>> I think that already works now.

>     I couldn't make it happen, but I can't say I've tried too hard.  All I
>     have to say is that it is not as easy as simply removing the back-end
>     and the C front-end directory from the source tree,

> I would have tried something simpler--just running Make with arguments
> that tell it not to build cc1.  If that doesn't work, can you try to
> find out why not?  It might be an easily corrected problem.

This won't work.  gcc needs cc1 in order to build libgcc.a, and a C++
compiler, for instance, must add some symbols to libgcc.a, so libgcc.a
must be built.  This clearly shows my point: the front-ends are not as
separate from the back-end as they should.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Proposal for new organization of gcc

[Richard Stallman]

    This won't work.  gcc needs cc1 in order to build libgcc.a,

That's true.  In fact, I think this is a show-stopper: unless we make
it possible to compile libgcc2.c with whatever C compiler you use to
compile GCC (not easy since it uses GCC features), we can't possibly
support building other languages without C.  We could perhaps make it
work to compile libgcc2.c using C++, if you don't build the C
compiler, but what if you choose to build only Fortran, Pascal or Ada?

But I don't think it is terribly important to make it possible
to build other languages without building C.

Re: Proposal for new organization of gcc

[Richard Earnshaw]

>     This won't work.  gcc needs cc1 in order to build libgcc.a,
> 
> That's true.  In fact, I think this is a show-stopper: unless we make
> it possible to compile libgcc2.c with whatever C compiler you use to
> compile GCC (not easy since it uses GCC features), we can't possibly
> support building other languages without C.  We could perhaps make it
> work to compile libgcc2.c using C++, if you don't build the C
> compiler, but what if you choose to build only Fortran, Pascal or Ada?
> 

Currently currently libgcc.a contains a range of functions for different 
roles.  Some are to support the core compiler (back end), eg functions to 
support primitive operations such as division (eg divsi) and some are 
language specific, like __eprintf (mainly for C's assert) or __builtin_new 
(C++).

I don't think it is feasible to build the core compiler functions without 
a gcc (though a native CC is also needed on many platforms for libgcc1 
functions), but it shouldn't be necessary to build a completely new gcc to 
compile these if gcc is already installed on the machine.

Perhaps one solution for the multiple sub-libraries problem is for the 
build/install process to merge any existing libgcc.a with the new 
functions that are required, creating a single super-library that contains 
support routines for all the installed compilers.  This would certainly be 
possible with Unix archive libraries, and probably most other OS's.  It 
wouldn't work if libgcc were made into a shared library, but there are 
probably other issues there as well.

Re: Proposal for new organization of gcc

[Alexandre Oliva]

Richard Earnshaw writes:

> Perhaps one solution for the multiple sub-libraries problem is for the 
> build/install process to merge any existing libgcc.a with the new 
> functions that are required, creating a single super-library that contains 
> support routines for all the installed compilers.

This doesn't sound right to me.  Changing libraries that are installed
already seems a bad idea to me.  Installing multiple libraries, OTOH,
does not seem a big problem, IMHO.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Proposal for new organization of gcc

[Richard Earnshaw]

> Richard Earnshaw writes:
> 
> > Perhaps one solution for the multiple sub-libraries problem is for the 
> > build/install process to merge any existing libgcc.a with the new 
> > functions that are required, creating a single super-library that contains 
> > support routines for all the installed compilers.
> 
> This doesn't sound right to me.  Changing libraries that are installed
> already seems a bad idea to me.  Installing multiple libraries, OTOH,
> does not seem a big problem, IMHO.
> 

But then the driver program has to know (or to be able to determine) what 
all libraries are called, or the user has to explicitly add them.  Merging 
the knowledge of multiple language support libraries into the driver 
problem is probably harder than merging the libraries.

You pays your money and you makes your choice.

Re: Proposal for new organization of gcc

[Alexandre Oliva]

Richard Earnshaw writes:

> But then the driver program has to know (or to be able to determine) what 
> all libraries are called, or the user has to explicitly add them.  Merging 
> the knowledge of multiple language support libraries into the driver 
> problem is probably harder than merging the libraries.

The driver already must know about multiple languages, so it wouldn't
be hard to give it knowledge about all libraries in an extendible
way.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Proposal for new organization of gcc

[Harvey J. Stein]

Richard Stallman <rms@santafe.edu> writes:

>     This won't work.  gcc needs cc1 in order to build libgcc.a,
> 
> That's true.  In fact, I think this is a show-stopper: unless we make
> it possible to compile libgcc2.c with whatever C compiler you use to
> compile GCC (not easy since it uses GCC features), we can't possibly
> support building other languages without C.  We could perhaps make it
> work to compile libgcc2.c using C++, if you don't build the C
> compiler, but what if you choose to build only Fortran, Pascal or Ada?
> 
> But I don't think it is terribly important to make it possible
> to build other languages without building C.

What about just supporting it when the stock compiler is gcc?

-- 
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il

Re: Proposal for new organization of gcc

[amylaar]

> > But I don't think it is terribly important to make it possible
> > to build other languages without building C.
> 
> What about just supporting it when the stock compiler is gcc?

It might also need a version check - if libgcc needs a minimum version of
gcc to compile.