If you want to get started with autotools, try to build yourself a minimal autotools
project. Once you have a working stub, you already took the biggest hurdle.<p>You only need to focus on two files: configure.ac, where you check for features, and Makefile.am, where you list your build targets and their sources. You can
also write normal Makefile rules there.<p>After editing these files, run `autreconf -fi` to create/update the configure and Makefile script. Then run<p><pre><code> ./configure
make
</code></pre>
to build your project. Have a look at Appendix A/Basic Autotoolization on the submitted website or checkout libabc by Poettering/Sievers:<p>1. <a href="https://autotools.io/whosafraid.html#idm117385102076160" rel="nofollow">https://autotools.io/whosafraid.html#idm117385102076160</a><p>2. <a href="http://0pointer.de/blog/projects/libabc.html" rel="nofollow">http://0pointer.de/blog/projects/libabc.html</a>
Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.
While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit.<p>It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.
Could anyone speak to why you would use Autotools today in a new project rather than gyp [0] (created by the Chrome team because Autotools sucks) or waf [1]? How many people really have a requirement to support more than just Windows, OS X, and Linux? I can understand not wanting to rip out a working Autotools implementation of a legacy project, but it's greenfield use should decline to zero.<p>[0] <a href="https://gyp.gsrc.io/" rel="nofollow">https://gyp.gsrc.io/</a>
[1] <a href="https://github.com/waf-project/waf" rel="nofollow">https://github.com/waf-project/waf</a>
This looks like a really useful guide through autotool hell, which is a fantastic thing to have, but it's not clear what <i>myths</i> are being busted so the name seems like a bit of a misnomer. Perhaps "Autotools Life Preserver" or something would be more accurate.
GNU make has macros too, but these were added much later than 1991; Interesting if make macros were available earlier, would people have used them instead of autotools ?<p>Thank you for the link on autotools, i will try to apply it if i am ever forced to do something with autoconf/autotools.
Please please please do not use ./configure aka autohell.<p>Study the Makefiles in <a href="http://git.suckless.org/" rel="nofollow">http://git.suckless.org/</a><p>Straightforward & fast.
I confess that I don't even know how to write a makefile, but reading the comments here, should I understand that cmake is better than autotools? Or should I learn autotools instead of cmake?<p>Since cmake is more adopted, isn't cmake better ?
One of the first lines<p>"...the language used to write the configure.ac is called M4sh, to make clear that it's based off both sh and the macro language M4. "<p>Tip: don't use Autotools