bug#11806: (setq load-path ..) of elisp-comp

[Jack Kelly]

On Thu, Jun 28, 2012 at 8:49 PM, Stefano Lattarini
<address@hidden> wrote:
> On 06/28/2012 06:47 AM, Makoto Fujiwara wrote:
>> I do have problem compiling *.el files with tc-2.3.1 (svn version)

I think this is the relevant Makefile.am:
http://code.google.com/p/tcode/source/browse/trunk/tc/lisp/Makefile.am

It confuses me thoroughly.

> Could you expose such problems in a minimal test case?  This way, I
> could add it to the automake testsuite, to ensure the issue doesn't
> represent itself in the future.  Thanks.
>
>> Following patch fixes this type of problem, thanks a lot.
>>
>> By the way, the same patch was once proposed as
>>   http://osdir.com/ml/sysutils.automake.patches/2003-01/msg00004.html
>> and fix seems to have made, but real line was dropped with
>> unknown reason.
>>
>> --- lib/elisp-comp.orig       2012-06-01 22:47:10.000000000 +0900
>> +++ lib/elisp-comp    2012-06-28 13:28:44.000000000 +0900
>> @@ -75,7 +75,7 @@
>>
>>  (
>>    cd $tempdir
>> -  echo "(setq load-path (cons nil load-path))" > script
>> +  echo "(setq load-path (cons \"../\" (cons nil load-path)))" > script
>>    $EMACS -batch -q -l script -f batch-byte-compile *.el || exit $?
>>    mv *.elc ..
>>  ) || exit $?
>>
>>
> The patch seems small and harmless, but unfortunately I know nothing at
> all about Lisp or Emacs, so I can't judge whether such a change could
> have unintended consequences.  Perchance someone more knowledgeable than
> me in this area is reading the thread, and can chime in?  Otherwise I
> will go ahead and push the patch in 72 hours.

I'm no elisp master, but here's what I see is happening:

* Developer defines something like lisp_LISP = foo.el bar.el baz.el
* baz.el (say) depends on quux.el, in the same directory but not
listed in the primary.
* At `make' time, everything in lisp_LISP is copied to a subdirectory
and batch-byte-compile is called on all those files.
* Because quux.el wasn't copied over, the compile fails.
* Adding the parent directory to load-path might fix that, but I
wonder if it will still break on VPATH builds? Maybe the correct
answer is to add ../$(srcdir) or $(abs_srcdir) insted.
* Why (in the .el files) is the developer depending on a file that's
not being compiled? will this cause automake to silently do the wrong
thing if a new .el file has been listed and Makefile.am doesn't get
updated? Now you can go ahead and install an incomplete package.
* Should the current directory come before the source directory?

There's another (potential) problem. The script that elisp-comp
creates is called "script". Does it make sense to allow files without
a .el extension to appear in a _LISP primary? Currently, automake lets
you get away with it, but it will only compile *.el anyway (even
though it copies $@ into the temporary dir). I don't know enough about
elisp to say, but if that's fixed, then "script" should be given a
better filename (using mktemp or something) so it doesn't clobber a
user's script.

-- Jack