[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h"
From: |
Bruno Haible |
Subject: |
Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" |
Date: |
Sat, 24 Aug 2019 10:19:27 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-157-generic; KDE/5.18.0; x86_64; ; ) |
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