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 <stefano.lattar...@gmail.com> 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
#! /bin/sh # Copyright (C) 2012 Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. # Test for automake bug#10128: $(OBJEXT) redefinition causes # $(foo_OBJECTS) to be defined as empty. . ./defs || Exit 1 set -e echo AC_OUTPUT >> configure.in cat > Makefile.am <<'END' LINK = echo >$@ Linked $@ from OBJEXT = fasl EXEEXT = noinst_PROGRAMS = foo zardoz foo_SOURCES = foo.lisp zardoz_SOURCES = mu1.lisp mu2.lisp ## Un-commenting this is enough to make the test pass. Weird! ##.lisp.o: .lisp.fasl: touch $@ .PHONY: test test: test '$(foo_OBJECTS)' = 'foo.fasl' test '$(zardoz_OBJECTS)' = 'mu1.fasl mu2.fasl' END $ACLOCAL $AUTOMAKE $AUTOCONF ./configure $MAKE test touch foo.lisp mu1.lisp mu2.lisp $MAKE all cat foo cat zardoz test "`cat foo`" = "Linked foo from foo.fasl" test "`cat zardoz`" = "Linked zardoz from mu1.fasl mu2.fasl" :
