automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[CRAZY PROPOSAL] Automake should support only GNU make


From: Stefano Lattarini
Subject: [CRAZY PROPOSAL] Automake should support only GNU make
Date: Wed, 12 Jan 2011 19:01:47 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

[Adding address@hidden, dropping address@hidden

References:
 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7824>
 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7670>

On Wednesday 12 January 2011, Юрий Пухальский wrote:
> Aye, looks like it.
> 
> I have no objections whatsoever, i just need some method to make it
> work, because it's my working project:)
> 
To be honest, I'm starting to agree with Ralf more and more on these
issues; i.e., just " ... require a decent make ;-)".

And more than this -- brace yourself -- I'm starting to think that
automake should *really* start supporting *only* GNU make (at least
from version 3.75 or so).

[ Note: I'm not saying this should be done right away, or from the
  next version either.  It's more an "automake 2.0" sort of thing,
  which would require extensive planning and discussion -- and surely
  an experimental git branch with a long road ahead! ]

My idea above might seem such an heresy that I guess I must offer an
in-depth justification for it.


[About GNU make]

 GNU make is a basic component of the GNU system, actively maintained and
 developed, well documented, and required by other very important projects
 (Linux Kernel and Git DVCS, for example).

 GNU make is very portable, easy to compile, and fully bootstrapping (its
 build system does not require a pre-existing make installation).
 
 GNU make is the default make program on GNU/Linux (okay, we're in
 full platitude land here, but I value completeness in this issue).
 
 GNU make is readily available in the FreeBSD port collection (and it's
 required by many other ports to compile, see
   <http://www.freebsd.org/doc/en/books/developers-handbook/tools-make.html>
 for more info).

 GNU make is available as a NetBSD package, for many architectures
 and versions; for example:
  
<ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/powerpc/4.0/devel/gmake-3.81.tgz>
  
<ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0/devel/gmake-3.82nb1.tgz>
  
<ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/sparc64/5.1/devel/gmake-3.81.tgz>
 

 GNU make should also be available as a Solaris precompiled package:
   <http://www.sun.com/software/solaris/freeware/>
 or as an unofficial pre-compiled binary:
   <http://www.sunfreeware.com/programlistintel10.html>.

 In conclusion, it's not unresonable to expect that a user ready to
 compile a package from sources will also be ready and capable to obtain,
 compile and install a non-ancient version of GNU make.


[About the purpose or "spirit" of Automake]

 Automake is about much more than just portability to different make
 implementations; it's about:
 
  - portability to different shells and tools used by make recipes;
  - easy integration with autoconf and libtool;
  - generation of portable rules for automatic dependency tracking;
  - automatic generation of testsuite drivers (capable of running
    tests in parallel, and with other nifty features, such as colored
    output and lazy re-running of tests);
  - the "mythical" distcheck target (ensures that a package works in
    a VPATH build, and that its distribution is fully self-contained);
  - generation and installation of different manual formats (info,
    PS, PDF, DVI) from Texinfo input;
  - active help in making your package's build system adherent to GNU
    coding standards;
  - and so on, and so on ...

 Some of the features above are IMHO such useful and such "killer
 features" that, just to have them readily available, I've sometimes
 used Automake in personal projects meant to run only on GNU/Linux,
 or even *only on my machine*!


[My humble conclusion]

 I don't think that requiring GNU make (not a specific version, just
 a less-than-fifteen-years old one) is gonna be an harsh or unreasonable
 requirement.  And the gains in terms of maintainability, testability,
 and possibility of optimization are obvous.


Regards,
   Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]