* No Fortran
@ 1998-09-08 19:58 Nathan Myers
1998-09-11 17:54 ` Gerald Pfeifer
0 siblings, 1 reply; 27+ messages in thread
From: Nathan Myers @ 1998-09-08 19:58 UTC (permalink / raw)
To: egcs
Whenever I build Egcs, I always specify only
LANGUAGES="c c++"
yet the build invariably spends a great deal of time on
Fortran libraries.
Can't the Fortran libraries be arranged to be built only when
something that depends on them is specified?
Nathan Myers
ncm@cantrip.org
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-08 19:58 No Fortran Nathan Myers
@ 1998-09-11 17:54 ` Gerald Pfeifer
1998-09-12 13:32 ` Jeffrey A Law
1998-09-13 4:58 ` Dave Love
0 siblings, 2 replies; 27+ messages in thread
From: Gerald Pfeifer @ 1998-09-11 17:54 UTC (permalink / raw)
To: egcs; +Cc: Nathan Myers
On Tue, 8 Sep 1998, Nathan Myers wrote:
> Whenever I build Egcs, I always specify only
>
> LANGUAGES="c c++"
>
> yet the build invariably spends a great deal of time on
> Fortran libraries.
libf2c, I mean? I've been wondering why we compile that for "c c++",
too. Would a patch that only builds libf2c if "g77" is built as well be
accepted?
A simple solution is removing libf2c from your local CVS tree resp. from
your untared snapshot, by the way.
Gerald
--
Gerald Pfeifer (Jerry) Vienna University of Technology
pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-11 17:54 ` Gerald Pfeifer
@ 1998-09-12 13:32 ` Jeffrey A Law
1998-09-14 17:12 ` Gerald Pfeifer
1998-09-13 4:58 ` Dave Love
1 sibling, 1 reply; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-12 13:32 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: egcs, Nathan Myers
In message < Pine.GSO.4.03.9809120241420.11674-100000@nashira.dbai.tuwien.ac.at >you write:
> On Tue, 8 Sep 1998, Nathan Myers wrote:
> > Whenever I build Egcs, I always specify only
> >
> > LANGUAGES="c c++"
> >
> > yet the build invariably spends a great deal of time on
> > Fortran libraries.
>
> libf2c, I mean? I've been wondering why we compile that for "c c++",
> too. Would a patch that only builds libf2c if "g77" is built as well be
> accepted?
Yes it would, though I thought we had already fixed this once.
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-11 17:54 ` Gerald Pfeifer
1998-09-12 13:32 ` Jeffrey A Law
@ 1998-09-13 4:58 ` Dave Love
1 sibling, 0 replies; 27+ messages in thread
From: Dave Love @ 1998-09-13 4:58 UTC (permalink / raw)
To: egcs
>>>>> "GP" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
GP> libf2c, I mean? I've been wondering why we compile that for "c
GP> c++", too. Would a patch that only builds libf2c if "g77" is
GP> built as well be accepted?
Perhaps it could treat C++ runtime on the same basis. (I'm not sure
if it's still the case, but g++ used to be built regardless of
LANGUAGES.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-14 17:12 ` Gerald Pfeifer
@ 1998-09-14 15:39 ` Craig Burley
1998-09-14 22:21 ` Joe Buck
` (2 more replies)
1998-09-15 0:55 ` Jeffrey A Law
1 sibling, 3 replies; 27+ messages in thread
From: Craig Burley @ 1998-09-14 15:39 UTC (permalink / raw)
To: pfeifer; +Cc: burley
>Craig, I'm also sending this directly to you, as it seems you developed
>that feature back then.
I'm still not entirely sure that we should avoid building libg2c
even when `f77' is not in the list of languages. Do we avoid
building the C++ libraries when "c++" isn't in that list?
The reason I ask is, just because g77 (and f771) don't get built
doesn't mean users won't want, or be able to, use a libg2c that
gets built with it:
f2c foo.f
gcc foo.c -lg2c -lm
Also, looking at egcs 1.1a, I don't see evidence that the libraries
get built with *any* definition of the LANGUAGES macro in place.
Maybe I'm wrong (I haven't tried it), or maybe this has changed
in the mainline. Otherwise, how could I implement this, other
than by having egcs/libf2c/Makefile.in test whether egcs/gcc/lang-f77
exists -- something that seems a bit questionable, though it might
work?
tq vm, (burley)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-12 13:32 ` Jeffrey A Law
@ 1998-09-14 17:12 ` Gerald Pfeifer
1998-09-14 15:39 ` Craig Burley
1998-09-15 0:55 ` Jeffrey A Law
0 siblings, 2 replies; 27+ messages in thread
From: Gerald Pfeifer @ 1998-09-14 17:12 UTC (permalink / raw)
To: egcs, Craig Burley; +Cc: Jeffrey A Law, Nathan Myers
On Sat, 12 Sep 1998, Jeffrey A Law wrote:
>> libf2 [...] ? I've been wondering why we compile that for "c c++", too.
>> Would a patch that only builds libf2c if "g77" is built as well be
>> accepted?
> Yes it would, though I thought we had already fixed this once.
Nope, this was for gcc/f only, as far as I can see.
Craig, I'm also sending this directly to you, as it seems you developed
that feature back then.
I had a look today, but it's not that trivial and I guess that for you
it shouldn't be that hard, should it? ;-)
Thu May 28 21:32:18 1998 Craig Burley <burley@gnu.org>
* Make-lang.in (g77.c, g77spec.o, g77.o, g77$(exeext),
g77-cross$(exeext), f771,
$(srcdir)/f/g77.info, $(srcdir)/f/g77.dvi,
$(srcdir)/f/intdoc.texi,
f77.install-common, f77.install-info, f77.install-man,
f77.uninstall, $(G77STAGESTUFF), f77.stage1, f77.stage2,
f77.stage3, f77.stage4, f77.distdir): Don't do anything
unless user specified "f77" or "F77" in $LANGUAGES either
during configuration or explicitly. For convenience of
various tests and to work around lack of the assignment
"LANGUAGES=$(BOOT_LANGUAGES)" in the "make stage1" command
of "make bootstrap" in gcc, use a touch file named "lang-f77"
to communicate whether this is the case.
Gerald
--
Gerald Pfeifer (Jerry) Vienna University of Technology
pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-14 15:39 ` Craig Burley
@ 1998-09-14 22:21 ` Joe Buck
1998-09-15 7:06 ` Craig Burley
1998-09-15 1:05 ` No Fortran Jeffrey A Law
1998-09-15 3:02 ` Marc Espie
2 siblings, 1 reply; 27+ messages in thread
From: Joe Buck @ 1998-09-14 22:21 UTC (permalink / raw)
To: Craig Burley; +Cc: pfeifer, egcs, law, burley
> I'm still not entirely sure that we should avoid building libg2c
> even when `f77' is not in the list of languages. Do we avoid
> building the C++ libraries when "c++" isn't in that list?
Yes. We have to, since the C++ libraries are mostly written in C++
and we don't assume the user has a C++ compiler if we didn't just
build one.
Furthermore, even if we didn't, we shouldn't waste users' time
building stuff when they thought they asked to exclude it.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-14 17:12 ` Gerald Pfeifer
1998-09-14 15:39 ` Craig Burley
@ 1998-09-15 0:55 ` Jeffrey A Law
1 sibling, 0 replies; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-15 0:55 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: egcs, Craig Burley, Nathan Myers
In message <Pine.GSO.4.03.9809142035270.16832-100000@nashira.dbai.tuwien.ac.a
t>you write:
> On Sat, 12 Sep 1998, Jeffrey A Law wrote:
> >> libf2 [...] ? I've been wondering why we compile that for "c c++", too.
> >> Would a patch that only builds libf2c if "g77" is built as well be
> >> accepted?
> > Yes it would, though I thought we had already fixed this once.
>
> Nope, this was for gcc/f only, as far as I can see.
Bummer.
I wonder if we could detect the existance of gcc/f771 in the toplevel
configure scripts and refuse to configure/build libf2c in that case.
Similarly for libchill, the C++ libs and libobjc (soon).
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-14 15:39 ` Craig Burley
1998-09-14 22:21 ` Joe Buck
@ 1998-09-15 1:05 ` Jeffrey A Law
1998-09-15 3:02 ` Marc Espie
2 siblings, 0 replies; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-15 1:05 UTC (permalink / raw)
To: Craig Burley; +Cc: pfeifer, egcs
In message < 199809142239.SAA01457@melange.gnu.org >you write:
> I'm still not entirely sure that we should avoid building libg2c
> even when `f77' is not in the list of languages. Do we avoid
> building the C++ libraries when "c++" isn't in that list?
For C++ it is critical that we not build them if C++ isn't in
LANGUAGES. Why, because some of the code is written in C++.
Worse yet, if we didn't build C++ ourselves, then autoconf might
find a random copy of g++ lying around on the system. Instead of
failing loudly it might silently use g++-2.7 or something bad like
that :-)
This kind of problem is much less severe for runtimes that are
written in C like libf2c and libchill since C code is rarely
incompatible between releases.
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-15 7:06 ` Craig Burley
@ 1998-09-15 1:12 ` Jeffrey A Law
1998-09-16 3:07 ` No Fortran - IS ANYBODY WORKING ON IT? Manfred Hollstein
0 siblings, 1 reply; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-15 1:12 UTC (permalink / raw)
To: Craig Burley; +Cc: jbuck, pfeifer, egcs
In message < 199809150720.DAA03225@melange.gnu.org >you write:
> Can the libf2c directory use whatever solution is employed to avoid
> building the C++ libraries -- is it general enough? Does anybody
> know?
Assuming we're actually handling this correctly for C++. Maybe we
are, if so, we should try and use the same technique.
> If not, perhaps, rather than testing for the existence of ../gcc/lang-f77,
> testing for ../gcc/g77 or ../gcc/f771 would be more appropriate.
> Somehow any of those tests feel like kludges, but offhand I can't
> see any reason they wouldn't work, in the short term anyway.
I kind of liked that idea (see my earlier message) It tests for
exactly the problem we want -- did the C++, Fortran, etc compiler
get built? If not, don't try to build the runtime.
This kind of scheme works better if we ever have an option to
enable/disable a language at configure time. ie --disable-chill
or something like that to disable the chill compiler, even if
it is in your source tree and you don't remember LANGUAGES="..." :-)
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-14 15:39 ` Craig Burley
1998-09-14 22:21 ` Joe Buck
1998-09-15 1:05 ` No Fortran Jeffrey A Law
@ 1998-09-15 3:02 ` Marc Espie
1998-09-15 14:14 ` Ken Raeburn
2 siblings, 1 reply; 27+ messages in thread
From: Marc Espie @ 1998-09-15 3:02 UTC (permalink / raw)
To: egcs
In article < 199809142239.SAA01457@melange.gnu.org > you write:
>>Craig, I'm also sending this directly to you, as it seems you developed
>>that feature back then.
>I'm still not entirely sure that we should avoid building libg2c
>even when `f77' is not in the list of languages. Do we avoid
>building the C++ libraries when "c++" isn't in that list?
>The reason I ask is, just because g77 (and f771) don't get built
>doesn't mean users won't want, or be able to, use a libg2c that
>gets built with it:
> f2c foo.f
> gcc foo.c -lg2c -lm
Seems valid to me, but then, I would say that we need a feature to
enable/disable specific libraries AND corresponding comments in the
INSTALL directive... Say something like
LANGUAGES="c++ chill f77 libf2c libstdc++" as a full list, with some
dependencies that get trigerred automatically (building f77 triggers
lib2fc).
I wouldn't know if this is an easy scheme to implement or not, though...
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-14 22:21 ` Joe Buck
@ 1998-09-15 7:06 ` Craig Burley
1998-09-15 1:12 ` Jeffrey A Law
0 siblings, 1 reply; 27+ messages in thread
From: Craig Burley @ 1998-09-15 7:06 UTC (permalink / raw)
To: jbuck; +Cc: burley
>> I'm still not entirely sure that we should avoid building libg2c
>> even when `f77' is not in the list of languages. Do we avoid
>> building the C++ libraries when "c++" isn't in that list?
>
>Yes. We have to, since the C++ libraries are mostly written in C++
>and we don't assume the user has a C++ compiler if we didn't just
>build one.
Ah. Okay, that makes sense, at least for C++. libg2c, AFAICT,
doesn't depend on anything other than gcc itself being built.
But, in theory, I suppose libg2c could be written in Fortran, and/or
depend on the Fortran compiler (f771) to generate configuration
info. (I have done only enough thinking about the long-term
architecting of this to realize there are some sticky issues...
seemingly none of which currently apply.)
>Furthermore, even if we didn't, we shouldn't waste users' time
>building stuff when they thought they asked to exclude it.
Sounds good to me.
Can the libf2c directory use whatever solution is employed to avoid
building the C++ libraries -- is it general enough? Does anybody
know?
If not, perhaps, rather than testing for the existence of ../gcc/lang-f77,
testing for ../gcc/g77 or ../gcc/f771 would be more appropriate.
Somehow any of those tests feel like kludges, but offhand I can't
see any reason they wouldn't work, in the short term anyway.
tq vm, (burley)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran
1998-09-15 3:02 ` Marc Espie
@ 1998-09-15 14:14 ` Ken Raeburn
0 siblings, 0 replies; 27+ messages in thread
From: Ken Raeburn @ 1998-09-15 14:14 UTC (permalink / raw)
To: egcs
Marc Espie <espie@quatramaran.ens.fr> writes:
> >I'm still not entirely sure that we should avoid building libg2c
> >even when `f77' is not in the list of languages. Do we avoid
> >building the C++ libraries when "c++" isn't in that list?
>
> >The reason I ask is, just because g77 (and f771) don't get built
> >doesn't mean users won't want, or be able to, use a libg2c that
> >gets built with it:
>
> > f2c foo.f
> > gcc foo.c -lg2c -lm
>
> Seems valid to me, but then, I would say that we need a feature to
> enable/disable specific libraries AND corresponding comments in the
> INSTALL directive... Say something like
> LANGUAGES="c++ chill f77 libf2c libstdc++" as a full list, with some
> dependencies that get trigerred automatically (building f77 triggers
> lib2fc).
Why should f77 always imply libf2c (or libg2c or whatever)? Maybe I
want f771 so I can generate object code, but I want to use my own
support library....
I think these should just be ignored. IMHO we're providing a full
compiler suite with runtime support (ignoring for the moment the fact
that binutils isn't included), not a random assortment of programs and
libraries to be built on an ad-hoc basis. Build the front end and the
libraries if the language is desired, and neither if it's not....
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran - IS ANYBODY WORKING ON IT?
1998-09-16 3:07 ` No Fortran - IS ANYBODY WORKING ON IT? Manfred Hollstein
@ 1998-09-15 23:51 ` Jeffrey A Law
1998-09-29 10:10 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Manfred Hollstein
1 sibling, 0 replies; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-15 23:51 UTC (permalink / raw)
To: manfred, Manfred.Hollstein; +Cc: burley, jbuck, pfeifer, egcs
In message < 13823.23619.576085.492756@slsvhmt >you write:
> Is anybody working on this already? I'd like to implement this as I've
> stumbled across this especially on my damn slow 68k machine (which is
> - even worse - using multilibs :-( ); but unfortunately I'm rather
> busy doing other things at the moment, I guess I'll be having a patch
> available in 1 to 2 weeks. OK?
I'm not aware of anyone actively working on it.
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: No Fortran - IS ANYBODY WORKING ON IT?
1998-09-15 1:12 ` Jeffrey A Law
@ 1998-09-16 3:07 ` Manfred Hollstein
1998-09-15 23:51 ` Jeffrey A Law
1998-09-29 10:10 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Manfred Hollstein
0 siblings, 2 replies; 27+ messages in thread
From: Manfred Hollstein @ 1998-09-16 3:07 UTC (permalink / raw)
To: law; +Cc: burley, jbuck, pfeifer, egcs
On Tue, 15 September 1998, 02:10:15, law@cygnus.com wrote:
>
> In message < 199809150720.DAA03225@melange.gnu.org >you write:
> > Can the libf2c directory use whatever solution is employed to avoid
> > building the C++ libraries -- is it general enough? Does anybody
> > know?
> Assuming we're actually handling this correctly for C++. Maybe we
> are, if so, we should try and use the same technique.
>
> > If not, perhaps, rather than testing for the existence of ../gcc/lang-f77,
> > testing for ../gcc/g77 or ../gcc/f771 would be more appropriate.
> > Somehow any of those tests feel like kludges, but offhand I can't
> > see any reason they wouldn't work, in the short term anyway.
> I kind of liked that idea (see my earlier message) It tests for
> exactly the problem we want -- did the C++, Fortran, etc compiler
> get built? If not, don't try to build the runtime.
>
> This kind of scheme works better if we ever have an option to
> enable/disable a language at configure time. ie --disable-chill
> or something like that to disable the chill compiler, even if
> it is in your source tree and you don't remember LANGUAGES="..." :-)
Is anybody working on this already? I'd like to implement this as I've
stumbled across this especially on my damn slow 68k machine (which is
- even worse - using multilibs :-( ); but unfortunately I'm rather
busy doing other things at the moment, I guess I'll be having a patch
available in 1 to 2 weeks. OK?
manfred
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to run only test where appropriate
1998-09-29 10:10 ` PATCH to run only test where appropriate Manfred Hollstein
@ 1998-09-29 10:10 ` Jeffrey A Law
1998-09-29 23:25 ` Manfred Hollstein
0 siblings, 1 reply; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-29 10:10 UTC (permalink / raw)
To: manfred, Manfred.Hollstein; +Cc: egcs-patches, burley, jbuck, pfeifer, egcs
In message < 13840.60777.577076.232891@slsvhmt >you write:
> On Tue, 29 September 1998, 15:53:53, manfred@s-direktnet.de wrote:
>
> > Another thing which should be fixed: currently "make check" ignores
> > any definition of LANGUAGES; on my Motorola machines I restrict them
> > to "c c++" due to the slow machines. Unfortunately, the "check-..."
> > targets don't consider if they actually can do anything useful,
> > e.g. if "cc1plus" doesn't exist, don't even try to start "runtest"; in
> > my example, the check-f77 causes me one additional *hour* of checking
> > on the dog slow m68k box :-( I'll be sending a patch for this, too.
>
> This patch
>
> - adds code to check if the compiler to be tested even exists,
> - eliminates the redundancy of having a separate "check-" target
> for each compiler; they actually only differ in the `--tool'
> argument.
>
> OK to install?
No. In the absence of binaries for the compiler in the build directory the
testsuite should use the compilers from the install tree. Your patch would
disable that behavior as far as I can tell.
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* PATCH to run only test where appropriate
1998-09-29 10:10 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Manfred Hollstein
@ 1998-09-29 10:10 ` Manfred Hollstein
1998-09-29 10:10 ` Jeffrey A Law
1998-09-30 4:15 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Jeffrey A Law
1 sibling, 1 reply; 27+ messages in thread
From: Manfred Hollstein @ 1998-09-29 10:10 UTC (permalink / raw)
To: egcs-patches; +Cc: law, burley, jbuck, pfeifer, egcs
On Tue, 29 September 1998, 15:53:53, manfred@s-direktnet.de wrote:
> Another thing which should be fixed: currently "make check" ignores
> any definition of LANGUAGES; on my Motorola machines I restrict them
> to "c c++" due to the slow machines. Unfortunately, the "check-..."
> targets don't consider if they actually can do anything useful,
> e.g. if "cc1plus" doesn't exist, don't even try to start "runtest"; in
> my example, the check-f77 causes me one additional *hour* of checking
> on the dog slow m68k box :-( I'll be sending a patch for this, too.
This patch
- adds code to check if the compiler to be tested even exists,
- eliminates the redundancy of having a separate "check-" target
for each compiler; they actually only differ in the `--tool'
argument.
OK to install?
manfred
1998-09-29 Manfred Hollstein <manfred@s-direktnet.de>
* Makefile.in (check-*): Combine existing check-<lang> targets
to avoid redundancy; add code to check if the tests actually
need to run.
diff -rup -x CVS -x RCS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el egcs-19980929.orig/gcc/Makefile.in egcs-19980929/gcc/Makefile.in
--- egcs-19980929.orig/gcc/Makefile.in Mon Sep 21 10:12:05 1998
+++ egcs-19980929/gcc/Makefile.in Tue Sep 29 16:16:44 1998
@@ -2612,45 +2612,26 @@ testsuite/site.exp: site.exp
rm -rf testsuite/site.exp
cp site.exp testsuite/site.exp
-check-g++: testsuite/site.exp
- -rootme=`pwd`; export rootme; \
- srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
- cd testsuite; \
- EXPECT=${EXPECT} ; export EXPECT ; \
- if [ -f $${rootme}/../expect/expect ] ; then \
- TCL_LIBRARY=$${srcdir}/../tcl/library ; \
- export TCL_LIBRARY ; fi ; \
- $(RUNTEST) --tool g++ $(RUNTESTFLAGS)
-
-check-gcc: testsuite/site.exp
- -rootme=`pwd`; export rootme; \
- srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
- cd testsuite; \
- EXPECT=${EXPECT} ; export EXPECT ; \
- if [ -f $${rootme}/../expect/expect ] ; then \
- TCL_LIBRARY=$${srcdir}/../tcl/library ; \
- export TCL_LIBRARY ; fi ; \
- $(RUNTEST) --tool gcc $(RUNTESTFLAGS)
-
-check-g77: testsuite/site.exp
- -rootme=`pwd`; export rootme; \
- srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
- cd testsuite; \
- EXPECT=${EXPECT} ; export EXPECT ; \
- if [ -f $${rootme}/../expect/expect ] ; then \
- TCL_LIBRARY=$${srcdir}/../tcl/library ; \
- export TCL_LIBRARY ; fi ; \
- $(RUNTEST) --tool g77 $(RUNTESTFLAGS)
-
-check-objc: testsuite/site.exp
- -rootme=`pwd`; export rootme; \
- srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
- cd testsuite; \
- EXPECT=${EXPECT} ; export EXPECT ; \
- if [ -f $${rootme}/../expect/expect ] ; then \
- TCL_LIBRARY=$${srcdir}/../tcl/library ; \
- export TCL_LIBRARY ; fi ; \
- $(RUNTEST) --tool objc $(RUNTESTFLAGS)
+check-g++ check-gcc check-g77 check-objc: testsuite/site.exp
+ -tool=`echo $@ | sed -e 's,^check-,,'`; \
+ runtests=no; \
+ case $$tool in \
+ g++ ) if [ -f ./cc1plus$(exeext) ]; then runtests=yes; else true; fi ;; \
+ gcc ) if [ -f ./cc1$(exeext) ]; then runtests=yes; else true; fi ;; \
+ g77 ) if [ -f ./f771$(exeext) ]; then runtests=yes; else true; fi ;; \
+ objc) if [ -f ./cc1obj$(exeext) ]; then runtests=yes; else true; fi ;; \
+ * ) true ;; \
+ esac; \
+ if [ $$runtests = yes ]; then \
+ rootme=`pwd`; export rootme; \
+ srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
+ cd testsuite; \
+ EXPECT=${EXPECT} ; export EXPECT ; \
+ if [ -f $${rootme}/../expect/expect ] ; then \
+ TCL_LIBRARY=$${srcdir}/../tcl/library ; \
+ export TCL_LIBRARY ; fi ; \
+ $(RUNTEST) --tool $$tool $(RUNTESTFLAGS) ; \
+ else true; fi
# These exist for maintenance purposes.
^ permalink raw reply [flat|nested] 27+ messages in thread
* PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?)
1998-09-16 3:07 ` No Fortran - IS ANYBODY WORKING ON IT? Manfred Hollstein
1998-09-15 23:51 ` Jeffrey A Law
@ 1998-09-29 10:10 ` Manfred Hollstein
1998-09-29 10:10 ` PATCH to run only test where appropriate Manfred Hollstein
1998-09-30 4:15 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Jeffrey A Law
1 sibling, 2 replies; 27+ messages in thread
From: Manfred Hollstein @ 1998-09-29 10:10 UTC (permalink / raw)
To: law; +Cc: burley, jbuck, pfeifer, egcs
On Wed, 16 September 1998, 08:39:53, manfred@s-direktnet.de wrote:
> On Tue, 15 September 1998, 02:10:15, law@cygnus.com wrote:
>
> >
> > This kind of scheme works better if we ever have an option to
> > enable/disable a language at configure time. ie --disable-chill
> > or something like that to disable the chill compiler, even if
> > it is in your source tree and you don't remember LANGUAGES="..." :-)
>
> Is anybody working on this already? I'd like to implement this as I've
> stumbled across this especially on my damn slow 68k machine (which is
> - even worse - using multilibs :-( ); but unfortunately I'm rather
> busy doing other things at the moment, I guess I'll be having a patch
> available in 1 to 2 weeks. OK?
>
> manfred
The approach you were talking about assumes, everybody who wants to
restrict the languages to a particular subset
- knows which languages do exist and which do I want.
My patch below goes the other way round. It's based on the assumption
that most people
- know which languages they actually want to build.
If the "--disable-chill" would have been available before the recent
languages had been introduced, all users, that only wanted "c c++" to
be built, would still get the new compilers, simply because they
didn't know such a beast exists.
With my patch applied, you can do things like this:
$ env ... [LANGUAGES="c c++"] ../egcs-src/configure \
[--enable-languages="c c++"] ...
(You can use an environment variable $LANGUAGES, or define the subset
via --enable-languages="..." - the --enable-l... argument overrules
$LANGUAGES).
Then you can build as usual:
$ make bootstrap
which will only build the C and C++ related compilers and runtime
libs. BUT, you can still build everything else by passing a
particular LANGUAGES="..." argument to make:
$ make bootstrap LANGUAGES="c f77"
will ensure, your build contains everything for C and F77 (since you
didn't call "make clean" in between, it actually still contains the
C++ related stuff).
I think this approach is much more flexible than defining at configure
time "which languages do I want?".
Is this, what you can live with?
Another thing which should be fixed: currently "make check" ignores
any definition of LANGUAGES; on my Motorola machines I restrict them
to "c c++" due to the slow machines. Unfortunately, the "check-..."
targets don't consider if they actually can do anything useful,
e.g. if "cc1plus" doesn't exist, don't even try to start "runtest"; in
my example, the check-f77 causes me one additional *hour* of checking
on the dog slow m68k box :-( I'll be sending a patch for this, too.
manfred
1998-09-29 Manfred Hollstein <manfred@s-direktnet.de>
* configure (enable_languages): New variable; emit its value
into the generated toplevel Makefile.
* Makefile.in ($(ALL_MODULES)): Descent into language specific
sub-directories only if $(LANGUAGES) contain the appropriate
identifier.
($(NATIVE_CHECK_MODULES)): Likewise.
($(CROSS_CHECK_MODULES)): Likewise.
($(INSTALL_MODULES)): Likewise.
($(CONFIGURE_TARGET_MODULES)): Likewise.
($(ALL_TARGET_MODULES)): Likewise.
($(CHECK_TARGET_MODULES)): Likewise.
($(INSTALL_TARGET_MODULES)): Likewise.
diff -rup -x CVS -x RCS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el egcs-19980929.orig/Makefile.in egcs-19980929/Makefile.in
--- egcs-19980929.orig/Makefile.in Fri Sep 25 12:11:08 1998
+++ egcs-19980929/Makefile.in Tue Sep 29 13:25:11 1998
@@ -1067,11 +1067,35 @@ gcc-no-fixedincludes:
.PHONY: $(ALL_MODULES) all-gui all-libproc
$(ALL_MODULES) all-gui all-libproc:
@dir=`echo $@ | sed -e 's/all-//'`; \
- if [ -f ./$${dir}/Makefile ] ; then \
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) all); \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -f ./$${dir}/Makefile ] ; then \
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) all); \
+ else \
+ true; \
+ fi; \
else \
true; \
fi
@@ -1084,6 +1108,63 @@ $(ALL_MODULES) all-gui all-libproc:
$(NATIVE_CHECK_MODULES):
@if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \
dir=`echo $@ | sed -e 's/check-//'`; \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -f ./$${dir}/Makefile ] ; then \
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) check); \
+ else \
+ true; \
+ fi; \
+ else \
+ true; \
+ fi; \
+ fi
+
+$(CROSS_CHECK_MODULES):
+ @dir=`echo $@ | sed -e 's/check-//'`; \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
if [ -f ./$${dir}/Makefile ] ; then \
r=`pwd`; export r; \
s=`cd $(srcdir); pwd`; export s; \
@@ -1092,15 +1173,6 @@ $(NATIVE_CHECK_MODULES):
else \
true; \
fi; \
- fi
-
-$(CROSS_CHECK_MODULES):
- @dir=`echo $@ | sed -e 's/check-//'`; \
- if [ -f ./$${dir}/Makefile ] ; then \
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) check); \
else \
true; \
fi
@@ -1110,11 +1182,35 @@ $(CROSS_CHECK_MODULES):
.PHONY: $(INSTALL_MODULES)
$(INSTALL_MODULES): installdirs
@dir=`echo $@ | sed -e 's/install-//'`; \
- if [ -f ./$${dir}/Makefile ] ; then \
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) install); \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -f ./$${dir}/Makefile ] ; then \
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) install); \
+ else \
+ true; \
+ fi; \
else \
true; \
fi
@@ -1124,91 +1220,139 @@ $(INSTALL_MODULES): installdirs
.PHONY: $(CONFIGURE_TARGET_MODULES)
$(CONFIGURE_TARGET_MODULES):
@dir=`echo $@ | sed -e 's/configure-target-//'`; \
- if [ -d $(TARGET_SUBDIR)/$${dir} ]; then \
- r=`pwd`; export r; \
- $(CC_FOR_TARGET) --print-multi-lib > $(TARGET_SUBDIR)/$${dir}/tmpmulti.out 2> /dev/null; \
- if [ -s $(TARGET_SUBDIR)/$${dir}/tmpmulti.out ]; then \
- if [ -f $(TARGET_SUBDIR)/$${dir}/multilib.out ]; then \
- if cmp $(TARGET_SUBDIR)/$${dir}/multilib.out $(TARGET_SUBDIR)/$${dir}/tmpmulti.out > /dev/null; then \
- rm -f $(TARGET_SUBDIR)/$${dir}/tmpmulti.out; \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -d $(TARGET_SUBDIR)/$${dir} ]; then \
+ r=`pwd`; export r; \
+ $(CC_FOR_TARGET) --print-multi-lib > $(TARGET_SUBDIR)/$${dir}/tmpmulti.out 2> /dev/null; \
+ if [ -s $(TARGET_SUBDIR)/$${dir}/tmpmulti.out ]; then \
+ if [ -f $(TARGET_SUBDIR)/$${dir}/multilib.out ]; then \
+ if cmp $(TARGET_SUBDIR)/$${dir}/multilib.out $(TARGET_SUBDIR)/$${dir}/tmpmulti.out > /dev/null; then \
+ rm -f $(TARGET_SUBDIR)/$${dir}/tmpmulti.out; \
+ else \
+ echo "Multilibs changed for $${dir}, reconfiguring"; \
+ rm -f $(TARGET_SUBDIR)/$${dir}/multilib.out $(TARGET_SUBDIR)/$${dir}/Makefile; \
+ mv $(TARGET_SUBDIR)/$${dir}/tmpmulti.out $(TARGET_SUBDIR)/$${dir}/multilib.out; \
+ fi; \
else \
- echo "Multilibs changed for $${dir}, reconfiguring"; \
- rm -f $(TARGET_SUBDIR)/$${dir}/multilib.out $(TARGET_SUBDIR)/$${dir}/Makefile; \
mv $(TARGET_SUBDIR)/$${dir}/tmpmulti.out $(TARGET_SUBDIR)/$${dir}/multilib.out; \
fi; \
- else \
- mv $(TARGET_SUBDIR)/$${dir}/tmpmulti.out $(TARGET_SUBDIR)/$${dir}/multilib.out; \
fi; \
fi; \
+ else \
+ true; \
fi; exit 0 # break command into two pieces
@dir=`echo $@ | sed -e 's/configure-target-//'`; \
- if [ ! -d $(TARGET_SUBDIR) ]; then \
- true; \
- elif [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
- true; \
- elif echo " $(TARGET_CONFIGDIRS) " | grep " $${dir} " >/dev/null 2>&1; then \
- if [ -d $(srcdir)/$${dir} ]; then \
- [ -d $(TARGET_SUBDIR)/$${dir} ] || mkdir $(TARGET_SUBDIR)/$${dir};\
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- AR="$(AR_FOR_TARGET)"; export AR; \
- AS="$(AS_FOR_TARGET)"; export AS; \
- CC="$(CC_FOR_TARGET)"; export CC; \
- CFLAGS="$(CFLAGS_FOR_TARGET)"; export CFLAGS; \
- CXX="$(CXX_FOR_TARGET)"; export CXX; \
- CXXFLAGS="$(CXXFLAGS_FOR_TARGET)"; export CXXFLAGS; \
- DLLTOOL="$(DLLTOOL_FOR_TARGET)"; export DLLTOOL; \
- LD="$(LD_FOR_TARGET)"; export LD; \
- LDFLAGS="$(LDFLAGS_FOR_TARGET)"; export LDFLAGS; \
- NM="$(NM_FOR_TARGET)"; export NM; \
- RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
- WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
- echo Configuring in $(TARGET_SUBDIR)/$${dir}; \
- cd $(TARGET_SUBDIR)/$${dir}; \
- case $(srcdir) in \
- /*) \
- topdir=$(srcdir) ;; \
- *) \
- case "$(TARGET_SUBDIR)" in \
- .) topdir="../$(srcdir)" ;; \
- *) topdir="../../$(srcdir)" ;; \
- esac ;; \
- esac; \
- if [ "$(srcdir)" = "." ] ; then \
- if [ "$(TARGET_SUBDIR)" != "." ] ; then \
- if $(SHELL) $$s/symlink-tree $${topdir}/$${dir} "no-such-file" ; then \
- if [ -f Makefile ]; then \
- if $(MAKE) distclean; then \
- true; \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ ! -d $(TARGET_SUBDIR) ]; then \
+ true; \
+ elif [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
+ true; \
+ elif echo " $(TARGET_CONFIGDIRS) " | grep " $${dir} " >/dev/null 2>&1; then \
+ if [ -d $(srcdir)/$${dir} ]; then \
+ [ -d $(TARGET_SUBDIR)/$${dir} ] || mkdir $(TARGET_SUBDIR)/$${dir};\
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ AR="$(AR_FOR_TARGET)"; export AR; \
+ AS="$(AS_FOR_TARGET)"; export AS; \
+ CC="$(CC_FOR_TARGET)"; export CC; \
+ CFLAGS="$(CFLAGS_FOR_TARGET)"; export CFLAGS; \
+ CXX="$(CXX_FOR_TARGET)"; export CXX; \
+ CXXFLAGS="$(CXXFLAGS_FOR_TARGET)"; export CXXFLAGS; \
+ DLLTOOL="$(DLLTOOL_FOR_TARGET)"; export DLLTOOL; \
+ LD="$(LD_FOR_TARGET)"; export LD; \
+ LDFLAGS="$(LDFLAGS_FOR_TARGET)"; export LDFLAGS; \
+ NM="$(NM_FOR_TARGET)"; export NM; \
+ RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
+ WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
+ echo Configuring in $(TARGET_SUBDIR)/$${dir}; \
+ cd $(TARGET_SUBDIR)/$${dir}; \
+ case $(srcdir) in \
+ /*) \
+ topdir=$(srcdir) ;; \
+ *) \
+ case "$(TARGET_SUBDIR)" in \
+ .) topdir="../$(srcdir)" ;; \
+ *) topdir="../../$(srcdir)" ;; \
+ esac ;; \
+ esac; \
+ if [ "$(srcdir)" = "." ] ; then \
+ if [ "$(TARGET_SUBDIR)" != "." ] ; then \
+ if $(SHELL) $$s/symlink-tree $${topdir}/$${dir} "no-such-file" ; then \
+ if [ -f Makefile ]; then \
+ if $(MAKE) distclean; then \
+ true; \
+ else \
+ exit 1; \
+ fi; \
else \
- exit 1; \
+ true; \
fi; \
else \
- true; \
+ exit 1; \
fi; \
else \
- exit 1; \
+ true; \
fi; \
+ srcdiroption="--srcdir=."; \
+ libsrcdir="."; \
else \
- true; \
+ srcdiroption="--srcdir=$${topdir}/$${dir}"; \
+ libsrcdir="$$s/$${dir}"; \
+ fi; \
+ if [ -f $${libsrcdir}/configure ] ; then \
+ rm -f no-such-file; \
+ CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
+ $(CONFIG_ARGUMENTS) $${srcdiroption} \
+ --with-target-subdir="$(TARGET_SUBDIR)"; \
+ else \
+ rm -f no-such-file; \
+ CONFIG_SITE=no-such-file $(SHELL) $$s/configure \
+ $(CONFIG_ARGUMENTS) $${srcdiroption} \
+ --with-target-subdir="$(TARGET_SUBDIR)"; \
fi; \
- srcdiroption="--srcdir=."; \
- libsrcdir="."; \
- else \
- srcdiroption="--srcdir=$${topdir}/$${dir}"; \
- libsrcdir="$$s/$${dir}"; \
- fi; \
- if [ -f $${libsrcdir}/configure ] ; then \
- rm -f no-such-file; \
- CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
- $(CONFIG_ARGUMENTS) $${srcdiroption} \
- --with-target-subdir="$(TARGET_SUBDIR)"; \
else \
- rm -f no-such-file; \
- CONFIG_SITE=no-such-file $(SHELL) $$s/configure \
- $(CONFIG_ARGUMENTS) $${srcdiroption} \
- --with-target-subdir="$(TARGET_SUBDIR)"; \
+ true; \
fi; \
else \
true; \
@@ -1222,11 +1366,35 @@ $(CONFIGURE_TARGET_MODULES):
.PHONY: $(ALL_TARGET_MODULES)
$(ALL_TARGET_MODULES):
@dir=`echo $@ | sed -e 's/all-target-//'`; \
- if [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- (cd $(TARGET_SUBDIR)/$${dir}; $(MAKE) $(TARGET_FLAGS_TO_PASS) all); \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ (cd $(TARGET_SUBDIR)/$${dir}; $(MAKE) $(TARGET_FLAGS_TO_PASS) all); \
+ else \
+ true; \
+ fi; \
else \
true; \
fi
@@ -1236,11 +1404,35 @@ $(ALL_TARGET_MODULES):
.PHONY: $(CHECK_TARGET_MODULES)
$(CHECK_TARGET_MODULES):
@dir=`echo $@ | sed -e 's/check-target-//'`; \
- if [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- (cd $(TARGET_SUBDIR)/$${dir};$(MAKE) $(TARGET_FLAGS_TO_PASS) check);\
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ (cd $(TARGET_SUBDIR)/$${dir};$(MAKE) $(TARGET_FLAGS_TO_PASS) check);\
+ else \
+ true; \
+ fi; \
else \
true; \
fi
@@ -1251,12 +1443,36 @@ $(CHECK_TARGET_MODULES):
.PHONY: $(INSTALL_TARGET_MODULES)
$(INSTALL_TARGET_MODULES): installdirs
@dir=`echo $@ | sed -e 's/install-target-//'`; \
- if [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
- r=`pwd`; export r; \
- s=`cd $(srcdir); pwd`; export s; \
- $(SET_LIB_PATH) \
- (cd $(TARGET_SUBDIR)/$${dir}; \
- $(MAKE) $(TARGET_FLAGS_TO_PASS) install); \
+ case "$${dir}:$(LANGUAGES)" in \
+ "libchill:"*"CHILL"* | \
+ "libf2c:"*"f77"* | \
+ "libio:"*"c++"* | \
+ "libstdc++:"*"c++"* | \
+ "libg++:"*"c++"* | \
+ "librx:"*"c++"* | \
+ "libobjc:"*"objc"* ) \
+ do_action=yes ;; \
+ "libchill:"* | \
+ "libf2c:"* | \
+ "libio:"* | \
+ "libstdc++:"* | \
+ "libg++:"* | \
+ "librx:"* | \
+ "libobjc:"* ) \
+ do_action=no ;; \
+ * ) \
+ do_action=yes ;; \
+ esac; \
+ if [ $${do_action} = yes ]; then \
+ if [ -f $(TARGET_SUBDIR)/$${dir}/Makefile ] ; then \
+ r=`pwd`; export r; \
+ s=`cd $(srcdir); pwd`; export s; \
+ $(SET_LIB_PATH) \
+ (cd $(TARGET_SUBDIR)/$${dir}; \
+ $(MAKE) $(TARGET_FLAGS_TO_PASS) install); \
+ else \
+ true; \
+ fi; \
else \
true; \
fi
diff -rup -x CVS -x RCS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el egcs-19980929.orig/configure egcs-19980929/configure
--- egcs-19980929.orig/configure Tue Sep 29 11:10:55 1998
+++ egcs-19980929/configure Tue Sep 29 15:16:02 1998
@@ -825,6 +825,12 @@ do
test -n "$DEFAULT_LEX" && break
done
+# Look if the user specified --enable-languages="..."; if not, use
+# the environment variable $LANGUAGES if defined.
+if test "${enable_languages+set}" != set && test "${LANGUAGES+set}" = set; then
+ enable_languages="`echo ${LANGUAGES} | tr ' ' ','`"
+fi
+
if [ "${build}" != "${host}" ]; then
# If we are doing a Canadian Cross, in which the host and build systems
# are not the same, we set reasonable default values for the tools.
@@ -1214,6 +1220,14 @@ build_os = ${build_os}
build_canonical = ${build_cpu}-${build_vendor}-${build_os}
EOF
esac
+
+ # Generate the appropriate default list of languages the user
+ # "normally" intends to build.
+ # If the user did not specify anything, we don't emit anything
+ # here, which means "default to build all available languages".
+ if test "${subdir}/" = "./" && test "${enable_languages+set}" = set; then
+ echo "LANGUAGES = `echo ${enable_languages} | tr ',' ' '`" >> ${Makefile}
+ fi
case "${package_makefile_frag}" in
"") ;;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to run only test where appropriate
1998-09-29 10:10 ` Jeffrey A Law
@ 1998-09-29 23:25 ` Manfred Hollstein
0 siblings, 0 replies; 27+ messages in thread
From: Manfred Hollstein @ 1998-09-29 23:25 UTC (permalink / raw)
To: law; +Cc: egcs-patches, burley, jbuck, pfeifer, egcs
On Tue, 29 September 1998, 10:34:06, law@cygnus.com wrote:
>
> In message < 13840.60777.577076.232891@slsvhmt >you write:
> > This patch
> >
> > - adds code to check if the compiler to be tested even exists,
> > - eliminates the redundancy of having a separate "check-" target
> > for each compiler; they actually only differ in the `--tool'
> > argument.
> >
> > OK to install?
> No. In the absence of binaries for the compiler in the build directory the
> testsuite should use the compilers from the install tree. Your patch would
> disable that behavior as far as I can tell.
>
> jeff
Ah, I didn't know this was intended.
manfred
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?)
1998-09-29 10:10 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Manfred Hollstein
1998-09-29 10:10 ` PATCH to run only test where appropriate Manfred Hollstein
@ 1998-09-30 4:15 ` Jeffrey A Law
1998-09-30 8:07 ` PATCH to pre-select languages to be build Manfred Hollstein
1 sibling, 1 reply; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-30 4:15 UTC (permalink / raw)
To: manfred, Manfred.Hollstein; +Cc: burley, jbuck, pfeifer, egcs
In message < 13840.57066.10628.804866@slsvhmt >you write:
> On Wed, 16 September 1998, 08:39:53, manfred@s-direktnet.de wrote:
>
> > On Tue, 15 September 1998, 02:10:15, law@cygnus.com wrote:
> >
> > >
> > > This kind of scheme works better if we ever have an option to
> > > enable/disable a language at configure time. ie --disable-chill
> > > or something like that to disable the chill compiler, even if
> > > it is in your source tree and you don't remember LANGUAGES="..." :-)
> >
> > Is anybody working on this already? I'd like to implement this as I've
> > stumbled across this especially on my damn slow 68k machine (which is
> > - even worse - using multilibs :-( ); but unfortunately I'm rather
> > busy doing other things at the moment, I guess I'll be having a patch
> > available in 1 to 2 weeks. OK?
> >
> > manfred
>
> The approach you were talking about assumes, everybody who wants to
> restrict the languages to a particular subset
>
> - knows which languages do exist and which do I want.
>
> My patch below goes the other way round. It's based on the assumption
> that most people
>
> - know which languages they actually want to build.
>
> If the "--disable-chill" would have been available before the recent
> languages had been introduced, all users, that only wanted "c c++" to
> be built, would still get the new compilers, simply because they
> didn't know such a beast exists.
I think there's a much simpler way to do this. Something like this in gcc/configure.in
# Figure out what language subdirectories are present.
subdirs=
for lang in ${srcdir}/*/config-lang.in ..
do
case $lang in
..) ;;
# The odd quoting in the next line works around
# an apparent bug in bash 1.12 on linux.
${srcdir}/[[*]]/config-lang.in) ;;
# CYGNUS LOCAL nofortran/law
${srcdir}/f/config-lang.in)
if [[ x$enable_fortran = xyes ]]; then
subdirs="$subdirs `echo $lang | sed -e 's,^.*/\([[^/]]*\)/config-lang.in$,\1,'`"
fi
;;
${srcdir}/objc/config-lang.in)
if [[ x$enable_objc = xyes ]]; then
subdirs="$subdirs `echo $lang | sed -e 's,^.*/\([[^/]]*\)/config-lang.in$,\1,'`"
fi
;;
# END CYGNUS LOCAL
*) subdirs="$subdirs `echo $lang | sed -e 's,^.*/\([[^/]]*\)/config-lang.in$,\1,'`" ;;
esac
done
This is what we're using inside Cygnus to disable fortran & objc. It's easily
extended to handle additional languages and to support a full enable/disable
syntax.
We then have the associated runtime libraries automatically disable themselves
if the proper compiler isn't found in <objdir>/gcc. This should be fairly
simple too, though we haven't actually tried it.
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-09-30 4:15 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Jeffrey A Law
@ 1998-09-30 8:07 ` Manfred Hollstein
1998-09-30 17:36 ` Jeffrey A Law
0 siblings, 1 reply; 27+ messages in thread
From: Manfred Hollstein @ 1998-09-30 8:07 UTC (permalink / raw)
To: law; +Cc: burley, jbuck, pfeifer, egcs
On Wed, 30 September 1998, 03:19:22, law@cygnus.com wrote:
>
[snip]
>
> In message < 13840.57066.10628.804866@slsvhmt >you write:
> >
> > The approach you were talking about assumes, everybody who wants to
> > restrict the languages to a particular subset
> >
> > - knows which languages do exist and which do I want.
> >
> > My patch below goes the other way round. It's based on the assumption
> > that most people
> >
> > - know which languages they actually want to build.
> >
> > If the "--disable-chill" would have been available before the recent
> > languages had been introduced, all users, that only wanted "c c++" to
> > be built, would still get the new compilers, simply because they
> > didn't know such a beast exists.
> I think there's a much simpler way to do this. Something like this in gcc/configure.in
> # Figure out what language subdirectories are present.
[script removed]
>
> This is what we're using inside Cygnus to disable fortran & objc. It's easily
> extended to handle additional languages and to support a full enable/disable
> syntax.
>
> We then have the associated runtime libraries automatically disable themselves
> if the proper compiler isn't found in <objdir>/gcc. This should be fairly
> simple too, though we haven't actually tried it.
>
> jeff
>
>
Well, I could implement this in addition, too. But there's a problem
with this approach: let's suppose Craig wants to build the C and the
F77 (only! no c++ ...) compilers, hence he wants to disable c++ (note,
this name is used for $(LANGUAGES)!); thus he adds `--disable-c++' to
his configure command. I guess you know the result:
From the toplevel configure file:
sh: enable_c++=no: command not found
and inside the gcc subdirectory:
configure: error: c++: invalid feature name
This is caused by `c++' not being a valid shell variable name. OK, we
can hack our toplevel configure script replacing '+' with 'x', but we
would have to do this for autoconf, too, and I believe this might be
hard to get a fixed autoconf in time... . Another solution might be
to use different name, i.e. `--disable-cxx', but then we'd have to
use "c++" for $(LANGUAGES) and "cxx" for the --enable-/--disable-
stuff :-(
My argument concerning new compilers in a new tarball still stands,
too. The average test user gets a new egcs-x.y.tar.gz file, untars
it, and calls his usual build script/comand, e.g.
$ configure --disable-f77 --disable-objc
$ make LANGUAGES="c c++" bootstrap install
ending up with two unwanted compilers installed (CHILL and Java); he
simply wasn't aware of their existance.
Although the changes to the toplevel Makefile.in might look ugly, they
are completely transparent to the user.
manfred
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-09-30 8:07 ` PATCH to pre-select languages to be build Manfred Hollstein
@ 1998-09-30 17:36 ` Jeffrey A Law
1998-10-01 3:25 ` Gerald Pfeifer
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Jeffrey A Law @ 1998-09-30 17:36 UTC (permalink / raw)
To: manfred, Manfred.Hollstein; +Cc: burley, jbuck, pfeifer, egcs
In message <13842.2446.855496.247677@slsvhmt>you write:
> Well, I could implement this in addition, too. But there's a problem
> with this approach: let's suppose Craig wants to build the C and the
> F77 (only! no c++ ...) compilers, hence he wants to disable c++ (note,
> this name is used for $(LANGUAGES)!); thus he adds `--disable-c++' to
> his configure command. I guess you know the result:
>
> >From the toplevel configure file:
>
> sh: enable_c++=no: command not found
>
> and inside the gcc subdirectory:
>
> configure: error: c++: invalid feature name
>
> This is caused by `c++' not being a valid shell variable name. OK, we
> can hack our toplevel configure script replacing '+' with 'x', but we
> would have to do this for autoconf, too, and I believe this might be
> hard to get a fixed autoconf in time... . Another solution might be
> to use different name, i.e. `--disable-cxx', but then we'd have to
> use "c++" for $(LANGUAGES) and "cxx" for the --enable-/--disable-
> stuff :-(
Ugh. I'd almost prefer to replace + with x as needed. The code is really
simpler than your approach.
> My argument concerning new compilers in a new tarball still stands,
> too. The average test user gets a new egcs-x.y.tar.gz file, untars
> it, and calls his usual build script/comand, e.g.
By default we should build all languages. The user must explicitly specify
that they do not want particular languages. I think we've agreed on that.
jeff
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-09-30 17:36 ` Jeffrey A Law
@ 1998-10-01 3:25 ` Gerald Pfeifer
1998-10-01 6:25 ` Manfred Hollstein
` (2 subsequent siblings)
3 siblings, 0 replies; 27+ messages in thread
From: Gerald Pfeifer @ 1998-10-01 3:25 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: manfred, Manfred.Hollstein, burley, jbuck, egcs
On Wed, 30 Sep 1998, Jeffrey A Law wrote:
>> My argument concerning new compilers in a new tarball still stands,
>> too. The average test user gets a new egcs-x.y.tar.gz file, untars
>> it, and calls his usual build script/comand, e.g.
> By default we should build all languages. The user must explicitly specify
> that they do not want particular languages. I think we've agreed on that.
The user should definitely be able to explicitely specify the languages
she wants to build as well, not only those that she does not want to
build.
(Else additions like chill and java will cause unwanted behavior from
a user perspective.)
Gerald
--
Gerald <pfeifer@dbai.tuwien.ac.at> http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-09-30 17:36 ` Jeffrey A Law
1998-10-01 3:25 ` Gerald Pfeifer
@ 1998-10-01 6:25 ` Manfred Hollstein
1998-10-01 7:28 ` Joern Rennecke
1998-10-01 16:51 ` Alexandre Oliva
3 siblings, 0 replies; 27+ messages in thread
From: Manfred Hollstein @ 1998-10-01 6:25 UTC (permalink / raw)
To: law; +Cc: burley, jbuck, pfeifer, egcs
On Wed, 30 September 1998, 13:14:00, law@cygnus.com wrote:
>
> In message <13842.2446.855496.247677@slsvhmt>you write:
> > Well, I could implement this in addition, too. But there's a problem
> > with this approach: let's suppose Craig wants to build the C and the
> > F77 (only! no c++ ...) compilers, hence he wants to disable c++ (note,
> > this name is used for $(LANGUAGES)!); thus he adds `--disable-c++' to
> > his configure command. I guess you know the result:
> >
> > >From the toplevel configure file:
> >
> > sh: enable_c++=no: command not found
> >
> > and inside the gcc subdirectory:
> >
> > configure: error: c++: invalid feature name
> >
> > This is caused by `c++' not being a valid shell variable name. OK, we
> > can hack our toplevel configure script replacing '+' with 'x', but we
> > would have to do this for autoconf, too, and I believe this might be
> > hard to get a fixed autoconf in time... . Another solution might be
> > to use different name, i.e. `--disable-cxx', but then we'd have to
> > use "c++" for $(LANGUAGES) and "cxx" for the --enable-/--disable-
> > stuff :-(
> Ugh. I'd almost prefer to replace + with x as needed. The code is really
> simpler than your approach.
>
I'm sorry if I sound pedantic. The problem is not only in our
configure file, this can be changed easily; I'm seeing major problems
with gcc's (and now libiberty as well) autoconf generated configure
file: all of them include code to check, if the feature to be enabled
or disabled
"consists only of alphanumeric characters and dashes"
(cited from autoconf.info).
Since we already have our own autoconf-9xmmdd.tar.gz file, we can
easily setup a new one with this fix applied; but, to be honest, I
don't actually know from memory, if the version I'm using is the one
from /pub/egcs/infrastructure or from /private/gas or perhaps even
from /private/gdb.
If we're going the install a patch in egcs relying on such a
particularly fixed autoconf version, we might end up with "broken"
configure scripts some day, only because somebody checked in a script
generated by his/her installed default autoconf version (i.e. 2.12);
and in addition, we'll have to make sure, these changes will be
incorporated into the upcoming 2.13, too.
I'm not opposed to the --enable-/--disable- stuff you're proposing,
but my patch works *now and for all languages*, and it doesn't depend
on fixes to be applied to "foreign" packages.
May I suggest:
1. We install my patch now; this will cover the "positive" side,
i.e. the user can specify which languages he *wants* to build.
(BTW, a similar patch to the toplevel Makefile.in would be
necessary for your patch, too)
2. Once we have a fixed autoconf version available and all egcs
maintainers are aware of it and are using it, we'll be going
to install the extensions you've suggested for those users,
that want to specify what they *don't want* to be built.
> > My argument concerning new compilers in a new tarball still stands,
> > too. The average test user gets a new egcs-x.y.tar.gz file, untars
> > it, and calls his usual build script/comand, e.g.
> By default we should build all languages. The user must explicitly specify
> that they do not want particular languages. I think we've agreed on that.
My patch doesn't change the default.
>
> jeff
manfred
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-09-30 17:36 ` Jeffrey A Law
1998-10-01 3:25 ` Gerald Pfeifer
1998-10-01 6:25 ` Manfred Hollstein
@ 1998-10-01 7:28 ` Joern Rennecke
1998-10-01 12:49 ` Manfred Hollstein
1998-10-01 16:51 ` Alexandre Oliva
3 siblings, 1 reply; 27+ messages in thread
From: Joern Rennecke @ 1998-10-01 7:28 UTC (permalink / raw)
To: law; +Cc: manfred, Manfred.Hollstein, burley, jbuck, pfeifer, egcs
> By default we should build all languages. The user must explicitly specify
> that they do not want particular languages. I think we've agreed on that.
Well, how about some alternate syntax to do this that doesn't require
to know all the languages?
E.g.: --disable-default-languages --enable-c --enable-fortran
to build only c and fortran.
No, I'm not volunteering to implement it ;-)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-10-01 7:28 ` Joern Rennecke
@ 1998-10-01 12:49 ` Manfred Hollstein
0 siblings, 0 replies; 27+ messages in thread
From: Manfred Hollstein @ 1998-10-01 12:49 UTC (permalink / raw)
To: amylaar; +Cc: law, burley, jbuck, pfeifer, egcs
On Thu, 1 October 1998, 15:27:49, amylaar@cygnus.co.uk wrote:
> > By default we should build all languages. The user must explicitly specify
> > that they do not want particular languages. I think we've agreed on that.
>
> Well, how about some alternate syntax to do this that doesn't require
> to know all the languages?
>
> E.g.: --disable-default-languages --enable-c --enable-fortran
> to build only c and fortran.
That's exactly what --enable-languages="c,f77" does, with my patch
applied ;-)
>
> No, I'm not volunteering to implement it ;-)
manfred
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: PATCH to pre-select languages to be build
1998-09-30 17:36 ` Jeffrey A Law
` (2 preceding siblings ...)
1998-10-01 7:28 ` Joern Rennecke
@ 1998-10-01 16:51 ` Alexandre Oliva
3 siblings, 0 replies; 27+ messages in thread
From: Alexandre Oliva @ 1998-10-01 16:51 UTC (permalink / raw)
To: law; +Cc: manfred, Manfred.Hollstein, burley, jbuck, pfeifer, egcs
Jeffrey A Law <law@cygnus.com> writes:
> In message <13842.2446.855496.247677@slsvhmt>you write:
>> My argument concerning new compilers in a new tarball still stands,
>> too. The average test user gets a new egcs-x.y.tar.gz file, untars
>> it, and calls his usual build script/comand, e.g.
> By default we should build all languages. The user must explicitly specify
> that they do not want particular languages. I think we've agreed on that.
IMO, all languages should be built by default. If any
--enable-lang-<language> switch is found, only the specified languages
are build. If any --disable-lang-<language> switch is found, but no
--enable-lang-<language> switch was issued, all languages but the
disabled ones should be built. For example:
configure --enable-lang-java # builds only Java
configure --disable-lang-chill # builds all but chill
configure --enable-lang-cxx --disable-lang-java # only C++, disable is ignored
configure --enable-lang-cxx --disable-lang-cxx # builds nothing?
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~1998-10-01 16:51 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-09-08 19:58 No Fortran Nathan Myers
1998-09-11 17:54 ` Gerald Pfeifer
1998-09-12 13:32 ` Jeffrey A Law
1998-09-14 17:12 ` Gerald Pfeifer
1998-09-14 15:39 ` Craig Burley
1998-09-14 22:21 ` Joe Buck
1998-09-15 7:06 ` Craig Burley
1998-09-15 1:12 ` Jeffrey A Law
1998-09-16 3:07 ` No Fortran - IS ANYBODY WORKING ON IT? Manfred Hollstein
1998-09-15 23:51 ` Jeffrey A Law
1998-09-29 10:10 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Manfred Hollstein
1998-09-29 10:10 ` PATCH to run only test where appropriate Manfred Hollstein
1998-09-29 10:10 ` Jeffrey A Law
1998-09-29 23:25 ` Manfred Hollstein
1998-09-30 4:15 ` PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?) Jeffrey A Law
1998-09-30 8:07 ` PATCH to pre-select languages to be build Manfred Hollstein
1998-09-30 17:36 ` Jeffrey A Law
1998-10-01 3:25 ` Gerald Pfeifer
1998-10-01 6:25 ` Manfred Hollstein
1998-10-01 7:28 ` Joern Rennecke
1998-10-01 12:49 ` Manfred Hollstein
1998-10-01 16:51 ` Alexandre Oliva
1998-09-15 1:05 ` No Fortran Jeffrey A Law
1998-09-15 3:02 ` Marc Espie
1998-09-15 14:14 ` Ken Raeburn
1998-09-15 0:55 ` Jeffrey A Law
1998-09-13 4:58 ` Dave Love
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).