* 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-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 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-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 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 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 - 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: 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
* 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
* 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
* 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
* 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
* 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-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-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 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-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
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).