This is the mail archive of the
mailing list for the GCC project.
Re: [Forwarded] GPC 2.1 released
- From: Frank Heckenbach <frank at g-n-u dot de>
- To: jsm28 at cam dot ac dot uk, aj at suse dot de, doko at cs dot tu-berlin dot de, gcc at gcc dot gnu dot org
- Cc: peter at gerwinski dot de
- Date: Tue, 14 May 2002 01:16:00 +0200
- Subject: Re: [Forwarded] GPC 2.1 released
- References: <Pine.LNX.firstname.lastname@example.org>
Joseph S. Myers wrote:
> Integration means - ought to mean - more than just supporting GCC 3.1, in
> that to be integrated it ought to follow established good practices for
> front ends.
First of all, I consider the following points mostly minor/marginal.
The hard issues seem to be the changes in the backend/frontend
interface such as the obstack to GC change. I think Peter Gerwinski
has had some discussions about these issues with some of you
already. I don't know about all the details myself, but the current
situation seems to be that there's noone really willing and able and
having the time to do this work. So most of the following points are
to be seen as whenever this work has been done which might not be
too soon ...
I'm CCing Peter since he probably knows better (from our side) if
there's anything else to discuss for now.
> For example:
> * Runtime library in a separate toplevel directory (needed for multilibs
> to work properly).
This should not be too diffcult, since it's mostly self-contained
already. A few rules in p/Make-lang.in must be moved to the toplevel
makefiles then, but I don't expect big problems there. This must
probably be done immediately before integrating GPC in GCC, but if
there's anything that can be prepared in advance, without breaking
the current ways of building GPC, let me know.
A similar thing probably applies to the progams in p/utils/. These
should be built for the host platform, so they will need something
like GPC_FOR_HOST. I haven't written any real build rules for them
yet, so they are not installed by default currently, but after
integration I suppose they also should go in a separate toplevel
> * Obviously, all the conditionals and diffs relating to support for
> different versions of GCC gone (since once it's integrated it need only
> support the CVS version of GCC it's included in).
Sure -- as soon as it's working properly. When we started supporting
gcc-2.95.x, some new problems appeared. Some of them are still
unsolved, and in fact may never get solved in 2.95.x (such as the
nonlocal goto bug on Sparc/Solaris), that's why we still support
2.8.1 as well. Therefore, I'd like to keep the support for the older
backend versions for some while, but once it's tested and found to
be working well with gcc-3.x without any new problems, I'll be glad
to remove these conditionals and diffs.
> * Obsolete things such as diff_excludes in config-lang.in gone.
Sure, together with the removal of the conditionals and diffs. I
might not find all obsolete things when I get to it, but you or
someone will surely tell us then ...
> * Using only Make-lang.in, no separate Makefile.in for the front end
I'm planning to do this soon, anyway. Is there anything to watch out
for when doing it (I suppose you have some experience with other
frontends in this regard)?
> * Integration of build/install instructions into main GCC installation
Of course. I hope it will then be simplified to as little as a
simple `--enable-languages=pascal' note. :-)
There are some notes about related packages (libs, utilities, etc.)
in our install.texi. I personally don't mind whether they'll move to
the main install docs, or remain within the GPC docs.
> * Building docs in a way more similar to those for the other front ends.
> (E.g., don't silence TeX, don't fail for overfull hboxes (since people can
> configure Texinfo for their own paper size and you can't reasonably ensure
> that the manual is perfect for every paper size -
Certainly not for every paper size, but IMHO it should look alright
for the standard size. BTW, I did not add these checks "arbitrarily
without good reason", but for the very concrete reason that some
things (like long URLs and too long lines in example code) sometimes
caused overfull boxes and didn't look good (to put it mildly) in the
manual. Since we offer DVI, PS and PDF files on our website and
might distribute printed copies in the future, I simply want to make
sure they look right (without looking through the files myself each
As for not silencing TeX, what's become of the good old Un*x
principle that a command should be silent unless a problem occurs?
ISTM that this principle is not valued much in GCC (e.g., building
GCC produces some warnings that could probably be eliminated with
some effort, and `configure --silent' seems to be broken since 2.95
(*)), but I prefer it very much because this way I can do a complete
GPC build (including documentation and some cross builds) without
any output (except for the warnings in toplev.c), and when any new
problems (e.g., warnings) appear, I see them directly without
looking through a long output.
(*) I don't know if this is a known problem, but since it's so
obvious I guess so. But in case it's not, here's the bug report:
# ../gcc-3.0.4/configure --silent; make
make: Leaving directory `/home/frank/in/x/a/gcc'
Configuring in i686-pc-linux-gnu/libstdc++-v3
configure: error: --silent=: invalid option; use --help to show usage
make: *** [configure-target-libstdc++-v3] Error 1
I've seen this with 3.0.4 and various 2.95.x versions on
i?86-pc-linux-gnu (and I think also other systems).
> actually setting the
> paper size in the manual, except for FSFPRINT, is wrong),
OK, I'll do this via the command line (`-t') now. Is that the
If we can't agree in the other points, I think we could just just an
environment variable or two different build rules (or a configure
option, though I wouldn't know how to implement it) to support out
> put the contents
> list in the right place in the manual in the first place rather than
> reordering the .dvi file,
Can I just move the `@summarycontents' and `@contents' after the
`@end titlepage', or is there anything to watch out for? (Since
gcc.texi until 2.95.x had them at the end, I wasn't sure if there
are any issues, so I rather wrote the dvi-reorder kludge to avoid
breaking anything else ...) Is a certain version of texinfo required
for it to work?
> use makeinfo --html for HTML manuals [there
> isn't any standard for building them from Makefiles, but it's what
> onlinedocs do].)
I plan to do this soon, just didn't get around to this yet, since
the first texinfo release with a usable `--html' (i.e. with file
splitting) was not so long ago. (I'm personally not happy with
texi2html at all, so I like to get rid of it ASAP.)
> * Using the GNU Free Documentation License for manuals.
Should be no problem. I guess we only need an ok from the FSF as the
copyright holder. I'll try to get this done soon.
> * See also the list in "Anatomy of a Language Front End" in
> sourcebuild.texi, to ensure that when adding it you do add a complete
> front end, with all the associated documentation etc. bits needed.
Is there a way to get this file without doing a complete CVS
Frank Heckenbach, email@example.com
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)