WOW!
Bruno, that was exactly the issue!
I should've asked you directly before spending hours debugging and
bisecting :)
On 2019-08-24 3:36 p.m., Bruno Haible wrote:
The fact that the error message in both case is "don't know how to make
XXXX" perhaps hints there's some common dependency detection that works
in gnu-make and not in bmake - might be helpful to consider that.
I think the problem is that 'bmake' does not consider the targets
'foo' and './foo' as being the same.
In the case of the iconv_open module the error message was
don't know how to make iconv_open-aix.h
and the Makefile has a rule for constructing ./iconv_open-aix.h
but no rule for constructing iconv_open-aix.h.
In your report with the error message
don't know how to make ./lib/libhello.a
it's probably the other way around.
And indeed,
GNU hello and GNU datamash (which exhibit the problem)
have something like this in their Makefile.am:
hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
While sed and coreutils (which don't have the problem) have:
sed_sed_LDADD = sed/libver.a lib/libsed.a
LDADD = src/libver.a lib/libcoreutils.a
So because of the "$(top_builddir)" the targets gets a "./"
prefix, and combined with that recent automake change,
they ended up being considered separated targets by "bmake".
Wow, again - that was a great insight, Bruno.
I'm not sure what is the "correct" solution (fix automake?),
but changing the Makefile.am in GNU hello and datamash will
be much quicker than waiting for a new automake version
to propagate all around...
Thanks again!
(I'll also post this to the automake mailling list, don't want
to cross-post).
