* preprocessing Makefile
@ 2007-07-19 9:41 Alexander Klimov
2007-07-19 10:02 ` Thien-Thi Nguyen
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Klimov @ 2007-07-19 9:41 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-19 9:41 preprocessing Makefile Alexander Klimov
@ 2007-07-19 10:02 ` Thien-Thi Nguyen
2007-07-19 21:21 ` Richard Stallman
0 siblings, 1 reply; 9+ messages in thread
From: Thien-Thi Nguyen @ 2007-07-19 10:02 UTC (permalink / raw
To: Alexander Klimov; +Cc: emacs-devel
() 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-19 10:02 ` Thien-Thi Nguyen
@ 2007-07-19 21:21 ` Richard Stallman
2007-07-20 22:37 ` Thien-Thi Nguyen
0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2007-07-19 21:21 UTC (permalink / raw
To: Thien-Thi Nguyen; +Cc: alserkli, emacs-devel
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-19 21:21 ` Richard Stallman
@ 2007-07-20 22:37 ` Thien-Thi Nguyen
2007-07-20 23:30 ` Thien-Thi Nguyen
2007-07-23 8:36 ` Alexander Klimov
0 siblings, 2 replies; 9+ messages in thread
From: Thien-Thi Nguyen @ 2007-07-20 22:37 UTC (permalink / raw
To: rms; +Cc: alserkli, emacs-devel
() 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-20 22:37 ` Thien-Thi Nguyen
@ 2007-07-20 23:30 ` Thien-Thi Nguyen
2007-07-23 8:36 ` Alexander Klimov
1 sibling, 0 replies; 9+ messages in thread
From: Thien-Thi Nguyen @ 2007-07-20 23:30 UTC (permalink / raw
To: alserkli; +Cc: emacs-devel
() 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-20 22:37 ` Thien-Thi Nguyen
2007-07-20 23:30 ` Thien-Thi Nguyen
@ 2007-07-23 8:36 ` Alexander Klimov
2007-07-23 13:54 ` Alexander Klimov
1 sibling, 1 reply; 9+ messages in thread
From: Alexander Klimov @ 2007-07-23 8:36 UTC (permalink / raw
To: Thien-Thi Nguyen; +Cc: rms, emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-23 8:36 ` Alexander Klimov
@ 2007-07-23 13:54 ` Alexander Klimov
2008-03-11 13:48 ` Alexander Klimov
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Klimov @ 2007-07-23 13:54 UTC (permalink / raw
To: emacs-devel; +Cc: Thien-Thi Nguyen
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2007-07-23 13:54 ` Alexander Klimov
@ 2008-03-11 13:48 ` Alexander Klimov
2008-07-01 3:16 ` Glenn Morris
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Klimov @ 2008-03-11 13:48 UTC (permalink / raw
To: emacs-devel; +Cc: Glenn Morris
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: preprocessing Makefile
2008-03-11 13:48 ` Alexander Klimov
@ 2008-07-01 3:16 ` Glenn Morris
0 siblings, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2008-07-01 3:16 UTC (permalink / raw
To: Alexander Klimov; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-07-01 3:16 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-19 9:41 preprocessing Makefile Alexander Klimov
2007-07-19 10:02 ` Thien-Thi Nguyen
2007-07-19 21:21 ` Richard Stallman
2007-07-20 22:37 ` Thien-Thi Nguyen
2007-07-20 23:30 ` Thien-Thi Nguyen
2007-07-23 8:36 ` Alexander Klimov
2007-07-23 13:54 ` Alexander Klimov
2008-03-11 13:48 ` Alexander Klimov
2008-07-01 3:16 ` Glenn Morris
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.