Next 2. Non-recursive Automake One of the common criticisms of automake is that most projects that make use of it use multiple Makefile. For quite a while, though, automake supports non-recursive builds, with a single Makefile. This is, actually, the best method to use with automake, since this not only covers the problems discussed in [ MillerRecursiveMake ] but also avoids the need for multiple convenience libraries to store the partial results.

Author:Muzshura Jukora
Country:Cape Verde
Language:English (Spanish)
Published (Last):18 October 2006
PDF File Size:2.22 Mb
ePub File Size:13.88 Mb
Price:Free* [*Free Regsitration Required]

Next 4. Library Versioning One of the hardest part during the development of a library package is handling of version information, as it relates to the binary interface exposed by said libraries and is, thus, governed by those rules rather than what is a more human readable release version.

The former includes, among others, the names of the functions, the meaning of the parameters, and the elements within structures. The latter adds to this the data types used for parameters and return values, and the order of the structures themselves.

Obviously, all the version components to the right of the one that is increased should then be reset to zero. For what concerns the version of the ABI, it should not, generally, be tied to the release version; exceptions are possible, but will be documented later on. Since the version attached to a library refers to its ABI, whenever the ABI changes, the version need to change, even if this happens within the same minor version, just with a new release.

This is the reason why the two versions are not supposed to have the same value. Setting the proper Shared Object Version Developers working on Linux workstations will probably have noticed that most libraries built through libtool have three numbers at the end of their name, such as libfoo.

This is not the case. To set the version of the library, libtool provides the -version-info parameter, which accepts three numbers, separated by colons, that are called respectively, current, revision and age. Both their name and their behaviour, nowadays, have to be considered fully arbitrary, as the explanation provided in the official documentation is confusing to say the least, and can be, in some cases, considered completely wrong.

Warning A common mistake is to assume that the three values passed to -version-info map directly into the three numbers at the end of the library name. This is not the case, and indeed, current, revision and age are applied differently depending on the operating system that one is using. For Linux, for instance, while the last two values map directly from the command-line, the first is calculated by subtracting age from current.

On the other hand, on modern FreeBSD, only one component is used in the library version, which corresponds to current. The rules of thumb, when dealing with these values are: Always increase the revision value. Increase the current value whenever an interface has been added, removed or changed. Increase the age value only if the changes made to the ABI are backward compatible.

The main reason for which libtool uses this scheme for version information, is that it allows to have multiple version of a given library installed, with both link editor and dynamic linker choosing the latest available at build and run time. With modern distributions packaging standards, this situation should not be happening anyway.

Another common mistake is to match the value of -version-info with the package version or vice-versa. The two values are not designed to match: current increases with any interface change, compatible or not, and revision should be incremented with any package version.

If the package version were to match the -version-info options, you would obtain a sequence of 0. It would keep correct if every release had backward-incompatible ABI changes 0.

While this versioning scheme is monotonically increasing, its format is exceedingly complicated and is due to cause confusion in packagers and users, as a non-backward-compatible ABI change might still be fully source compatible, and thus a jump from version 1. It is suggested to refrain from idiosyncratic versioning for packages, in favour of more reliable and understandable semantic versioning. Following semantic versioning for the package while trying to apply the same to the library would also lead to confusing and inconvenient behaviour as the parameters are mangled by libtool according to the system it is building for and are thus going to produce incorrect results in some cases.

Multiple libraries versions While libtool was designed to handle the presence of multiple libraries implementing the same API and even ABI on the system, distributions made that necessity moot. On the other hand, it is not uncommon for multiple versions of a library to be installed, with multiple API implemented, allowing consumers to pick their supported version. The first reaction would be to combine the two options, -release and -version-info; this would, though, be wrong.

When using -release the static archive, the one with. To do so, the declaration in the Makefile.


GNU Autotools

DasIch on Dec 17, Learning about autotools is an amazing source of fremdscham. That everyone else just kind of seemed to go with it It is not clear to me that the essential complexity of the problem is significantly simpler than the autotools solution. Contemplating all that probably makes autotools come out looking pretty good in context. Well, way back in the day when they existed to the degree they did.


Tag: Autotools Mythbuster

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.


Autotools Mythbuster: automake pains

Next 3. Nonetheless, there are some caveats that require attention when using the macro. This value, usually provided in uppercase, is used as prefix to the variables holding the compiler flags and libraries reported by pkg-config. This will also be used as message during the configure checks: checking for FOO Each entry in the list can have a version comparison specifier, with the same syntax as the Requires keyword in the data files themselves. In contrast with almost all of the original macros, though, the default action-if-not-found will end the execution with an error for not having found the dependency. The names of these variables can be somewhat misleading, since the former will generally provide the flags to pass to the preprocessor, rather than the compiler, such as include paths and macro definitions, and the latter will provide the library paths as well as the libraries themselves.

Related Articles