Building nested Autotools Package without Installing

3
votes

What I want is to build my autotools package together with a nested autotools package. It's a static library and usually this package install the lib in your $prefix/lib folder, if you type make && make install

Sub-Package-Files:

configure.ac

AC_INIT([testlib],[1.0],[[email protected]])
AM_INIT_AUTOMAKE([foreign -Wall -Werror])
AC_PROG_CC()
AC_PROG_RANLIB()
AC_CHECK_HEADERS()
AC_LANG([C])
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT

Makefile.am

SUBDIRS = src

src/Makefile.am

lib_LIBRARIES = libtestlib.a
libtestlib_a_SOURCES = testlib.c
include_HEADERS = testlib.h

But I want to use it as a nested package in my autotools package and need it only for linking while build time.

So how do I achieve that my package is build & installed but the sub- / nested package is only build without modifying the configure.ac or the Makefile.am from the sub-package?

3
clinuxgccautotoolsautoconf
It would seem that what you want to do completely subverts the purpose of libraries, and is not a well supported workflow. If you want to use some other package as a convenience library, then pull the source code out of it and use it in your own package. Or have the user install the other package in a temporary location and build statically linked executables. But, really, the better option is to have the user install the dependency. - William Pursell
Why? If the library is already shipped as a automake package, why don't use it, when automake already have the facilitiy to include subpackages? I want to keep the installation simple for users. So I don't want them to install the dependencys by their own. I don't want to install this lib in the system, because the user don't need it. It's an static library that is only needed for this build! If the user decides to use this lib more often in his own projects; At this time it makes sense to install the library, but not for only one build! - Sebi2020
Because the autotools are not a package management system, and they should not be used as such. If your goal is to keep installation simple for users, then give them an rpm, or a deb, or a pkg, or whatever package you like. - William Pursell
Yes not a package management but with dependency tracking and the ability to include subpackages... However I had never spoken about package management and to include the libs that are a part of the program doesn't mean to use autotools as a package manager... I don't know how you've got this idea... - Sebi2020
The phrase "I want to keep the installation simple for users" screams "package management system". - William Pursell

3 Answers

2
votes

So how do I achieve that my package is build & installed but the sub- / nested package is only build without modifying the configure.ac or the Makefile.am from the sub-package?

Your best bet is probably to use AC_CONFIG_SUBDIRS in the top-level configure.ac to link configuration of the subpackage with the top-level package, but to avoid using SUBDIRS in the top-level Makefile.am to trigger make recursing into the subpackage. Instead of the latter, add a manual rule to the top-level Makefile.am for building the wanted library via a recursive make.

In the top-level package, that would look something like this:

configure.ac

# ...
AC_CONFIG_SUBDIRS([testlib-1.0])
# ...

Makefile.am

# ... testlib-1.0 *not* present in SUBDIRS ...

testlib-1.0/src/libtestlib.a:
    $(MAKE) -C testlib-1.0

Be sure, then, to express a proper dependency on testlib-1.0/src/libtestlib.a where needed, and to use appropriate link options at the top level.

1
votes

Use AC_CONFIG_SUBDIRS([testlib]). For code samples, read more about it in the documentation.

EDIT

If you wanted to build convenience libraries without touching the subpackage (for instance, if you stored it as a Git submodule in your main Git repository) then you could:

  • copy the relevant checks from the subpackage's configure.ac into your package's configure.ac
  • have your package's configure.ac include AC_OUTPUT([subpackage/Makefile])
  • leave subpackage out of SUBDIRS in Makefile.am

  • have your package's Makefile.am build the relevant parts of subpackage the way you want them, e.g.

    noinst_LIBRARIES = subpackage/libsubpackage.a
subpackage_libsubpackage_a_SOURCES = subpackage/source.c etc.

This may not be what you want, as it involves duplicating a lot of subpackage's build system, but it does allow you to drop the subpackage into your package unchanged.

1
votes

I'm not sure if this is too hackish, but giving the SUBDIRS variable a target-specific value seems to work and looks relatively elegant:

SUBDIRS = src

install installdirs: SUBDIRS =

or, more generally

SUBDIRS := foo bar libgazonk

install installdirs: SUBDIRS := $(filter-out libgazonk, $(SUBDIRS))

(Simple expansion necessary to avoid infinite recursion.)