hpr-knowledge-base/hpr_transcripts/hpr3040.txt

Episode: 3040
Title: HPR3040: Why use GNU Autotools
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3040/hpr3040.mp3
Transcribed: 2025-10-24 15:35:48

---

This is Hacker Public Radio Episode 3,040 for Friday, 27 March 2020.
Today's show is entitled Why I Use New Autos. It is hosted by Kla too
and is about 29 minutes long
and carries a clean flag. The summer is
six good reasons you should be using a build system.
This episode of HPR is brought to you by archive.org.
Support universal access to all knowledge by heading over to archive.org forward slash donate.
You're listening to Hacker Public Radio. My name is Kla too and this episode is going to sell you
I hope on Gnu Autotools. What is Gnu Autotools? The shortest way to convey what that is
is the famous incantation.slashconfigure make install. If you've read about that
if you may be performed to that process yourself then you know right away what Gnu Autotools is.
You may not understand what it does exactly but you know that you've used it.
Or anyway that's how Autotools manifests itself.
What it really is to you as a possible software developer.
And if you don't think of yourself as a software developer then maybe you any kind of software that you have written
like whether it's a bash script or a python script or a little gooey or anything that you're working on
or if you intend to get there someday then Autotools is something that you actually might want to look
at sooner than later. Really is a really useful system.
Now it's not the only system. So in a way if there's some other build system
that you happen to know is more appropriate to your requirements.
So in other words if you are in fact writing a python application then possibly make the Gnu Autotools
maybe that isn't the best system for you. And maybe the better choice would be the python packaging system
or if you're developing in Java then maybe you want to use Ant or whatever the case may be.
You may, I invite you to continue to listen to this episode and to interpret
when I say Autotools, Gnu Autotools, hear something else, hear python, pip, easy install,
whatever they call it, easy setup, whatever they call it, hear Ant, whatever.
So in very broad terms this is an episode about using a build system over not using a build system.
And I think that's applicable to a lot of what we do actually.
And I'm going to tell you why. That's the point of this episode. I'm going to tell you exactly my thoughts on this subject.
And the reason it's about Gnu Autotools rather than one of those other systems is because I don't use those other systems.
I'm eager to learn them. I have not yet learned them. Gnu Autotools is what I got and it's what I'm selling you on.
Alright so that's what Autotools is. You know the commands, you know it's a build system, but what does that really mean?
Well Dan Waschko of the Linux link tech show once said, and I don't even know if he would remember this,
but he did once say a long time ago that quote or approximate quote, Linux does have a universal packaging format.
It's called Autotools. He said that. I don't remember if it was just a comment that he made an IRC or if he said it on a podcast.
I just don't remember. He said it and it made an impression on me even then because I thought well that's a really good point.
Like with open source software because the source code is there, there kind of is a universal way to make the application install on a computer.
And that is if the developers used it, Autotools.
Now there are arguments against that because well it's it's the letter of the law, but not the spirit of the law.
People are really saying we need a universal packaging format such as flat pack or snap or RPM or something like that.
That all Linux is used and there's no doubt that if something is put onto Linux it will run.
So that's a different conversation, but the the the technicality is still worth noting.
And that is when you have the source code, the ability to build it is very very significant.
And so new Autotools and any kind of build system that has kind of made official like that.
There is a system by which everyone can build the source code reliably and rip in a way that they can repeat.
So in other words, you build it on your development machine and then you package it up and send it away.
And then there's every expectation because you used this build system that someone else can run the same three commands that you ran to build the thing and end up with the same kind of structure and and number of files and types of files that you produced.
And the nice thing about that having this standardized way of building software more or less from the beginning, like if you structure your software project around Autotools, then you have that standard method of building and it all sort of works as expected for you and for your users and for packages.
And so there's well, there's a structure there, right? I mean that structure is a thing that exists and you know the layout.
So I don't I I'm trying to say the word sort of like or the concept of restrictions or constraints and that makes it sound like a bad thing.
But if you think about the alternative, which is just write your own shell script that sort of takes all the software and maybe it builds it if it has to be compiled or maybe it just puts it into the right directory and then copies it into your users computer.
Under your users computer under your users file system and so on.
You can do that. And in fact, I would say that in terms of ease of you know initial getting started sort of with Autotools, there's a big incentive not to get started with Autotools.
It's not a super easy system to learn necessarily. I mean, it's not by any means impossible, but there it's a new system.
It's things that you have to learn and to a new developer or a hobbyist developer, that's a tough sell because I mean you spent you know three, five, 10, 20 years learning bash and you feel really good about it now.
You're just getting started with bash, you know, actual scripts that that are very useful and and so you think, well, I know bash.
So surely this Autotools thing will be pretty much the same, right? It's from they're both GNU on the on the tin that's GNU and GNU.
Okay, so they it's got to be similar. It looks mostly similar. It's totally not similar. It's totally different. Sorry.
So you have to learn like Autotools now and isn't wouldn't it just be easier to resort to a quick bash script that would collect the files that you know that need to be put
under your user's computer and then just put them on there and that would be the bad be it. That'd be finished.
And you can do that too. You could do all kinds of clever checks to make sure that you're dealing with the kind of system that you think you're kind of you're dealing with and so on.
It would all work. But it's it's it's now now you've got everything available to you there. It's it's sort of like you're now looking out into the void or into undiscovered country.
Whereas previously you've been in or in the other scenario you've got Autotools and there's a it's a known quantity and that seems like a really weird benefit.
But it can actually be really really useful because the the process of installing software you know copying software from one place to another isn't actually that complex.
There's it can be because of the variables of the system and so on. But the the concept of it is pretty simple.
And so you don't you don't really need all that space you don't need that big undiscovered country in front of you.
That's not something that's useful to you as someone who just wants to copy some files onto your user system.
There's a bunch of boring stupid stuff that you have to do to check to see what kind of file system it is and see just make sure where everything is installed.
Make sure you got the libraries that you need and so on. All this ridiculous kind of checking that you might have to do.
You don't want to do that. You don't have to reinvent that wheel. Trust me. That's it's not worth it. That's not a good use of your time.
Let auto tools handle that for you.
So you don't have to reinvent the process.
And it's almost guaranteed that when you reinvent the process you're going to forget something you're going to reinvent it poorly.
Because auto tools has been around for a long time. People have already found all the annoyances about it.
Have they fixed them? Well maybe not all the annoyances have they fixed the bugs? Yeah a lot of them.
So auto tools is time tested and that little shell script that starts out as a quick really quick easy six line shell script.
And then it becomes a 12 line shell script because you realize that on any other system other than the what your development system.
There's other things that need to be done so you'll just add a couple of quick little conditionals.
It's going to be a really quick thing. It's just another six lines. It just doubles the size of the file. Not a big deal. It's a small file.
And then suddenly you distribute that and then suddenly you get reports back. Oh by the way you totally discount the fact that on this platform it's completely different.
Now you've got 24 lines of code and after that it's certainly done not a problem. And then you get another report and suddenly it's a 48 line script that's doing a bunch of checks.
And then now you've got to you've got to set some variables depending on what the what you discover about the host system.
But those variables need to go into at the actual code. So now you you have to build an infrastructure to change the actual code that's being that's going to be compiled and and it goes all over the place.
In other words you you you just develop now you're a developer of a build system. And that's not what you set out to do. That was not the goal.
You were just trying to develop this little helpful script that you found useful and thought other people might find useful as well. If only they could install it. Use auto tools.
None of that will happen. You will struggle to learn auto tools for a day two days three days a weekend whatever. And then you'll have figured it out at least for that one project if nothing else.
And you'll be able to release your project and people can build it reliably without any problem because auto tools that's what it does.
So that's one big reason right there is just that auto tools has been standardized. It is reliable. It is robust. That's the reason because auto tools because auto tools is auto tools.
That's that's one reason next reason. Consider this reason number two is because auto tools hooks into or rather it is hooked into a bunch of other packaging systems.
So auto tools is cool and all and I kind of get the feeling that at one point that it literally was a packaging system. Like you want to install some extra software on I don't know your Solaris box back in 1993.
Well guess what your options are a make file and and you get to build it or or you know if someone was clever and used the new auto tools then your option was run configure make make install and now it's installed.
And if you get tired of it and want to uninstall it then you have to do a make uninstall and then it's it's gone. It's off of your system and that was the packaging system.
Obviously people found that a little bit cumbersome if they installed one thing that relied on another and then they had to rebuild the thing because it needed a newer version and so on and so forth and that's why we have package management systems today.
But at one time that's what the the make system or rather auto tools and things like it that those were you know considered packaging systems and I mean to this day we have BSD with the port system which is just a big collection of make files so it's a valid system.
But what I'm going to say here and and BSD ports is not exclusive to this is that other packaging systems take advantage of and leverage auto tools they they they know that auto tools is a system to build software they know what to expect out of auto tools they know that auto tools is generally pretty reliable and predictable.
So a lot of times if you go to build for instance if you just go to build a quick RPM you just need to do a quick RPM you will be so happy if you find if you download the source code and find that it uses new auto tools I know I've been there I've been the person who is happy about it.
It feels so good because that RPM that could have been a 35 line macro spec file with a bunch of different macros and a bunch of directives it becomes like maybe a 12 line spec file.
Okay 12 is probably pretty low let's say I don't know 15 20 line whatever the day but it's super simple like all those basic macros that you that you find on like how to build an RPM kind of search results all of those you just plug them in you're just like okay here's the source here's the name of the package here's the version here's the you know here's the build directive here's the.
Install directive here's what I installed it's just bang bang bang easy no brainer you just you just see that it's new auto tools and you tell the RPM spec file okay run auto tools.
And you're basically done same goes for a Debian package a slack build a flat pack all of these things all of these major these sort of big make or these big packaging formats that are out there.
They know what to do with new auto tools now again I don't want to make this episode too much about the magic of the new auto tools specifically because it doesn't it's not necessarily only about new auto tools.
These build systems also recognize other other common build.
Program so you know like your your pips and your ants and your your gems and and I don't know grail and all these other things like all yeah they they they know what to do with those and that's great and that's very cool and so in other words the idea here is to use.
Use a packaging system do not use or use a build system rather do not use your own standard or your own sort of off the cuff invented shell script you can but it makes the.
It makes the process of packaging your application potentially a little bit more laborious and part of the idea of open source part of the.
The advantage of open source is that you don't have to be the person to go and build your software or package up your software for all the different platforms.
I mean realistically you just you can't be I mean you can be because you could you could do it and then you could automate it and it would all be done and and that's great that's a wonderful.
Newish kind of you know all the building automation things that exist nowadays it's really cool but you shouldn't really necessarily have to be the one to do all that ideally there are people out there looking for software to package and.
It makes it easier for them to contribute to your project if you use something.
That that that just gets plugged into something else it's just you know use that standard.
Plug.
Design.
So that they can connect it to their to their device.
That's a pretty good analogy I thought I just thought of that right off the top my head okay so.
Another good reason to use that that was reason number two just because other things plug into it or can accept a plug from that so it talks to other things.
Huge advantage as well is that auto tools is and I kind of I might be cheating now I mean those were really the two big reasons well actually you know what so I'm going to move this one up here in my little list so.
There's a the third reason that I really truly have.
Is it makes a versioning of your software and and adapting the code of the actual source code of your project really really easy and this is actually kind of what turned me on to auto tools eventually like because I avoided auto tools just like you are.
I figured I know shell scripting I can do this this is easy I'll just I'll just roll my own little installers because I mean frankly I couldn't figure out auto tools it's not an easy system and I'm going to explain it in a in a future episode I will explain auto tools to you so that maybe you'll have a leg up but I avoided it for a while and the thing that finally kind of.
Dreamy in was the ability to set to set variables.
That would then be assigned a value in the thing that gets built for distribution so in other words a lot of times for a version I would just in my in a shell script I would have version equals and there's the there's the version number and maybe that version gets called by something else or.
A Python application would be in the about section and and then before building I would have to remember to run something to set that version to increment that version number and so on and a lot of times.
That wouldn't be it wouldn't only be in one place I would have to go and change it in a couple of different places and that wasn't ever any fun so and I tried a couple of different things I tried like well I can.
I can I can automate it mostly with a make file and I'll put it in there and I'll have a said thing that goes through all the different things that does have this version variable somewhere and I'll put a number in there and so on but then how do you know what the number.
Was it what how do you know what you're incrementing it to and how do you get that information to your make file I mean you can you can pass an argument and so on it was just it was a mess it was more trouble than it was worth.
Autotools makes that so easy there's like one variable in one file you change that it goes it's distributed as needed it's beautiful and you can do that with more than just the version it doesn't have to be just the version number it could be other things to it can be any any manner of variables really so.
Autotools makes that really really easy once you learn it you know which of the sort of like the three vital files that that auto tools need to get sort of start out from you learn where those go and then you just don't have to worry about anymore you make those changes you commit it or you push it to your repo or whatever you do and you build it and you make your distribution copy and everything's there it's just done for you.
Speaking of everything being there and everything being done for you the other so that was the third reason versioning and sort of variable handling across the project the the fourth fifth and sixth reasons are technically just kind of their their cheats there I think I've already actually said everything but I'm going to go ahead and mention them just to kind of emphasize them because they're they're not.
They're not that they are a big deal it's worth mentioning so here the reason number four is you're building for various o s's for free you don't have to account for the fact that your project might be installed it might be built and installed onto a Mac or a windows box.
I'm assuming in this scenario that you've developed for Linux so you've developed something and maybe you're not even sure it will run on another platform but someone out there has the idea that they're going to build it and try it and maybe they'll who knows maybe they'll give you some patches to upgrade somewhere to change something so that it works better on other platforms the point is for them to get even that far.
You've got to they have to get it onto their system now we could we could argue well you know what if they're going to go to the all that trouble then let them figure out their own shell scripts I mean it's not going to be that hard this mythical person is going to be familiar enough with all of this stuff to be able to figure that out right well not necessarily first of all and then secondly it's just not you're asking someone else then to sort of reinvent a wheel or two.
To cross a distance that you could have already crossed with auto tools with auto tools you you can't fathom the number of lines of code that you get oh wait that's this is okay so that was reason for reason five is something that I'm mentioning now by accident but but it is related you get a lot of code for free with auto tools you just get a big dump a code after you run that dot slash configure.
And all of these other commands you get a bunch of really really smart environment checking type of code for free stuff that you don't ever have to write yourself you don't even have to look at it you just get it.
And some of that code is is accounting for for a different platform platform that you may well never have expected your program to be installed on at all you never gave it the second thought or maybe you couldn't test it on that platform either because you maybe you don't have a Mac lying around at your disposal maybe you don't have a windows box lying around to test this thing on.
But it's open source people should be able to run it on any platform that they that they please and so if you wrap that up in a new auto tools container not literal container sorry if you if you put auto if you put it into a auto tools present box with wrapping then then you hand it off and people can just run auto tools and configure.
And it's all it's all calculated it's figured out the thing the system detects oh you you're not using you know you don't have this path so we'll default over to this path instead and so on.
So it's definitely worth doing for broader support that's reason number four and then reason number five is you do get a lot of code for free you get a lot of checks and system probes completely for free lots of stuff is managed for you.
It kind of boggles the mind if you ever look at it there's just a lot a lot of code there but it's it's stuff that you didn't have to worry about and it helps ensure that what is being built is pretty rock solid pretty robust stuff because it has checked lots of things for you.
And that's that's good that that can't be bad awareness of of what the system requirements are is is definitely a good thing.
And then finally the sixth reason that I've got for you is that all in one sort of configuration step for you as the developer not the dot slash configure step but the the part where you're rolling all of the auto tool configuration files that you need.
To do in order to make dot slash configure make make install actually function once you do that you do that once you know you configure your you you type in your little code to configure AC and make file am and all these other files that you have to do for auto tools but once you've done it you get you get a bill you get a build system for for you for yourself for testing and so on.
You get a build system for your users so you can you can send you can you can build a distributed package out to to users.
You also get a build system for packages which which may be the same or maybe different to kind of depends.
And so everyone wins from really one configuration step from one initialization process everyone gets what they need in order to build and run your code and that's a great feeling for everybody because there's just no question about how to do it.
There's no question as to whether it will work on their machine whether or at least whether it will it will at least put itself into the places where one would expect on their machine and ideally it does work on their machine I mean generally speaking if it compiles and builds and and installs I mean yeah go yeah installs said compile and build but what I mean is that yeah it compiles and everything goes into the folders that it is meant to locally.
And then they install it onto their machine then it generally runs I mean not always there are exceptions your code might be bad their system might be especially screwy that no one could have ever anticipated but generally speaking it runs and and it's really easy with auto tools.
Okay so just to reiterate though that was six six reasons you heard them you counted them but just to reiterate new auto tools is not necessarily the easiest thing to use.
Okay so you know how get is pretty pretty easy you do get in it return and suddenly the the the directory that you've just done that in is a get repository bang it's done you're you're good to go you are now using get that's not exactly how can you auto tools works it's a little bit more manual.
There's a lot of configuration that you have to learn like there are little bits of configuration files or yeah can build files I guess that you have to construct basically from scratch it's a little bit scary you know you just you open up a configure dot AC file and you think what is a dot AC file and what do I put into it so it can be intimidating.
It is not a shell script it is not something that you are familiar with yet probably unless you're using it but if you're if you're seeking to learn new auto tools this is all new to you this is not something that has really an equivalent you won't you're not writing in a list if you're an EMAX person you're not writing in bash if you've been practicing bash for all these years it's just completely different it's utterly new and it will there will be moments of discomfort and frustration.
That said I just gave you six really good reasons why it's actually worth it.
In the next episode on this very network hacker public radio I am going to I should have said in my next episode on this very network I am going to I'm going to teach you how to use new auto tools on your own project and after you hear that episode you will be empowered and excited.
To go use new auto tools I promise listen to my next episode try to prove me wrong.
You've been listening to hacker public radio at hacker public radio dot org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show like all our shows was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast and click on our contributing to find out how easy it really is.
Hacker public radio was founded by the digital dot pound and the infonomicon computer club and it's part of the binary revolution at binwreff.com.
If you have comments on today's show please email the host directly leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated today's show is released on the creative comments,
attribution, share a live 3.0 license.