[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .dvi.ps unconditionally applies dvips
From: |
Ralf Corsepius |
Subject: |
Re: .dvi.ps unconditionally applies dvips |
Date: |
Mon, 02 Aug 2004 08:01:49 +0200 |
On Sun, 2004-08-01 at 22:23, Alexandre Duret-Lutz wrote:
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
>
> Ralf> Hi,
> Ralf> I am facing lots of troubles with *_TEXINFOS in automake-1.9:
>
> Ralf> Here is first one: The .dvi.ps rules being generated by automake-1.9
> Ralf> unconditionally applies DVIPS.
>
> Hum, sorry, but that's indeed what I'd expect. What's your
> issue exactly?
"Automake produces non-functional, non-portable and unsafe Makefiles".
Example:
# cat Makefile.am
info_TEXINFOS = demo.texi
>From the corresponding Makefile.in:
...
DVIPS = dvips
...
.dvi.ps:
$(DVIPS) -o $@ $<
...
# ./configure
# make demo.ps
...
MAKEINFO='/bin/sh /users/rtems/src/autobugs/info3/missing --run
makeinfo -I .' \
texi2dvi demo.texi
...
dvips -o demo.ps demo.dvi
make: dvips: Command not found
make: *** [demo.ps] Error 127
Note: Makeinfo even is guarded by "missing", dvips is not.
> What else did you expect?
Automake is aiming at portable makefiles, right?
IMO, for Makefiles to be portable, automake must not rely on tools that
may not be present everywhere and must automatically check for presence
of those tools or at least complain if the configure script doesn't set
them up.
In case of DVIPS, automake hard-coes "DVIPS = dvips" into Makefiles and
blindly applies it. IMO, this contradicts to automake's
working-principles.
> Do you mean the
> problem appeared with 1.9?
I don't know. I just tripped over it when trying automake-1.9 and
investigating why automake-1.9 apparently screws up on *texi/*info
files.
> AFAICT the .dvi.ps rule has been
> unchanged since its introduction in 1996.
I would not want exclude this. May-be it's just a reflection of the
importance of texi/info in real life :-)
Ralf