On 2021-01-25, John Calcote <john.calc...@gmail.com> wrote: > On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler <nbow...@draconx.ca> wrote: >> On 2021-01-25, Zack Weinberg <za...@panix.com> wrote: >> > I'm not at all familiar with Automake's internals, but the reason I >> > suggested taking advantage of GNU make extensions was the potential >> > for _complexity_ reduction of the generated Makefile, not performance. >> > For instance, this generated rule from one of my other projects [...] >> >> To be honest if Automake-generated Makefile.in files only worked >> for users with, say, sufficiently modern versions of GNU Make, I'm >> not sure there would be any point in using Automake. > > I'm not sure I see your point Nick. Why use Automake? Because I'd much > rather write (and maintain) two lines of automake code than even a single > page of GNU make code.
I'm trying to say that if you are going to force users to use GNU make anyway then then I think most if not all of Automake's features would be more effectively implemented by one or more "include"-able GNU make snippets rather than using a standalone perl-based preprocessor stage like Automake that introduces its own unique set of problems. This approach is very typically used in the BSD world, where the build environment is centered around one specific make implementation and everyone shares the same set of common build recipes. But for me, I want my packages to be widely portable and out-of-the-box compatibility with default "make" implementations, to the greatest extent possible, on a wide variety of real-world platforms is important. I personally don't want to ask users of non-GNU systems to install GNU make just because the Makefile would be slightly easier to write. Today, I use Automake to help me achieve this goal. If a new version of Automake were to make that impossible, because its own rules will not run on other makes, then I suppose I would not be using that version. This doesn't mean everything needs to work _perfectly_ on every make, but I expect at least "./configure --whatever-options && make install" to work everywhere, and for incremental rebuilds to work contingent on functional dependency tracking (which in practice is almost everywhere). Cheers, Nick
