bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10128: am_foo_OBJECTS is empty when ...


From: Sebastian Freundt
Subject: bug#10128: am_foo_OBJECTS is empty when ...
Date: Mon, 02 Jan 2012 18:24:25 +0000
User-agent: Gnus/5.110014 (No Gnus v0.14) SXEmacs/22.1.14 (linux)

Stefano Lattarini <address@hidden> writes:

> Hi Sebastian, sorry for the terrible delay.
>
> On 11/24/2011 01:02 PM, Sebastian Freundt wrote:
>> The (internal) variable am_foo_OBJECTS is empty when OBJEXT has been
>> redefined *and* no .SOURCE_EXT.o rule is present.
>> 
>> Example:
>> 
>> --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.fasl:
>>         touch $@
>> 
>> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>>
> This does really seem like an abuse of already corner-case Automake features 
> ...
> What are you trying to obtain actually?  Perhaps it can be done with less 
> poking
> of Automake's dark corners ...

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.

The compiler itself isn't confused about the contents of the file (in fact
I've made it read .o files which are in fact .fasl tentatively) but my own
script is, calling file(1) on each file beforehand to determine the
contents seems tedious to me :(

>> Now the generated Makefile lists:
>> 
>> am_foo_OBJECTS =
>> foo_OBJECTS = $(am_foo_OBJECTS)
>> 
>> However, adding a .lisp.o (the old OBJEXT) magically makes it all work:
>> 
> 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.

Not true, bar.fasl will will be built by the .lisp.fasl rule as defined,
at least here with GNU make 3.82.


> 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.

Thanks for delving into this
Sebastian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]