Re: [Bug-zile] Missing dependency for zile.1.in Makefile target

[Ulrich Mueller]

>>>>> On Tue, 7 Sep 2010, Reuben Thomas wrote:

> Unfortunately, I've just worked out why zile.1.in did not depend on
> zile$(EXEEXT). You are correct that it should, normally, but I have
> made zile.1.in an EXTRA_DIST file so that help2man is not needed to
> build Zile from a release tarball. If zile.1.in is made to depend on
> zile$(EXEEXT), then it is always remade, since zile$(EXEEXT) is
> always built. But when running make distcheck, zile.1.in is built
> under the _build directory. However, it is not removed by make
> distclean, since it is an EXTRA_DIST file, so make distcheck fails,
> because _build is not left empty by make distclean, as it should be.
> This is a catch-22: I cannot, in general, remove zile.1.in, in case
> I am doing a normal build!

I see the problem. One could solve it with "order-only" prerequisites,
like this:

zile.1.in: main.c man-extras zile-help2man-wrapper | zile$(exeEXT)

This might be a GNUism, though.

> So the two solutions seem to be:

> 1. Require all users to install help2man. This would be a pity.

> 2. Require you to use touch to reset the timestamp on main.c, so
> that zile.1.in is not rebuilt.

... or update the timestamp on zile.1.in.

> I would prefer 2, as it affects far fewer users.

I agree that you cannot go for 1. But 2 is a hack and not really a
solution. (I can live with it though.)

> This also leads to another question: what patch to main.c do you
> need in the first place? I'm always keen to try to make Zile more
> portable, and I believe that Debian, at least, does not need to
> patch the source at all, so if I can help Gentoo avoid a patch, I'd
> be happy to.

So far we also don't patch the source. The only tweak that we do is
that we remove /usr/lib/charset.alias from the installed image
unconditionally, since it caused problems on some non-glibc systems.


The reason why I patched main.c (so far, for testing purposes only) is
related to Gentoo bug 335898 <http://bugs.gentoo.org/335898>.

In a nutshell: Configure scripts of some programs are testing for the
location of Emacs's lisp dir, typically using an expression like this:

   $EMACS -batch -q -eval '(while load-path (princ (concat
   (car load-path) "\n")) (setq load-path (cdr load-path)))'

(So far, we have identified bash, gettext, gpm, and qingy, but
probably this list will become longer.)

Now if on a user's system /usr/bin/emacs is symlinked to zile, above
test will hang: Zile will happily ignore all command line options and
interpret the last argument as a file name.

Therefore, I had experimented with making Zile error out if an unknown
command line option is encountered, instead of displaying an error
message in the minibuffer.

Ulrich