Re: M4 problems

Re: M4 problems

[Krister Walfridsson]

Here are the changes needed to handle M4 the same way as YACC
and LEX.

   /Krister



Mon Apr 13 15:20:40 1998  Krister Walfridsson <cato@df.lth.se>

        * configure: Define DEFAULT_M4 by searching PATH.
        * Makfile.in: Use DEFAULT_M4.


*** configure.old	Fri Apr 10 19:36:19 1998
--- configure	Mon Apr 13 15:05:50 1998
***************
*** 762,767 ****
--- 762,786 ----
    test -n "$DEFAULT_YACC" && break
  done
  
+ # Generate a default definition for M4.  This is used if the makefile can't
+ # locate m4 in objdir.
+ 
+ for prog in gm4 gnum4 m4
+ do
+   set dummy $prog; tmp=$2
+   IFS="${IFS=   }"; save_ifs="$IFS"; IFS="${IFS}:"
+   for dir in $PATH; do
+     test -z "$dir" && dir=.
+     if test -f $dir/$tmp; then
+       DEFAULT_M4="$prog"
+       break
+     fi
+   done
+   IFS="$save_ifs"
+ 
+   test -n "$DEFAULT_M4" && break
+ done
+ 
  # Generate a default definition for LEX.  This is used if the makefile can't
  # locate flex in objdir.
  
***************
*** 1259,1264 ****
--- 1278,1284 ----
                      -e "s|^tooldir[ 	]*=.*$|tooldir = ${tooldir}|" \
  		    -e "s:^DEFAULT_YACC[	 ]*=.*$:DEFAULT_YACC = ${DEFAULT_YACC}:" \
  		    -e "s:^DEFAULT_LEX[	 ]*=.*$:DEFAULT_LEX = ${DEFAULT_LEX}:" \
+ 		    -e "s:^DEFAULT_M4[  ]*=.*$:DEFAULT_M4 = ${DEFAULT_M4}:" \
                      ${subdir}/Makefile.tem >> ${Makefile}
  
  	    # If this is a Canadian Cross, preset the values of many more





*** Makefile.in.old	Mon Apr 13 13:29:20 1998
--- Makefile.in	Mon Apr 13 14:56:17 1998
***************
*** 100,105 ****
--- 100,106 ----
  # These values are substituted by configure.
  DEFAULT_YACC = yacc
  DEFAULT_LEX = lex
+ DEFAULT_M4 = m4
  
  BISON = `if [ -f $$r/bison/bison ] ; then \
  	    echo $$r/bison/bison -L $$s/bison/ ; \
***************
*** 121,127 ****
  
  M4 = `if [ -f $$r/m4/m4 ] ; \
  	then echo $$r/m4/m4 ; \
! 	else echo m4 ; fi`
  
  MAKEINFO = `if [ -f $$r/texinfo/makeinfo/Makefile ] ; \
  	then echo $$r/texinfo/makeinfo/makeinfo ; \
--- 122,128 ----
  
  M4 = `if [ -f $$r/m4/m4 ] ; \
  	then echo $$r/m4/m4 ; \
! 	else echo ${DEFAULT_M4} ; fi`
  
  MAKEINFO = `if [ -f $$r/texinfo/makeinfo/Makefile ] ; \
  	then echo $$r/texinfo/makeinfo/makeinfo ; \

Re: M4 problems

[Jeffrey A Law]

  In message < Pine.LNX.3.96.980413154041.7042A-100000@bartlet.df.lth.se >you wri  > 
  > Here are the changes needed to handle M4 the same way as YACC
  > and LEX.
  > 
  >    /Krister
  > 
  > 
  > 
  > Mon Apr 13 15:20:40 1998  Krister Walfridsson <cato@df.lth.se>
  > 
  >         * configure: Define DEFAULT_M4 by searching PATH.
  >         * Makfile.in: Use DEFAULT_M4.
Thanks!  I have installed this patch.

jeff

M4 problems

[Krister Walfridsson]

Are there any good reason we define M4 in the egcs/Makefile?

The reason I don't like it is that I get errors from autoconf that I 
need GNU m4, but autoconf is generally smart enough to find my GNU m4
(which in NetBSD normlly lives in /usr/pkg/bin and is called gm4) unless
M4 is defined. And we doesn't use M4 anywhere as far I can see.

I suggest we remove the M4 definition (or is it better to do some magic 
with autoconf to see if we can find any GNU m4?)

   /Krister




Sat Apr  4 20:05:15 1998  Krister Walfridsson (cato@df.lth.se)

        * Makefile.in: Removed M4 definition.


*** Makefile.in.old     Tue Mar 31 19:35:23 1998
--- Makefile.in Sat Apr  4 20:03:13 1998
***************
*** 119,128 ****
        then echo $$r/flex/flex ; \
        else echo ${DEFAULT_LEX} ; fi`
  
