Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h"

[Assaf Gordon]

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