Create your first Conan package with Autotools

Warning

This example will only work for Linux and OSX environments and does not support Windows directly, including msys2/cygwin subsystems. However, Windows Subsystem for Linux (WSL) should work since it provides a Linux environment. While Conan offers win_bash = True for some level of support in Windows environments with Autotools, it’s not applicable in this tutorial.

In the Create your first Conan package tutorial CMake was used as the build system. If you haven’t read that section, read it first to familiarize yourself with the conanfile.py and test_package concepts, then come back to read about the specifics of the Autotools package creation.

Use the conan new command to create a “Hello World” C++ library example project:

  1. $ conan new autotools_lib -d name=hello -d version=0.1

This will create a Conan package project with the following structure.

  1. ├── conanfile.py
  2. ├── configure.ac
  3. ├── Makefile.am
  4. ├── src
  5. │   ├── hello.h
  6. │   ├── hello.cpp
  7. │   └── Makefile.am
  8. └── test_package
  9.     ├── conanfile.py
  10.     ├── configure.ac
  11.     ├── mainc.pp
  12.     └── Makefile.am

The structure and files are very similar to the previous CMake example:

  • conanfile.py: On the root folder, there is a conanfile.py which is the main recipe file, responsible for defining how the package is built and consumed.

  • configure.ac: An autotools configuration script, that contains the necessary macros and references the Makefiles it needs to configure.

  • Makefile.am: A Makefile configuration file, defining only SUBDIRS = src

  • src folder: the folder that contains the simple C++ “hello” library.

  • src/Makefile.am: Makefile configuration file containing the library definition and source files like libhello_la_SOURCES = hello.cpp hello.h

  • test_package folder: contains an example application that will require and link with the created package. In this case the test_package also contains an autotools project, but it is possible to have the test_package using other build system as CMake if desired. It is not mandatory that the test_package is using the same build system as the package.

Let’s have a look at the package recipe conanfile.py (only the relevant new parts):

  1. exports_sources = "configure.ac", "Makefile.am", "src/*"
  3. def layout(self):
  4.     basic_layout(self)
  6. def generate(self):
  7.     at_toolchain = AutotoolsToolchain(self)
  8.     at_toolchain.generate()
  10. def build(self):
  11.     autotools = Autotools(self)
  12.     autotools.autoreconf()
  13.     autotools.configure()
  14.     autotools.make()
  16. def package(self):
  17.     autotools = Autotools(self)
  18.     autotools.install()
  19.     fix_apple_shared_install_name(self)

Let’s explain the different sections of the recipe briefly:

  • The layout() defines a basic_layout(), this is less flexible than a CMake one, so it doesn’t allow any parametrization.

  • The generate() method calls AutotoolsToolchain that can generate a conanautotoolstoolchain environment script defining environment variables like CXXFLAGS or LDFLAGS that will be used by the Makefiles to map the Conan input settings into compile flags. If the project had dependencies with Conan requires, it should add PkgConfigDeps too

  • The build() method uses the Autotools() helper to drive the build, calling the different configure and build steps.

  • The package() method uses the Autotools install functionality to define and copy to the package folder the final artifacts. Note the template also includes a call to fix_apple_shared_install_name() that uses OSX install_name_tool utility to set @rpath``to fix the ``LC_ID_DYLIB and LC_LOAD_DYLIB fields on Apple dylibs, because it is very unusual that autotools project will manage to do this (CMake can do it) .

Let’s build the package from sources with the current default configuration, and then let the test_package folder test the package:

  1. $ conan create .
  3. ...
  4. ======== Testing the package: Executing test ========
  5. hello/0.1 (test package): Running test()
  6. hello/0.1 (test package): RUN: ./main
  7. hello/0.1: Hello World Release!
  8.   hello/0.1: __x86_64__ defined
  9.   hello/0.1: _GLIBCXX_USE_CXX11_ABI 1
  10.   hello/0.1: __cplusplus201703
  11.   hello/0.1: __GNUC__11
  12.   hello/0.1: __GNUC_MINOR__1
  13. hello/0.1 test_package

We can now validate that the recipe and the package binary are in the cache:

  1. $ conan list "hello/1.0:*"
  2. Local Cache:
  3.   hello
  4.     hello/1.0
  5.       revisions
  6.         5b151b3f08144bf25131266eb306ddff (2024-03-06 12:03:52 UTC)
  7.           packages
  8.             8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe
  9.               info
  10.                 settings
  11.                   arch: x86_64
  12.                   build_type: Release
  13.                   compiler: gcc
  14.                   compiler.cppstd: gnu17
  15.                   compiler.libcxx: libstdc++11
  16.                   compiler.version: 11
  17.                   os: Linux
  18.                 options
  19.                   fPIC: True
  20.                   shared: False

See also