[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10128: am_foo_OBJECTS is empty when ...
From: |
Stefano Lattarini |
Subject: |
bug#10128: am_foo_OBJECTS is empty when ... |
Date: |
Mon, 02 Jan 2012 21:13:39 +0100 |
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 <address@hidden> 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
objext-pr10128.test
Description: Text document