Stefano Lattarini <[email protected]> writes: > 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).
Oh that's a bit non-standard I'm afraid, normally lispers wouldn't use automake to compiler their files. And my solution is a bunch of shell scripts and lisp snippets that prepares files for compilation into .fasl (byte-compiled lisp) and on the LINK step uses a non-portable: (sb-ext:save-lisp-and-die "thhcc.bin" :executable t :toplevel #'main) which will then be objcopy'd to replace trampoline code by the lisp system with my own. It's too fragile to be useful in general, sorry :( >> Stefano Lattarini <[email protected]> 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. Well, I think a mention in the manual that OBJEXT must match the language chosen via AC_LANG (in the autoconf/automake tandem case) would be useful enough to avoid such pitfalls. In the long run I think automake needs upstream-support from the lisp systems to support compilation and linking steps on the command line. I think you can close this bug, it was merely something to point the possible pitfalls out when using a non-standard language compiler. Sebastian
