On Tue, 22 Nov 2011, Nick Bowler wrote:
We must weigh the costs against the benefits. It's currently not clear
to me what the benefits actually are, to anyone other than automake
maintainers.
Currently, the benefits to automake maintainers is clear, there may be
some benefit to package maintainers (hopefully by making automake easier
to use), and there seems to be no benefit to users at all.
The benefits of depending on GNU make have yet to be enumerated. It
would behoove the proponents this change to do so.
Some benefits (somewhat) noticeable by end users that I see are:
o Packaged Makefile.in (or GNUmakefile.in) can be smaller since GNU
make string functions and other enhanced functionality can be used to
eliminate/reduce Makefile code currently generated via Automake
perl code. Perhaps the GNUmakefile.in could be 1/3rd or even 1/4
the size Makefile.in is today.
o Full header dependencies do not need to be (as) optional.
o Some functionality delivered as scripts (e.g. 'compile') could be
subsumed by the Makefile so builds might be slightly faster.
o Libtool script functionality could be assimilated into the
Makefile so builds may be somewhat faster.
These are all marginal improvements from an end-user's perspective.
However, a good argument can be made that the GNU build tool should
accept Makefile.am files directly, eliminating packaged Makefile.in
files. This is yet another argument that Automake should not depend
on classic 'make' or even current GNU make. There is no reason to
deliver pre-processed template files to the user if GNU is free to
insist that the user install a GNU build tool in advance (which it
never has before). If GNU is going to insist that the user install
its own tool in advance, then it seems like that tool should provide
quite a lot more functionality than other similar tools the user
already has available.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
