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

Previous Next

To reply to this bug, email your comments to 10128 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Freundt <freundt <at> fresse.org>
To: bug-automake <at> gnu.org
Subject: am_foo_OBJECTS is empty when ...
Date: Thu, 24 Nov 2011 12:02:05 +0000

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

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:

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

Affected automake versions: all, 1.11.1 in particular.

Cheers,
Sebastian

Message #8 received at 10128 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Sebastian Freundt <freundt <at> fresse.org>
Cc: 10128 <at> debbugs.gnu.org
Subject: Re: bug#10128: am_foo_OBJECTS is empty when ...
Date: Mon, 02 Jan 2012 19:03:25 +0100

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

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

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.

Thanks,
  Stefano

Message #11 received at 10128 <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Freundt <freundt <at> fresse.org>
To: 10128 <at> debbugs.gnu.org
Subject: Re: 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

Message #14 received at 10128 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Sebastian Freundt <freundt <at> fresse.org>
Cc: 10128 <at> debbugs.gnu.org
Subject: Re: bug#10128: am_foo_OBJECTS is empty when ...
Date: Mon, 02 Jan 2012 21:13:39 +0100

[Message part 1 (text/plain, inline)]

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 <stefano.lattarini <at> gmail.com> 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 (text/plain, attachment)]

Message #17 received at 10128 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Sebastian Freundt <freundt <at> fresse.org>
Cc: 10128 <at> debbugs.gnu.org
Subject: Re: bug#10128: am_foo_OBJECTS is empty when ...
Date: Tue, 03 Jan 2012 18:47:29 +0100

[Message part 1 (text/plain, inline)]

> 
> I've now prepared a test case to correctly expose the bug.
>
And now I've pushed it with the attached patch (it is obviously still
declared as an XFAIL).

Regards,
  Stefano

[0001-coverage-expose-automake-bug-10128.patch (text/x-diff, attachment)]

Message #20 received at 10128 <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Freundt <freundt <at> fresse.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10128 <at> debbugs.gnu.org
Subject: Re: bug#10128: am_foo_OBJECTS is empty when ...
Date: Tue, 03 Jan 2012 18:25:42 +0000

Stefano Lattarini <stefano.lattarini <at> gmail.com> 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 <stefano.lattarini <at> gmail.com> 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

Previous Next

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