Hi Jack, thanks for the feedback. On 07/05/2012 11:33 PM, Jack Kelly wrote: > On Fri, Jul 6, 2012 at 3:56 AM, Stefano Lattarini > <[email protected]> wrote: >> On 07/01/2012 01:03 AM, Jack Kelly wrote: >> Thanks. I've condensed a patch from you explanation (see attachment). >> I will push it shortly if there are no objections. > > Though I doubt it makes any practical difference, the only thing I > would suggest is to cons the load-path so the current directory is > before $abs_srcdir: echo "(setq load-path (cons nil (cons > \"$abs_srcdir\" load-path)))" > script > > That way, the build directory (where all the .el files being compiled > actually are), then the src directory, then everywhere else will be > searched. > Usually I'd agree, and in fact I had done as you're suggesting in a previous attempt; but that caused the test 'lisp3.sh' to fail :-/ With the patch I've posted, the testsuite remains clean at least.
So I say we commit my patch: albeit suboptimal, and somewhat reeking of cargo-cult programming, it solves the OP issue. If someone then wants to venture in refactoring, fixing and cleaning up the elisp support in Automake -- be him my guest! As for more, I'm not knowledgeable nor motivated enough to venture in something like that at the moment. Sorry. > Another thing I noticed from `man emacs': There's a --eval command > like argument, so generating that subscript is technically > unnecessary. Try something like: > > $EMACS -batch -q --eval "(setq load-path (cons nil (cons > \"$abs_srcdir\" load-path)))" -f batch-byte-compile *.el || exit $? > > Since elisp-comp doesn't handle stamps but only a temporary directory, > I think you might even be able to call it directly from make using > something like: > > $(EMACS) -batch -q --eval "(setq load-path (cons \"$(srcdir)\" > load-path))" -f batch-byte-compile $(LISP) || exit 1 > I'm not sure how this would interact with $(LISP) containing '.el' files in a subdirectory ... But then, I guess all the current implementation of byte-compilation for elisp sources is probably brittle and buggy in such a setup anyway, I guess, so my misgivings might be unjustified: <http://lists.gnu.org/archive/html/automake/2009-10/msg00013.html> Anyway, I'd rather not touch the existing code, for fear of introducing regressions. But patches would be mostly welcome (if coming with proper testsuite enhancement). Thanks, Stefano
