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

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

[Assaf Gordon]

Hello,

While investigating some other issue, I noticed that non-gnu make
fails to create 'iconv_open-aix.h' from 'iconv_open-aix.gperf'.

Perhaps this is a non-issue, and only gnu-make is supported
for this bootstrapping stage (and non-gnu makes are only supported
after "make dist"). Still, worth reporting.

To reproduce:

    ./gnulib-tool --create-testdir --dir=foo iconv_open
    cd foo
    ./configure && make   ## gnu make - works OK

    ## gnu make - the "-aix.h" file is re-generated without problem
    rm gllib/iconv_open-aix.h
    make

    # now try again with BSD make
    $ rm gllib/iconv_open-aix.h
    $ bmake
    bmake  all-recursive
    Making all in gllib
    bmake[2]: don't know how to make iconv_open-aix.h. Stop

    bmake[2]: stopped in /home/gordon/projects/gnulib/foo/gllib
     *** Error code 1

The 'bmake' here is BSD-make from the stock Debian 'bmake' package,
but the same happens on FreeBSD.

-assaf

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

[Bruno Haible]

Hi Assaf,

> Perhaps this is a non-issue, and only gnu-make is supported
> for this bootstrapping stage (and non-gnu makes are only supported
> after "make dist"). Still, worth reporting.

Indeed, we need to distinguish the two uses: Building from a tarball,
and building from a git checkout.

For building from a tarball, the GNU Coding Standards [1] remind us
to minimize the assumptions. To me, this means that for building from
a tarball, any reasonable 'make' implementation should be supported
(of course without the VPATH feature, which Solaris 'make' does not
support correctly).

(While reading [1], I'm surprised to see that 'bison' is among the
tools that may be required for building. So, our habit to distribute
pre-built .c from .y files in tarballs is not mandated by the
GNU Coding Standards, but is merely a convenience, to avoid trouble
when the users don't have bison installed or have an older version
of bison installed that does not match the minimum requirements of
the particular .y file.)

Anyway, 'gperf' is not among these tools. Therefore the iconv_open
module includes the .h files in EXTRA_DIST, so that they appear in
the tarballs. Now, for building from a git checkout, typically more
tools are needed, usually listed in the file 'HACKING'. To me,
the priorities are as follows:
  1. GNU make must be supported.
  2. The preinstalled 'make' of various operating systems should
     be supported, if possible.
  3. Other 'make' implementations should be supported, if possible.

> The 'bmake' here is BSD-make from the stock Debian 'bmake' package,
> but the same happens on FreeBSD.

'bmake' is in category 3. Whereas the Makefile rule that rebuilds
iconv_open-aix.h has been written in such a way that it works with
OpenBSD 'make', which is in category 2.

I won't remove support for a 'make' in category 2, to satisfy one
in category 3.

In other words, 'bmake' is just too dumb to be supported as a build
tool in HACKING.

Bruno

[1] https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html

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

[Assaf Gordon]

Hello Bruno,

On 2019-08-24 2:19 a.m., Bruno Haible wrote:
>> Perhaps this is a non-issue, and only gnu-make is supported
>> for this bootstrapping stage (and non-gnu makes are only supported
>> after "make dist"). Still, worth reporting.
> 
> Indeed, we need to distinguish the two uses: Building from a tarball,
> and building from a git checkout.
> 

[...]

> Now, for building from a git checkout, typically more
> tools are needed, usually listed in the file 'HACKING'. To me,
> the priorities are as follows:
>    1. GNU make must be supported.
>    2. The preinstalled 'make' of various operating systems should
>       be supported, if possible.
>    3. Other 'make' implementations should be supported, if possible.
> 
>> The 'bmake' here is BSD-make from the stock Debian 'bmake' package,
>> but the same happens on FreeBSD.
> 
> 'bmake' is in category 3. Whereas the Makefile rule that rebuilds
> iconv_open-aix.h has been written in such a way that it works with
> OpenBSD 'make', which is in category 2.
> 
> I won't remove support for a 'make' in category 2, to satisfy one
> in category 3.
> 
> In other words, 'bmake' is just too dumb to be supported as a build
> tool in HACKING.
> 

Thanks for the details.

For completeness, this version of "make" is the native version
(=preinstalled by the operating system) in FreeBSD and NetBSD -
so projects using gnulib's "iconv_open" module can't be built
there from git without installing gnu-make.

However, as you wrote, this is a minor issue at best.
If someone wants to develop or hack on such project on these systems,
they'll anyhow need automake+autoconf+gettext+gperf+pkg-config,
they might as well install gnu-make too :)

-assaf

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

[Bruno Haible]

Assaf Gordon wrote:
> this version of "make" is the native version
> (=preinstalled by the operating system) in FreeBSD and NetBSD

So, by improving the support for OpenBSD I regressed on the same
feature in FreeBSD? Ouch.

Bruno

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

[Assaf Gordon]

On 2019-08-24 3:08 p.m., Bruno Haible wrote:
> Assaf Gordon wrote:
>> this version of "make" is the native version
>> (=preinstalled by the operating system) in FreeBSD and NetBSD
> 
> So, by improving the support for OpenBSD I regressed on the same
> feature in FreeBSD? Ouch.
> 

Somewhat related,

I'm also struggling with another "bmake" issue relating to automake,
here: https://lists.gnu.org/r/automake/2019-08/msg00000.html

Seems like some recent change in automake broke compilation (of released 
tarballs) with "bmake", while gnu-make still works.

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.

-assaf

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

[Bruno Haible]

Hi Assaf,

> I'm also struggling with another "bmake" issue relating to automake,
> here: https://lists.gnu.org/r/automake/2019-08/msg00000.html
> 
> Seems like some recent change in automake broke compilation (of released 
> tarballs) with "bmake", while gnu-make still works.
> 
> 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.

Bruno

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