bug#10128: am_foo_OBJECTS is empty when ...

[Stefano Lattarini]

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