[HN Gopher] GNU Autotools: A Tutorial [pdf]
___________________________________________________________________
GNU Autotools: A Tutorial [pdf]
Author : jnxx
Score : 38 points
Date : 2021-03-29 09:04 UTC (1 days ago)
(HTM) web link (elinux.org)
(TXT) w3m dump (elinux.org)
| dwheeler wrote:
| If you prefer a video, you might check out my 3-part autotools
| tutorial, starting here:
| https://www.youtube.com/watch?v=4q_inV9M_us
|
| The video shows an animation about how the autotools work (which
| I think helps understanding), and has a CLI demo of how to use
| it, all for the low price of free :-).
| jnwatson wrote:
| The burning question is: is Autotools worth it these days?
|
| In my early days of programming, I thought Autotools was the
| coolest thing in the whole world. It was essentially magic.
|
| These days, with the demand for running on non-Linux UNIX at an
| all time low, why put yourself through all this?
| aparsons wrote:
| For most programming (ie - web services), no. For anything that
| makes system calls within 1-2 layers of abstraction (graphics
| programming, shell utilities, etc) it is a godsend
| stabbles wrote:
| Today I had to use autotools for the first time, where I
| previously only used CMake.
|
| I thought I should be scared, and m4 looks daunting, but what
| they at least get right is that it's trivial to generate both
| shared and static libraries, cross-compilation is a breeze, and
| in the end all you need is a shell to configure and make to
| install.
|
| CMake defaults to either shared or static libs, and sometimes you
| have to read the docs for a project to figure out what custom
| variables influence this; and cross-compilation is almost always
| guaranteed not to work because some find_x cmake script tries to
| compile and run a C source to figure out certain properties about
| the target (but it confuses that with the host system).
| Thev00d00 wrote:
| Or use anything else.
|
| CMake or Meson have both learned the lessons of Autotools and so
| you dont need to subject yourself to them anymore.
| jnxx wrote:
| A nice introduction how autotools work, what are the basic
| concepts, and what one needs to know to configure an autotools
| build in a standard project. Especially compared to some other
| build systems, it is not only solid and well thought-out but also
| surprisingly well documented.
|
| Another really nice, more detailed introduction is this one:
|
| https://www.lrde.epita.fr/~adl/dl/autotools.pdf
| smartmic wrote:
| I also highly recommend John Calcote's book "Autotools" from no
| starch press: https://nostarch.com/autotools2e
|
| Probably the best technical book I bought in the last year. After
| the lecture, I have put aside all whispered-in prejudices and am
| convinced that it will still be worth betting on GNU autotools in
| the 2020s.
| chiumichael wrote:
| What are some things that autotools can do that more modern
| tools can't?
| smartmic wrote:
| First thing that comes to my mind is the best-in-class cross-
| UNIX compatibility. But shouldn't the question be the other
| way around: What can the modern tools do that autotools
| can't?
| dragontamer wrote:
| The obvious: CMake compiles into either Makefiles or Visual
| Studio solutions, allowing for cross Linux / Windows
| builds.
|
| Support for Ninja files also seems to speed up builds in my
| experience. (Ninja is a Makefile "assembly language",
| minimal features, assuming that things like CMake files
| compile into Ninja). Ninja is fully multithreaded and
| focused on speed instead of features, and it really does
| show.
|
| Since ./configure is single-threaded, a substantial amount
| of time needs to be spent whenever you make changes to your
| Autoconf / Automake stuff.
|
| CMake has a few nice things: a built in basic testing
| framework (just interpreting the exit codes of programs: 0
| is success and anything else is test-failure). Said testing
| framework has been integrated into various other test
| frameworks (like Googletest: https://cmake.org/cmake/help/l
| atest/module/GoogleTest.html).
| chiumichael wrote:
| Good point. Personally, I've avoided autotools for a long
| time since many projects use CMake and because of its
| reputation as a painful thing to learn. Lately, however,
| I've started learning more about autotools, so was just
| curious as to what it's really good at.
| smartmic wrote:
| Oh yes, the reputation of the learning curve precedes it.
| But the book helped me get started and, as is often the
| case with complex things, once you've dealt with it a
| bit, the experience wasn't as bad as I feared.
| sramsay wrote:
| I am absolutely the opposite. I've avoided CMake for a
| long time since many projects use autotools and because
| of its reputation as a painful thing to learn. ;)
|
| But actually, one of the points made in the Calcote book
| really stuck with me. Build tools are not just about
| developer convenience; they're also about the user's
| convenience. It's more work on my end, but my users (who,
| admittedly, are on UNIX-likes) know to type:
| ./configure make
|
| From _their_ standpoint, it just works as expected.
| jnxx wrote:
| One thing that I am wondering: Why do git repos with totools
| build chain often include the generated files, like ./configure ?
|
| Wouldn't it just be better to provide the source files
| (autoconf.ac and Makefile.am) and instruct developers to run
| "autoreconf" to generate the rest? That would it also make much
| clearer which files need to be changed if e.g. source files are
| added.
| froh wrote:
| Linux distributions like suse or redhat actually bootstrap
| autotools during build, to.enforce consistency. at least they
| did 10y ago.
|
| you will sometimes run into subtle forward porting issues doing
| this.
|
| that's why not doing this and using the generated Makefile and
| ./configure is a good idea (tm) for most consumers of packages.
|
| in other words: if you're in for adventure and learning, go for
| autoreconf. https://wiki.debian.org/Autoreconf
| stabbles wrote:
| In my experience they don't often have a configure file in the
| repo, but only in the release tarball (some repos on github
| have an action to setup a tarball with configure script). That
| way the user only needs a shell and make, nothing else.
| geofft wrote:
| It depends on the extent to which the git repo is s product for
| end users vs. for developers. Traditionally, the product for
| end users was the source tarball... but also, traditionally, we
| didn't have git. :)
|
| The whole point of autotools is that the output (./configure)
| is highly portable and can be run on basically any mostly-
| POSIX-compliant /bin/sh. You don't need to install anything
| beyond sh and make just to perform the build - compare with a
| design like Bazel where you need a piece of software to do the
| build.
|
| If the generated files change rarely, checking in and
| committing the generated files means people who are just making
| code changes (or no changes at all) don't need to install
| autotools.
|
| Also, there are functionality changes in certain versions of
| autotools; you might want to make sure your users get a feature
| that was implemented in a recent version of autotools, but
| support users who are running on an older OS that doesn't have
| that version packaged.
|
| (If you expect the git repo to be primarily used by developers
| / contributors instead of end users who are just building it,
| then you should definitely gitgnore the generated files, but
| also make sure to include them in the release tarballs. "make
| dist" will do it. You should also guide end users to download
| that release tarball instead of an auto-generated tarball of
| your git sources - GitHub and GitLab both have support for file
| attachments in their release feature, these days.)
|
| In our modern world, this might be less important because
| installing software (even specific versions of software) is a
| lot easier. But then our modern world probably deserves
| something other than autotools, because a lot of what makes
| autotools hard to work with is the fact that it's intended to
| translate down to sh/make. (Options I'm aware of that look
| fairly reasonable include Meson/Ninja, CMake, and I guess
| Bazel.)
| helaoban wrote:
| You'll find that many projects include a "bootstrap" script
| that does just that.
___________________________________________________________________
(page generated 2021-03-30 23:01 UTC)