Re: Creating plain Makefiles with automake

[Russ Allbery]

Roger Leigh <address@hidden> writes:
> On Wed, Apr 24, 2013 at 08:36:06AM +0100, Diego Elio Pettenò wrote:

>> As a distribution developer this seems to me just yet another hack that
>> is going to cause us great pain in the future if it is found in the
>> wild..

> I'm not sure I see why.  It has the virtue of removing a step of
> indirection in the intermediary Makefile.in, and so serves to simplify
> things.  Including the substituted variable definitions via a separate
> file would also serve to make things more robust:  there's only a single
> source for them, rather than duplicate definitions across every
> Makefile.in.  And it's now possible to have rules depend upon the
> Makefile.am, Makefile and/or the configuration data which can then be
> used to trigger Makefile regeneration and rebuilds in a more informed
> manner, avoiding some of the rebuilds that now occur since you've
> decoupled the make logic and configuration logic.

If *everyone* switched, that would be one thing.  But my concern would be
around losing consistency.  The current Autotools process, whatever its
shortcomings, is extremely well-understood, and knowledge of how it works
is built into a large number of supporting tools (dh and dh-autoreconf on
the Debian side, for example).  There's an advantage to sticking with a
suboptimal process if it's the process that everyone else is using.  It
all depends on how significant the gains are.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>