autoconf: generated configure scripts should not try to use nawk

[ryandesign (Ryan Carsten Schmidt)]

autoconf generates configure scripts that, among other things, try to determine which awk implementation to use. It tries, in order, gawk, mawk, nawk and awk, and uses the first one that's found.

gawk works well. I've never tried mawk but also never heard of any problems with it. But users who install nawk but do not have gawk installed have experienced numerous build failures of various ports. There are many prior tickets. In the past, I've fixed this by using the conflicts_build portgroup to add a build conflict with nawk. This is inconvenient for the user who actually wants to use nawk for their own work, because it requires them to deactivate nawk prior to building the port they requested and to reactivate it later. Lately, Josh has been fixing the problem a different way: by patching configure scripts to no longer try to use nawk. I've changed several ports today to use that method, but ran into a problem fixing graphviz, because graphviz uses autoreconf to regenerate its configure script, so even though I've patched it to not use nawk, it gets regenerated at configure time and then again will use nawk.

Although not all ports fail to build when nawk is installed (for example, autoconf itself doesn't), enough do that I would like a more central solution for this issue. As a first step, I propose that the autoconf port be modified so that the configure scripts it generates no longer attempt to use nawk. I'm not aware of any benefit of trying to use nawk, and as I said I'm aware of many drawbacks. There are probably countless ports that fail to build with nawk that have not been reported; for example, I just fixed this problem in gdal today. By fixing the problem centrally in autoconf, we fix the problem for all ports using autoconf, and fixing other ports could become as easy as just having them run autoreconf (or, of course, manually writing a patchfile).

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

goes in files directory

[larryv (Lawrence Velázquez)]

possibly minimal patch

[larryv (Lawrence Velázquez)]

I think this is a good approach, but could you test whether my minimal patch​ works? I believe line 348 of programs.m4 affects the behavior of autoscan, so I’d prefer to leave it intact.

[ryandesign (Ryan Carsten Schmidt)]

You're right, your patch is sufficient. But the same changes need to be made in libtool: both to change its own configure script so that it can build, and also to change the configure script that it installs for other ports to use.

[ryandesign (Ryan Carsten Schmidt)]

Or maybe it's not a good idea that we change autoconf's behavior. After all, people might be using autoconf to generate distribution tarballs of their own software. They might not want our configure script customizations.

Maybe it's better for each affected port to force the use of a working awk using a configure argument, as I did for graphviz in r142776. We could even think about adding such a configure argument by default for all ports, though probably more than a handful (i.e. those not using autoconf) would complain about that.

[ryandesign (Ryan Carsten Schmidt)]

My above changes to libtool caused problems; see #49774.

[ryandesign (Ryan Carsten Schmidt)]

Let's not do this.

The reasons all the other ports were having problems with nawk was that nawk was broken. nawk has been fixed; see #51812.