#127 libevent build fails if 'env' tool in uncommon location

[Anonymous]

Compiling libevent fails if the 'env' executable is not located at /usr/bin.

The Makefile in libevent/test calls the Python script ../event-rpcgen.py directly, assuming it has executable rights and also relying on the script's shebang to locate Python.

If 'env' is not availabe at /usr/bin, the script will fail and the build process is interrupted.

I propose that the script is not called directly, but handed to the python executable as an argument.

[Nick Mathewson]

Seems like a fine idea to me; want to write the patch ?

[Anonymous]

Version A of a proposed patch

[Anonymous]

Version B of the patch

[Anonymous]

Here's two versions of basically the same patch.

I much prefer version A, because it uses existing autotools magic to detect Python and will stop at the configure step if Python is not available.
Unfortunately, this creates a new dependency for python.m4, which might be available on some systems, but not others (it is not available by default on my NAS device for example).

Version B is much more straightforward, but it hardcodes the binary name 'python' into the build process, which may not be much better than the current implementation.

[Nick Mathewson]

I like the approach of version A better too, but aborting at configure time if we can't find Python is too much. There are plenty of Windows people who don't care about Libevent's RPC stuff at all, and it would be gratuitous to force them to install it.

Instead, it would be better to contain the failure of a missing Python by just not building the RPC regression tests.

Instead, you could use something like
AM_PATH_PYTHON([2.whatever],,[:])
AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :])

and then later adjust test/Makefile.am accordingly to only invoke Python when there's an actual Python binary available.

Also, which Automake version introduced AM_PATH_PYTHON ?