On 01/02/2012 07:24 PM, Sebastian Freundt wrote: > > Well, I'm trying to build objects that will be linked later on, only that > the linker is a lisp compiler, and that compiler can read .lisp, .fasl, .o > and .so. As in raw lisp source code, byte-compiled lisp, elf objects and > elf dynamic objects. > This seems a legitimate use case. May I ask you to post a working version of your code? This would be useful both for future references, and to (try to) distil it into a test case (that is, if the Lisp compiler you are using is widespread enough to make such a test case useful). > Stefano Lattarini writes: > >> Well, actually it doesn't, because ... >> >>> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- >>> >>> AM_DEFAULT_SOURCE_EXT = .lisp >>> OBJEXT = fasl >>> >>> noinst_PROGRAMS = foo >>> foo_SOURCES = bar.lisp >>> >>> .lisp.o: ## just be >>> >>> .lisp.fasl: >>> touch $@ >>> >>> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- >>> >>> am_foo_OBJECTS = bar.$(OBJEXT) >>> foo_OBJECTS = $(am_foo_OBJECTS) >>> >> ... if you try to run the generated Makefile you will obtain some error >> like: >> >> make: *** No rule to make target `bar.fasl', needed by `foo'. >> make: Target `all' not remade because of errors. > D'oh, what a dope! In my testing, I had forgotten to create a proper bar.lisp file; so *obviously* make complained :-( > Not true, bar.fasl will will be built by the .lisp.fasl rule as defined, > at least here with GNU make 3.82. > You are perfectly right; in fact, this works with other make implementations as well (e.g, FreeBSD make, NetBSD make, Solaris make). I've now prepared a test case to correctly expose the bug; see attachement. >> In fact, I'm not sure the Automake APIs are designed to allow a redefinition >> of `OBJEXT' at all; but I can't find anything explicit about this in the manual. >> I'll need to investigate on this. > > Ok, well I understand that it's a bit corner-stone but it could be a very > useful case study if anyone intended to make automake more generic, or > less C/C++ specific. > I agree. If nothing else, it could bring at least to some more examples or explanations in the manual. Thanks, Stefano