* Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST: > If depending on GNU make was considered ok, then Automake would have > been developed quite differently than it is. Given current Automake > objectives, it is wise that individual projects also try to avoid > GNU make syntax in Makefile.am.
While I don't dispute that, I do think that requiring GNU make is a fairly low barrier in way of prerequisites. GNU make is small, highly portable and easily installed. If Automake were only started now, I think requiring GNU make would be a prudent design decision. The current Automake code contains large chunks of logic that exists purely to work around missing features or issues in non-GNU make implementations. Let's be honest, requiring GNU make outright would make several optimizations possible, leading to smaller makefiles and lower build system overhead. We've been at the point before where some new feature was easily implemented in GNU make syntax but rather tough in portable make. Some features may not be possible at all with the latter. Still, as things stand, I'm not sure whether changing design goals of Automake now are such a good idea. BSD developers really like using their own make. The code we have works, build system overhead is really bad only on w32. We have opportunities for improvement by assuming Posix and XSI shell in more places, guarded by suitable tests. As long as the build system parallelizes well, I don't think there is too much cause for concern. For your own Makefile.am code, you can turn off warnings about nonportable constructs by adding -Wno-portability to the automake options. Cheers, Ralf
