bug#10128: am_foo_OBJECTS is empty when ...

[Sebastian Freundt]

Stefano Lattarini <address@hidden> 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 <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.

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