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. You only need to focus on two files: configure. You can also write normal Makefile rules there. Then run.
|Published (Last):||3 July 2008|
|PDF File Size:||3.2 Mb|
|ePub File Size:||4.72 Mb|
|Price:||Free* [*Free Regsitration Required]|
Things get even more interesting when you think that there is the Autoconf Archive — which, by the way, references Autotools Mythbuster as best practices — and then projects such as dolt that are developed by completely separate organisations. I do think that this is a quite big drawback of autotools compared to things like CMake: you now have to allow for combinations of different tools written in different languages autoconf is almost entirely shell and M4, automake uses lots of Perl, libtool is shell as well , with their own deprecation timelines, and with different distributions providing different sets of them.
My guess is that many problems lie in the different sets of developers for each project. I know for instance that Stefano at least was planning to have a separate Automake-NG implementation that did not rely on Perl at all, but used GNU make features, including make macros. I generally like this idea, because similarly to dolt it removes overhead for the most common case any Linux distribution will use GNU make by default , while not removing the option where this is indeed needed any BSD system.
On the other hand it adds one more dimension to the already multi-dimensional compatibility problem. For instance if you accepted Perl as a dependency of the package — since automake needs it; but remember this is not a dependency for the projects using autotools! And it would probably be interesting if you could just declare in your configure.
So the new version of Automake is out, and is most likely going to be the last release of the first major version. The next version of Automake is going to be 2. After the various issues in 1. While a bunch of features are getting deprecated with these two versions, they will not be dropped at least until version 3.
This mean that there should be all the time for developers to update their Autotools before they starting failing. For instance, the C compilation handling has been streamlined, with anticipation of further streamlining on Automake 2. What does this mean?
Mostly that there is one fewer line to add to your configure. It also means that the compile script is now needed by all automake projects. The only one new feature that I think is worth the release, is better support for including files within Makefile.
This is a follow-up on my last post for autotools introduction. So after creating a simple autotools build system in the previous now you might want to know how to build a library — this is where the first part of complexity kicks in. The complexity is not, though, into using libtool, but into making a proper library. Some projects that only ever deal with programs still use libtool because that way they can rely on.
My suggestion is very simply not to rely on them as much as you can. Doing it this way means that you no longer have to care about using libtool for non-library-providing projects. But in the case you are building said library, using libtool is important. First of all, make sure to have an unique prefix to your public symbols, be them constants, variables or functions. Reducing the amount of symbols that you expose is not only a good performance consideration, but it also means that you avoid the off-chance to have symbol collisions which is a big problem to debug.
So do pay attention. Once you got these details sorted out, you should start by slightly change the configure. My personal recommendation is not to touch those options in most cases. Packagers will disable static linking when it makes sense, and if the user does not know much about static and dynamic linking, they are better off getting everything by default on a manual install.
On the Makefile. First of all, with the name autotools, we include quite a bit of different tools. If you have a very simple program not hellow-simple, but still simple , you definitely want to use at the very least two: autoconf and automake. This means that you need two files: configure. The first of the two files configure.
Let me explain. The first two lines are used to initialize autoconf and automake respectively. The former is being told the name and version of the project, the place to report bugs, and an URL for the package to use in documentation. After initializing the tools, you need to, at the very least, ask for a C compiler. Yes this is really enough as a very basic Makefile. If you were to have two programs, hellow and hellou , and a convenience library between the two you could do it this way:.
This is the automagic dependency problem, but on the other branch. When the user has no way to opt out from it which is bad , we call it an automagic dependency. But what happens if the user has requested it and the feature is not available? The same goes for freetype. Checking for all of that would be nice, but I have honestly no way to do it.
In particular, with pkg-config , the kind of setup you should have is the following:. This would hopefully make sure that in the future, most configure scripts will follow this approach. I could understand the complaint if it was posted on Planet Gentoo. I mused last week about the possibility of publishing Autotools Mythbuster as an eBook — after posting the article I decided to look into which options I had for self-publishing, and, long story short, I ended up putting it for sale on Amazon and on Lulu which nowadays handles eBooks as well.
Much more interesting than this is, though, the technical aspect of publishing the guide as an eBook. The two options produce quite different files, respectively in ePub 3 and ePub 2 format. On the other hand, getting these two to work also got me to have a working upgrade path to XHTML 5, which failed for me last time.
Hopefully, before next week there will be a new update for both website and ebooks that will cover most of this, and more. The final word has to clarify one thing: both Amazon and Google Books put the review on hold the moment when they found the content available already online mostly on my website and at Gitorious , and asked me to confirm how that was possible. The new style is just a bunch of changes over the previous one even though I also made use of sass to make the stylesheet smaller , and for the most part is to give it something recognizable.
I need to spend another day or two working on the content itself at the very least, as the automake 1.
But leaving the content side alone, let me address a different point first. More and more people lately have been asking for a way to have the guide available offline, either as ebook ePub or PDF or packaged. On the other hand, while not expecting to get rich off it, I would like to know that the time I spend on it is at least partly compensated — token gestures are better than nothing as well — and that precludes a simple availability of the content offline, which is what people at this point are clamoring for.
Mostly I want to have a way to stop somebody else exploiting my work for gain. If I drop the NC clause, nothing can stop an asshole from picking up the guide, making it available on Amazon, and get the money for it.
Is it likely? Since the content is also available on Git — right now on Gitorious, but read on — it would be trivial to do. But again, this would be cannibalizing the only compensation I got for the time spent on the guide. Which makes me very doubtful on what to do. Yes, it is already available offline through Gitorious, but GitHub would make it effectively easier to get offline than to consult online.
Is that what I want to do? Luckily, this has changed recently, so the obstacle is actually fallen. Too bad. Well, there has been two releases already, 1. First of all, there are two releases because the first one 1. After a complain from Paolo Bonzini related to a patch to sed to get rid of the old macros, Stefano decided to re-introduce the macros as deprecated in 1.
What does this tell me? Well, two things mainly: the first is that this release has been rushed out without enough testing the beta for it was released on December 19th! The second that there is still no proper process in the deprecation of features with clear deadlines of when they are to disappear. This impression is further strengthened in respect with some of the deprecation that appear in this new release, and some of the removals that did not happen at all.
This release was supposed to mark the first one not supporting the old-style name of configure. For some reason — none of which has been discussed on the automake mailing list, unsurprisingly — it was decided to postpone this to the next release.
It still is a perfectly good idea to rename the files now, but you can probably get pissed easily if you felt pressurized into getting ready for the new release, and then the requirement is dropped without further notice. Which means I have to document it myself, as I find it extremely stupid to have a feature that is not documented anywhere, but is found in the wild.
All of this is already documented in Autotools Mythbuster even though there is more work to do. Then there are things that changed, or were introduced in this release. First of all, silent rules are no longer optional — this basically means that the silent-rules option to the automake init is now a no-op, and the generated makefiles all have the silent rules harness included but not enabled by default as usual. For me this meant a rewrite of the related section as now you have one more variant of automake to support.
Then there finally is support in aclocal to get the macro directory selected in configure. I just decided to post it as it is, even though there are a few things that are slightly out of date. Please bear with me. Well, the problem comes from automake, and its ties to the GNU project it belongs to. The idea behind it is that the default settings of automake have to fit with the GNU projects.
And GNU projects have a long list of coding styles, best practices, and policies that might sound silly and some are but are consistently followed by official projects. These policies not only mandate the presence of a stable set of files including those noted above, and a couple more , but also that the portability warnings are enabled, as the resulting Makefiles are supposed to be usable with non-GNU make implementations.
So how do you fix this? Which is very likely what you want. Do note that the fact that the files are no longer mandatory does not mean that you can no longer use them. But trust me, you want to be a foreigner, in GNU land. Build systems using automake have a default target for testing purposes called check.
This target is designed to build and execute testcases, in a pretty much transparent way.
Autotools Mythbuster is a no-nonsense guide to Autotools, written with the idea of providing a full, integrated view of the tools in the GNU build chain: autoconf, automake, libtool, pkg-config, and so on. Instead of providing a full detailing of the workings of the components, which most consumers are not interested on, this guide focuses on building useful, solid and distribution-friendly packages, that developers can submit to distributions without having to jump through hoops to get them accepted. Autotools Mythbuster is available as an eBook for those who want to read or reference it online. Profits from its sales are used to pay for hosting and domain name registration. You can find the book on all major Amazon websites, as well as Kobo and their franchises. Amazon Germany.
Tag: Autotools Mythbuster
It can be difficult to make a software program portable: the C compiler differs from system to system; certain library functions are missing on some systems; header files may have different names. One way to handle this is to write conditional code, with code blocks selected by means of preprocessor directives ifdef ; but because of the wide variety of build environments this approach quickly becomes unmanageable. Autotools is designed to address this problem more manageably. Autotools is part of the GNU toolchain and is widely used in many free software and open source packages. Its component tools are free software -licensed under the GNU General Public License with special license exceptions   permitting its use with proprietary software. The GNU Build System makes it possible to build many programs using a two-step process: configure followed by make.
Goodreads helps you keep track of books you want to read. Want to Read saving…. Want to Read Currently Reading Read. Other editions.
Things get even more interesting when you think that there is the Autoconf Archive — which, by the way, references Autotools Mythbuster as best practices — and then projects such as dolt that are developed by completely separate organisations. I do think that this is a quite big drawback of autotools compared to things like CMake: you now have to allow for combinations of different tools written in different languages autoconf is almost entirely shell and M4, automake uses lots of Perl, libtool is shell as well , with their own deprecation timelines, and with different distributions providing different sets of them. My guess is that many problems lie in the different sets of developers for each project. I know for instance that Stefano at least was planning to have a separate Automake-NG implementation that did not rely on Perl at all, but used GNU make features, including make macros. I generally like this idea, because similarly to dolt it removes overhead for the most common case any Linux distribution will use GNU make by default , while not removing the option where this is indeed needed any BSD system. On the other hand it adds one more dimension to the already multi-dimensional compatibility problem. For instance if you accepted Perl as a dependency of the package — since automake needs it; but remember this is not a dependency for the projects using autotools!