As a follow-up to my earlier "fixed-upstream" tag based on the
upstream maintainer's belief, I tested my package with automake 1.16.1
(the latest upstream version). It did fix this bug that automake 1.15
manifested in my case.
I was able to get around the bug in automake 1.15, so it does not
On Wed, 10 Dec 2014 14:30:41 +1000 Vince Boros v.bo...@uq.edu.au wrote:
On Mon, 8 Dec 2014 17:51:03 +0100 (CET) Jan Engelhardt jeng...@inai.de
wrote:
The sensible way is to statically resolve $(top_srcdir) with the real
(relative) path of the source file, that is,
foo_SOURCES = foo.c
On Mon, 8 Dec 2014 17:51:03 +0100 (CET) Jan Engelhardt jeng...@inai.de
wrote:
On Sat, 28 Jun 2014 18:38:16 +1000, Craig Small wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993 :
$ cat Makefile.am
AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS = foo
foo_SOURCES = foo.c
On Sat, 28 Jun 2014 18:38:16 +1000, Craig Small wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993 :
$ cat Makefile.am
AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS = foo
foo_SOURCES = foo.c lib/bar.c lib/bar.h $(top_srcdir)/lib/nothere.c
The way I interpret the automake
Package: automake
Version: 1:1.14.1-3
Severity: normal
This one had me going for a while. I think it is an automake problem,
rather than an autoconf problem because the mystery directory appears
at the ./configure step.
It started because automake complains about subdir-objects:
$ automake
5 matches
Mail list logo
