* iconv_open: non-gnu make fails to generate "iconv_open-aix.h" @ 2019-08-24 6:15 Assaf Gordon 2019-08-24 8:19 ` Bruno Haible 0 siblings, 1 reply; 7+ messages in thread From: Assaf Gordon @ 2019-08-24 6:15 UTC (permalink / raw) To: bug-gnulib@gnu.org List 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" 2019-08-24 6:15 iconv_open: non-gnu make fails to generate "iconv_open-aix.h" Assaf Gordon @ 2019-08-24 8:19 ` Bruno Haible 2019-08-24 20:12 ` Assaf Gordon 0 siblings, 1 reply; 7+ messages in thread From: Bruno Haible @ 2019-08-24 8:19 UTC (permalink / raw) To: bug-gnulib; +Cc: Assaf Gordon 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" 2019-08-24 8:19 ` Bruno Haible @ 2019-08-24 20:12 ` Assaf Gordon 2019-08-24 21:08 ` Bruno Haible 0 siblings, 1 reply; 7+ messages in thread From: Assaf Gordon @ 2019-08-24 20:12 UTC (permalink / raw) To: Bruno Haible, bug-gnulib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" 2019-08-24 20:12 ` Assaf Gordon @ 2019-08-24 21:08 ` Bruno Haible 2019-08-24 21:14 ` Assaf Gordon 0 siblings, 1 reply; 7+ messages in thread From: Bruno Haible @ 2019-08-24 21:08 UTC (permalink / raw) To: Assaf Gordon; +Cc: bug-gnulib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" 2019-08-24 21:08 ` Bruno Haible @ 2019-08-24 21:14 ` Assaf Gordon 2019-08-24 21:36 ` Bruno Haible 0 siblings, 1 reply; 7+ messages in thread From: Assaf Gordon @ 2019-08-24 21:14 UTC (permalink / raw) To: Bruno Haible; +Cc: bug-gnulib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" 2019-08-24 21:14 ` Assaf Gordon @ 2019-08-24 21:36 ` Bruno Haible 2019-08-24 21:58 ` Assaf Gordon 0 siblings, 1 reply; 7+ messages in thread From: Bruno Haible @ 2019-08-24 21:36 UTC (permalink / raw) To: Assaf Gordon; +Cc: bug-gnulib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h" 2019-08-24 21:36 ` Bruno Haible @ 2019-08-24 21:58 ` Assaf Gordon 0 siblings, 0 replies; 7+ messages in thread From: Assaf Gordon @ 2019-08-24 21:58 UTC (permalink / raw) To: Bruno Haible; +Cc: bug-gnulib 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). ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-08-24 21:59 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-24 6:15 iconv_open: non-gnu make fails to generate "iconv_open-aix.h" Assaf Gordon 2019-08-24 8:19 ` Bruno Haible 2019-08-24 20:12 ` Assaf Gordon 2019-08-24 21:08 ` Bruno Haible 2019-08-24 21:14 ` Assaf Gordon 2019-08-24 21:36 ` Bruno Haible 2019-08-24 21:58 ` Assaf Gordon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).