preprocessing Makefile

preprocessing Makefile

[Alexander Klimov]

Hi.

I have GTK installed in a directory with a name that contains
/soft-linux/. A Makefile is generated by a C preprocessor and as a
result the path is converted to .../soft-1/... and I have an error
during compilation of emacs from cvs:

 gcc -c [...] -I[...]/soft-1/include/gtk-2.0 [...]

Since `echo | gcc -E -dM - | grep -v __' gives me

#define i386 1
#define unix 1
#define linux 1

I suspect that I would have similar problems with `unix' or the
processor name in the path.

One solution is to set CPP="gcc -E -undef" or at least -Ulinux in my
case, but I am not sure if this does not introduce other problems
(currently bootstrap fails for me even on a system that does not
have this problem with paths).

-- 
Regards,
ASK

Re: preprocessing Makefile

[Thien-Thi Nguyen]

() Alexander Klimov <alserkli@inbox.ru>
() Thu, 19 Jul 2007 12:41:57 +0300 (IDT)

   One solution is to set CPP="gcc -E -undef" or at least -Ulinux in my
   case, but I am not sure if this does not introduce other problems
   (currently bootstrap fails for me even on a system that does not
   have this problem with paths).

another one is to ditch the preprocessing altogether, shifting such
configuration duties fully to autoconf.  i wonder why this was never
done.  too hairy?  certainly mucking w/ the preprocessor (generally,
build flow) was a large part of the pain for the vms port.

i understand that early autoconf was not up to the task of configuring
emacs, but perhaps these days it can be cajoled to DTRT.  does anyone
object to this kind of revamp?  if so, why?

thi

Re: preprocessing Makefile

[Richard Stallman]

    i understand that early autoconf was not up to the task of configuring
    emacs, but perhaps these days it can be cajoled to DTRT.  does anyone
    object to this kind of revamp?  if so, why?

The existing mechanism is very powerful.  I started using it long
before there was anything like autoconf.

I don't know the autoconf features that would replace it.  If they are
equally powerful, then I don't mind if we switch to them.  Can you
explain how they work?  How about emailing me (personally) the
relevant documentation?

Re: preprocessing Makefile

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Thu, 19 Jul 2007 17:21:13 -0400

   I don't know the autoconf features that would replace it.  If
   they are equally powerful, then I don't mind if we switch to
   them.  Can you explain how they work?  How about emailing me
   (personally) the relevant documentation?

ok, i'll do that as soon as i gather my thoughts.

as for the OP's problem, the configure script includes the fragment:

  # Now get this: Some word that is part of the ${srcdir} directory name
  # or the ${configuration} value might, just might, happen to be an
  # identifier like `sun4' or `i386' or something, and be predefined by
  # the C preprocessor to some helpful value like 1, or maybe the empty
  # string.  Needless to say consequent macro substitutions are less
  # than conducive to the makefile finding the correct directory.
  undefs="`echo $top_srcdir $configuration $canonical |
  sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/  *$//' \
      -e 's/  */ -U/g' -e 's/-U[0-9][^ ]*//g' \
  `"

which purports to avoid the s/linux/1/ problem by arranging to
undefine (via -U) portions of the directory name (among other
stuff).  the bug is that the variable for the top srcdir is no
longer top_srcdir, but ac_top_srcdir.

to see if this diagnosis is correct, OP can change "$top_srcdir"
on the line that begins undefs=... to be "$ac_top_srcdir" in the
configure script directly (skipping the configure.in to configure
generation step), then rerun the configuration.  then let us know
what results.

i suspect `configuration' and `canonical' may likewise need to be
updated, but i haven't checked those variables.

thi

Re: preprocessing Makefile

[Thien-Thi Nguyen]

() Thien-Thi Nguyen <ttn@gnuvola.org>
() Sat, 21 Jul 2007 00:37:16 +0200

   to be "$ac_top_srcdir"

well, turns out even ac_top_srcdir yields nothing (for me).  w/ further
mucking, i was able to get these variables set by adding the block:

  _ACEOF
  echo "configuration=\"$configuration\"" >>$CONFIG_STATUS
  echo "canonical=\"$canonical\""     >>$CONFIG_STATUS
  cat >>$CONFIG_STATUS <<\_ACEOF
  
  echo "HEY: $srcdir"
  echo "HEY: $configuration"
  echo "HEY: $canonical"

between the "# now get this" comment paragraph and the undefs= line
(without the indentation).  to check, i turned on command display
immediately prior to the cpp commands further down (~L24800) in two
places, like so:

  set -x
  $CPP $undefs -I. -I$srcdir/src $CPPFLAGS junk.c | \

