Roger Leigh <rle...@codelibre.net> 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 (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
