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
affe
On Wed, 10 Dec 2014 14:30:41 +1000 Vince Boros wrote:
> On Mon, 8 Dec 2014 17:51:03 +0100 (CET) Jan Engelhardt
> 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 lib/bar.c lib/bar.h lib/n
On Mon, 8 Dec 2014 17:51:03 +0100 (CET) Jan Engelhardt
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 lib
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
Makefi
5 matches
Mail list logo