when i do ./config.status --recheck, i see:

  HEY: /home/ttn/build/GNU/emacs
  HEY: i686-pc-linux-gnu
  HEY: i686-pc-linux-gnu
  creating src/epaths.h
  src/epaths.h is unchanged
  creating lib-src/Makefile
  + gcc -E -Uhome -Uttn -Ubuild -UGNU -Uemacs -Ui686 -Upc -Ulinux -Ugnu -Ui686 -Upc -Ulinux -Ugnu -I. -I/home/ttn/build/GNU/emacs/src -D_BSD_SOURCE junk.c
  + sed -e 's/^ /	/' -e '/^#/d' -e '/^[ 	\f]*$/d'
  + cat junk1.c junk2.c
  + rm -f junk.c junk1.c junk2.c
  + chmod 444 Makefile.new
  + mv -f Makefile.new Makefile
  creating src/Makefile
  + gcc -E -Uhome -Uttn -Ubuild -UGNU -Uemacs -Ui686 -Upc -Ulinux -Ugnu -Ui686 -Upc -Ulinux -Ugnu -I. -I/home/ttn/build/GNU/emacs/src -D_BSD_SOURCE junk.c
  + sed -e 's/^ /	/' -e '/^#/d' -e '/^[ 	\f]*$/d'
  + cat junk1.c junk2.c
  + rm -f junk.c junk1.c junk2.c
  + chmod 444 Makefile.new
  + mv -f Makefile.new Makefile

which shows the undefs being generated.  yuk!  now i'm feeling the
nausea from autoconf (1.1xx) for vms memories surrounding me....
time for bed.

thi

Re: preprocessing Makefile

[Alexander Klimov]

On Sat, 21 Jul 2007, Thien-Thi Nguyen wrote:
> to see if this diagnosis is correct, OP can change "$top_srcdir"
> on the line that begins undefs=... to be "$ac_top_srcdir" in the
> configure script directly (skipping the configure.in to configure
> generation step), then rerun the configuration.  then let us know
> what results.

I changed the line to be

  undefs="`echo $ac_top_srcdir $configuration ...

and get exactly the same error with soft-1 as before.

As a next attempt I put

  undefs=-undef

instead of that and the soft-1 problem gone, but a strange new problem
emerge:

  make[2]: Entering directory `.../emacs-cvs/src
  gcc -c ... pre-crt0.c
  make[2]: *** No rule to make target `/usr/lib/crt0.o', needed by `temacs'.  Stop.
  make[2]: Leaving directory `.../emacs-cvs/src'

It is true, I don't have `/usr/lib/crt0.o', although there are
/usr/lib/crt{1,i,n}.o


I suspect that all this problems relate to GTK: I used .../soft-linux
as prefix for emacs for a long time and the only recent change was
that I installed new GTK into that directory. If I run configure with
--with-x-toolkit=lucid, the c-compilation runs smoothly, and I am
stuck while the autoloads are generated:

  Generating autoloads for progmodes/ps-mode.el...done
  Generating autoloads for ps-mule.el...
  End of file during parsing
  make[2]: *** [autoloads] Error 255
  make[2]: Leaving directory `.../emacs-cvs/lisp'

-- 
Regards,
ASK

Re: preprocessing Makefile

[Alexander Klimov]

On Mon, 23 Jul 2007, Alexander Klimov wrote:
> I suspect that all this problems relate to GTK: I used .../soft-linux
> as prefix for emacs for a long time and the only recent change was
> that I installed new GTK into that directory. If I run configure with
> --with-x-toolkit=lucid, the c-compilation runs smoothly, and I am
> stuck while the autoloads are generated:
>
>   Generating autoloads for progmodes/ps-mode.el...done
>   Generating autoloads for ps-mule.el...
>   End of file during parsing
>   make[2]: *** [autoloads] Error 255
>   make[2]: Leaving directory `.../emacs-cvs/lisp'

I removed lisp and re-update it from cvs, now I can bootstrap emacs
with `lucid', `no', and `motif' toolkits, but not with gtk. Btw,
motif compiled, but if I try to select something from font menu, emacs
crashes with the following message:

  X protocol error: BadAccess (attempt to access private resource
  denied) on protocol request 33

-- 
Regards,
ASK

Re: preprocessing Makefile

[Alexander Klimov]

On Mon, 23 Jul 2007, Alexander Klimov wrote:
> I suspect that all this problems relate to GTK: I used .../soft-linux
> as prefix for emacs for a long time and the only recent change was
> that I installed new GTK into that directory. If I run configure with
> --with-x-toolkit=lucid, the c-compilation runs smoothly

The problem (`soft-1' instead of `soft-linux' [1]) is back, and now it
does not allow me to bootstrap even with lucid:

 gcc -c [...] -I[...]/soft-1/include/freetype2 [...] ftfont.c
 In file included from
 [...]soft-linux/include/fontconfig/fcfreetype.h:27,
                 from ftfont.c:28:
 [...]soft-linux/include/ft2build.h:56:38: error:
  freetype/config/ftheader.h: No such file or directory

Btw, the latest version I built before that was on 2008-03-04.

[1] <http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01027.html>

-- 
Regards,
ASK

Re: preprocessing Makefile

[Glenn Morris]

Alexander Klimov wrote:

> On Mon, 23 Jul 2007, Alexander Klimov wrote:
>> I suspect that all this problems relate to GTK: I used .../soft-linux
>> as prefix for emacs for a long time and the only recent change was
>> that I installed new GTK into that directory. If I run configure with
>> --with-x-toolkit=lucid, the c-compilation runs smoothly
>
> The problem (`soft-1' instead of `soft-linux' [1]) is back, and now it
> does not allow me to bootstrap even with lucid:

Sorry about the huge delay. Hopefully this is fixed now.