Re: Portable type definitions for tools

[Alan Barrett <apb%cequrux.com@localhost>]

On Thu, 11 Sep 2008, Luke Mewburn wrote:
>  * Joerg's proposal requires a newer version of autoconf (2.60+)
>    than we have in gnu/dist/autoconf as a MKMAINTAINERTOOLS item.
>    (for AC_TYPE_INT8_T, etc)

Using a non-tools version of autoconf seems like a bad idea in general,
and updating the tools version of autoconf during the pre-netbsd-5
freeze seems like a bad idea now.

>  * New autoconf has improved tests for other issues that may
>    help improve the portability of src/tools.

In that case, we should consider updating to it after netbsd-5 is
branched.  We could even pull the change up to the netbsd-5 branch
later.

>  * autoconf 2.60+ needs GNU m4 1.4.5 and prefers 1.4.11.
>    We don't have GNU m4 in-tree.

This is very obnoxious.  autoconf basically refuses to run if
it thinks you don't have GNU m4, and they don't document exactly
what GNU extensions they rely on, so it's difficult to check
whether another m4 is actually good enough.

>  * autoconf 2.62+ and m4 1.4.10+ is licensed under GPLv3.

However, OpenBSD m4 is supposed to be
good enough, according to Marc Espie in
<http://mail-index.netbsd.org/tech-pkg/2008/08/21/msg001529.html>

> In light of this, we need to decide whether the costs of
> importing a newer autoconf & GNU m4 into the tree
> (under src/external/gpl3/ ) this close the the 5.0 branch
> are outweighed by the benefits of building tools/compat/configure
> with a more modern autoconf.

I'd like to know about platforms that used to be able to build tools,
but that now cannot build tools.  What problems do such platforms have?

My recommendation is to make the minimal changes required for
portability of the tools build system.  I suspect that this will involve
adding autoconf tests for a few extra functions, but no infrastructure
changes.

--apb (Alan Barrett)