No Fortran

No Fortran

[Nathan Myers]

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

Re: No Fortran

[Gerald Pfeifer]

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/

Re: No Fortran

[Jeffrey A Law]

  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

Re: No Fortran

[Gerald Pfeifer]

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/

Re: No Fortran

[Craig 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)

Re: No Fortran

[Joe Buck]

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

Re: No Fortran

[Craig 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)

Re: No Fortran

[Jeffrey A Law]

  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

Re: No Fortran - IS ANYBODY WORKING ON IT?

[Manfred Hollstein]

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

Re: No Fortran - IS ANYBODY WORKING ON IT?

[Jeffrey A Law]

  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

PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?)

[Manfred Hollstein]

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
               "") ;;

PATCH to run only test where appropriate

[Manfred Hollstein]

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.
 

Re: PATCH to run only test where appropriate

[Jeffrey A Law]

  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

Re: PATCH to run only test where appropriate

[Manfred Hollstein]

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

Re: PATCH to pre-select languages to be build (was: Re: No Fortran - IS ANYBODY WORKING ON IT?)

[Jeffrey A Law]

  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

Re: PATCH to pre-select languages to be build

[Manfred Hollstein]

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

Re: PATCH to pre-select languages to be build

[Jeffrey A Law]

  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

Re: PATCH to pre-select languages to be build

[Gerald Pfeifer]

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/

Re: PATCH to pre-select languages to be build

[Manfred Hollstein]

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

Re: PATCH to pre-select languages to be build

[Joern Rennecke]

> 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 ;-)

Re: PATCH to pre-select languages to be build

[Manfred Hollstein]

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

Re: PATCH to pre-select languages to be build

[Alexandre Oliva]

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

Re: No Fortran

[Jeffrey A Law]

  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

Re: No Fortran

[Marc Espie]

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

Re: No Fortran

[Ken Raeburn]

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

Re: No Fortran

[Jeffrey A Law]

  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

Re: No Fortran

[Dave Love]

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