GNU bug report logs - #10128
am_foo_OBJECTS is empty when ...

Previous Next

Package: automake;

Reported by: Sebastian Freundt <freundt <at> fresse.org>

Date: Thu, 24 Nov 2011 18:38:02 UTC

Severity: minor

Full log


View this message in rfc822 format

From: Sebastian Freundt <freundt <at> fresse.org>
To: 10128 <at> debbugs.gnu.org
Subject: bug#10128: am_foo_OBJECTS is empty when ...
Date: Mon, 02 Jan 2012 18:24:25 +0000
Stefano Lattarini <stefano.lattarini <at> gmail.com> 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




This bug report was last modified 13 years and 163 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.