using autoconf for lib-src/Makefile.in

using autoconf for lib-src/Makefile.in

[Dan Nicolaescu]

The use of the C preprocessor on the Makefiles is not ideal.

It seems that the number of #ifdefs in lib-src/Makefile.in is not too
high, and there's enough infrastructure in configure.in in place to make
it feasible to replace the use of the preprocessor.

This patch gets rid of the C_SWITCH_SYSTEM #ifdef.  It seems to work
fine on x86 Fedora.

Is this TRTD?


--- Makefile.in.~1.167.~	2008-07-21 11:34:27.000000000 -0700
+++ Makefile.in	2008-08-01 14:49:50.000000000 -0700
@@ -161,10 +161,6 @@ INSTALLABLES = etags${EXEEXT} ctags${EXE
 #define LIBS_MACHINE
 #endif
 
-#ifndef C_SWITCH_SYSTEM
-#define C_SWITCH_SYSTEM
-#endif
-
 #ifndef C_SWITCH_MACHINE
 #define C_SWITCH_MACHINE
 #endif
@@ -237,16 +233,16 @@ LOADLIBES=LIBS_SYSTEM LIBS_MACHINE
    Some other files - those shared with other GNU utilities - need
    HAVE_CONFIG_H #defined before they know they can take advantage of
    the information in ../src/config.h.  */
-ALL_CFLAGS = C_SWITCH_SYSTEM C_SWITCH_MACHINE -DHAVE_CONFIG_H \
+ALL_CFLAGS = @c_switch_system@ C_SWITCH_MACHINE -DHAVE_CONFIG_H \
    -I. -I../src -I${srcdir} -I${srcdir}/../src ${LDFLAGS} ${CPPFLAGS} ${CFLAGS}
-LINK_CFLAGS = C_SWITCH_SYSTEM C_SWITCH_MACHINE -DHAVE_CONFIG_H \
+LINK_CFLAGS = @c_switch_system@ C_SWITCH_MACHINE -DHAVE_CONFIG_H \
    -I. -I../src -I${srcdir} -I${srcdir}/../src ${LDFLAGS} ${CFLAGS}
-CPP_CFLAGS = C_SWITCH_SYSTEM C_SWITCH_MACHINE -DHAVE_CONFIG_H \
+CPP_CFLAGS = @c_switch_system@ C_SWITCH_MACHINE -DHAVE_CONFIG_H \
    -I. -I../src -I${srcdir} -I${srcdir}/../src ${CPPFLAGS} ${CFLAGS}
 /* This was all of CPP_CFLAGS except -Demacs.
    Now that -Demacs has been deleted from CPP_CFLAGS,
    this is actually the same as CPP_CFLAGS, but let\'s not delete it yet.  */
-BASE_CFLAGS = C_SWITCH_SYSTEM C_SWITCH_MACHINE -DHAVE_CONFIG_H \
+BASE_CFLAGS = @c_switch_system@ C_SWITCH_MACHINE -DHAVE_CONFIG_H \
    -I. -I../src -I${srcdir} -I${srcdir}/../src ${CPPFLAGS} ${CFLAGS}
 \f
 .SUFFIXES: .m

Re: using autoconf for lib-src/Makefile.in

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> The use of the C preprocessor on the Makefiles is not ideal.
>
> It seems that the number of #ifdefs in lib-src/Makefile.in is not too
> high, and there's enough infrastructure in configure.in in place to make
> it feasible to replace the use of the preprocessor.
>
> This patch gets rid of the C_SWITCH_SYSTEM #ifdef.  It seems to work
> fine on x86 Fedora.
>
> Is this TRTD?

Note that such changes shouldn't be checked in right now.  During the
testing phase, checkins should fix actual bugs.

Re: using autoconf for lib-src/Makefile.in

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > The use of the C preprocessor on the Makefiles is not ideal.
  > >
  > > It seems that the number of #ifdefs in lib-src/Makefile.in is not too
  > > high, and there's enough infrastructure in configure.in in place to make
  > > it feasible to replace the use of the preprocessor.
  > >
  > > This patch gets rid of the C_SWITCH_SYSTEM #ifdef.  It seems to work
  > > fine on x86 Fedora.
  > >
  > > Is this TRTD?
  > 
  > Note that such changes shouldn't be checked in right now. 

No intention to do that whatsoever.  It's just better to create a public
record of this so that it does not get completely forgotten (I probably will). 

Re: using autoconf for lib-src/Makefile.in

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> This patch gets rid of the C_SWITCH_SYSTEM #ifdef.  It seems to work
> fine on x86 Fedora.

BTW, isn't it generally considered a good idea to not use @fooo@
substitutions directly in make rules, but rather use them indirectly via
a make variable?

E.g., instead of:

   some_dep: @blargh@ other_stuff

Use:

   BLARGH = @blargh@
   ...
   some_dep: $(BLARGH) other_stuff

[Where the definition of BLARGH is near the beginning of the makefile
with other var defs.]

-Miles

-- 
Justice, n. A commodity which in a more or less adulterated condition the
State sells to the citizen as a reward for his allegiance, taxes and personal
service.

Re: using autoconf for lib-src/Makefile.in

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > This patch gets rid of the C_SWITCH_SYSTEM #ifdef.  It seems to work
  > > fine on x86 Fedora.
  > 
  > BTW, isn't it generally considered a good idea to not use @fooo@
  > substitutions directly in make rules, but rather use them indirectly via
  > a make variable?

Thanks, wasn't aware of that.
With this fixed, is the rest of the approach TRTD?

Re: using autoconf for lib-src/Makefile.in

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > BTW, isn't it generally considered a good idea to not use @fooo@
>   > substitutions directly in make rules, but rather use them indirectly via
>   > a make variable?
>
> Thanks, wasn't aware of that.
> With this fixed, is the rest of the approach TRTD?

Er, well I dunno really; seems like there's a lot of other uses of
C_SWITCH_SYSTEM in there that you don't change...

-Miles

-- 
White, adj. and n. Black.

Re: using autoconf for lib-src/Makefile.in

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > BTW, isn't it generally considered a good idea to not use @fooo@
  > >   > substitutions directly in make rules, but rather use them indirectly via
  > >   > a make variable?
  > >
  > > Thanks, wasn't aware of that.
  > > With this fixed, is the rest of the approach TRTD?
  > 
  > Er, well I dunno really; seems like there's a lot of other uses of
  > C_SWITCH_SYSTEM in there that you don't change...

In lib-src/Makefile.in ? For this first experiment let's just look at
lib-src/Makefile.in.

Re: using autoconf for lib-src/Makefile.in

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> In lib-src/Makefile.in ? For this first experiment let's just look at
> lib-src/Makefile.in.

In that case, seems reasonable, at least as far as Makefile.in is
considered....

Does a proper subst get defined by configure though?  At least, I don't
see any obvious calls to AC_SUBST for C_SWITCH_SYSTEM....

-Miles

-- 
Discriminate, v.i. To note the particulars in which one person or thing is,
if possible, more objectionable than another.

Re: using autoconf for lib-src/Makefile.in

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > In lib-src/Makefile.in ? For this first experiment let's just look at
  > > lib-src/Makefile.in.
  > 
  > In that case, seems reasonable, at least as far as Makefile.in is
  > considered....
  > 
  > Does a proper subst get defined by configure though?  At least, I don't
  > see any obvious calls to AC_SUBST for C_SWITCH_SYSTEM....

There is one for c_switch_system, and @c_switch_system@ is what the
proposal uses in lib-src/Makefile.in.

Re: using autoconf for lib-src/Makefile.in

[Stefan Monnier]

>> Note that such changes shouldn't be checked in right now. 

> No intention to do that whatsoever.  It's just better to create
> a public record of this so that it does not get completely forgotten
> (I probably will). 

Maybe we could create a Bzr branch for such patches?


        Stefan

Re: using autoconf for lib-src/Makefile.in

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> Note that such changes shouldn't be checked in right now. 
  > 
  > > No intention to do that whatsoever.  It's just better to create
  > > a public record of this so that it does not get completely forgotten
  > > (I probably will). 
  > 
  > Maybe we could create a Bzr branch for such patches?

I'd say: YES.  Hopefully more people will join the effort.

Re: using autoconf for lib-src/Makefile.in

[Stefan Monnier]

>> >> Note that such changes shouldn't be checked in right now. 
>> > No intention to do that whatsoever.  It's just better to create
>> > a public record of this so that it does not get completely forgotten
>> > (I probably will). 
>> Maybe we could create a Bzr branch for such patches?
> I'd say: YES.  Hopefully more people will join the effort.

Please do, then.


        Stefan