- M4 = `if [ -f $$r/m4/m4 ] ; \
-       then echo $$r/m4/m4 ; \
-       else echo m4 ; fi`
- 
  MAKEINFO = `if [ -f $$r/texinfo/makeinfo/Makefile ] ; \
        then echo $$r/texinfo/makeinfo/makeinfo ; \
        else echo makeinfo ; fi`
--- 119,124 ----

Re: M4 problems

[Ian Lance Taylor]

   Date: Sat, 4 Apr 1998 20:12:36 +0200 (MET DST)
   From: Krister Walfridsson <cato@df.lth.se>

   Are there any good reason we define M4 in the egcs/Makefile?

The top level egcs Makefile is just a generic Makefile which can be
used to build a number of tools in the same directory.  It's the same
Makefile that is for binutils and gdb releases, for example.

One of the tools that it can build is autoconf.  To do that, you would
put the autoconf and m4 sources as sibling directories to gcc, and run
something like make all-autoconf.  When doing this, M4 is defined to
make the right thing happen.

   The reason I don't like it is that I get errors from autoconf that I 
   need GNU m4, but autoconf is generally smart enough to find my GNU m4
   (which in NetBSD normlly lives in /usr/pkg/bin and is called gm4) unless
   M4 is defined. And we doesn't use M4 anywhere as far I can see.

I think the right fix for the general case is probably to locate m4 in
the top level configure script, along the lines of how DEFAULT_YACC is
handled.

Ian

Re: M4 problems

[Jeffrey A Law]

  In message < Pine.LNX.3.96.980404201041.2213A-100000@bartlet.df.lth.se >you wri
te:
  > Are there any good reason we define M4 in the egcs/Makefile?
Yes.  It's part of the one tree build system.

If you take the m4 sources and put them in the source tree with egcs,
then egcs will automatically build and use the m4 binaries that you
just built instead of whatever is lying around on the system.

jeff

Re: M4 problems

[Richard Earnshaw]

> 
> 
>   In message < Pine.LNX.3.96.980404201041.2213A-100000@bartlet.df.lth.se >you wri
> te:
>   > Are there any good reason we define M4 in the egcs/Makefile?
> Yes.  It's part of the one tree build system.
> 
> If you take the m4 sources and put them in the source tree with egcs,
> then egcs will automatically build and use the m4 binaries that you
> just built instead of whatever is lying around on the system.
> 

The problem is not what happens when you have the m4 sources in your build 
tree.  It's what happens when you don't.  If you don't have the source 
then configure *assumes* that your gnu m4 is installed as 'm4' (if it 
isn't then things break).

I don't particularly want to have to have m4 in my egcs build tree (it's 
big enough already); but equally, I'm not keen on having gnu m4 installed 
as anything other than gm4 (I can't have an environment where standard 
utilities are being replaced by others -- not all my work is gnu based and 
it could result in problems in the field which I'm not aware of).

The obvious solution for this would be for the toplevel configure to 
detect (a la autoconf) where the installed version of gnu m4 is (it can 
find a gnu m4 that is installed as gm4), and to use that.

Why is this not done?

Richard.

Re: M4 problems

[Ian Lance Taylor]

   Date: Mon, 06 Apr 1998 11:12:41 +0100
   From: Richard Earnshaw <rearnsha@arm.com>

   The obvious solution for this would be for the toplevel configure to 
   detect (a la autoconf) where the installed version of gnu m4 is (it can 
   find a gnu m4 that is installed as gm4), and to use that.

   Why is this not done?

Simply because, up until now, nobody cared.

I agree that what you suggest is the right solution.  If somebody
writes the patch, we should install it.

Ian