How can I propagate automake variables in a sub-package setup?

Question

I have a sub-package setup in my autotools repository, in which several related projects are glued together using a master configure.ac and Makefile.am.

Aside from the compilation ordering, easily done via AC_CONFIG_SUBDIRS() macro, there is the need to export headers and library locations required between these excessively coupled sub-projects.

--- configure.ac
 |- Makefile.am
 |- subproj1 --- configure.ac
 |            |- Makefile.am
 |            |- src
 |            \- include
 [...]
 |
 \- subprojN --- configure.ac // requires -I${top_srcdir}/subprojX/include and
              |- Makefile.am  // -L${top_srcdir}/subprojX/src
              |- src
              \- include

Regrouping these packages as one is not an option, unfortunately. I tried exporting variables using AC_SUBST() and/or make's export command, for no avail.

The only way I could get these flags available into every sub-project Makefile was passing CPPFLAGS and LDFLAGS into the root configure invocation (via command-line). However, I'd hope if there is a way to keep these values inside autotools stuff, instead of having to create a separate script for them.

PS: similar to automake and project dependencies

Related [question](http://old.nabble.com/sub-package-tt28680783.html#a28680783) on outer forum. — milton, Apr 18 '12 at 21:42

William Pursell · Accepted Answer · 2012-04-25T12:43:07.430

The autotools are not really designed to be a package management system, so this is an awkward usage, but it is possible to reference relative paths outside of the build tree in the sub-projects. In other words, in subprojN/Makefile.am, you can add:

AM_CPPFLAGS = -I$(srcdir)/../subprojX/include
AM_LDFLAGS = -L$(srcdir)/../subprojX/lib

In this scenario, if subprojN/configure is trying to find libsubprojX, it will fail unless you instead add ../subprojX/{include,lib} to CPPFLAGS and LDFLAGS for configure, which can be done in configure.ac:

CPPFLAGS="$CPPFLAGS -I${srcdir}/../subprojX/include
LDFLAGS="$LDFLAGS -L${srcdir}/../subprojX/lib"

If the configure scripts of the subprojects are not checking for the libraries in the coupled subprojects, it would probably be cleaner to specify LDADD in Makefile.am to get the necessary libraries linked.

It has been suggested that the -L flags should reference `$builddir` rather than `$srcdir`, and I have some inclination towards that idea. However, this really won't work since the configure script will try to use things from the builddir before they are built. Of course, by the same argument, the configure script will try to link with libraries in the srcdir that may not exist yet...and this is why the auto-tools shouldn't be used as a package management system. Install the dependencies in /usr/local and stop worrying about these issues! — William Pursell, Dec 13 '16 at 22:52

score -1 · Answer 2 · answered Apr 20 '12 at 13:43

-1

CPPFLAGS and LDFLAGS should almost never be passed directly on the command line (personal opinion) but should be set in a config.site. Simply make the assignments in ${prefix}/share/config.site or in $CONFIG_SITE (ie, in the file $HOME/config.site and set CONFIG_SITE=$HOME/config.site in the environment in which you run configure) and that script will be sourced by all of your configure invocations. I'm not sure exactly what you mean by "keep these values inside autotool stuff", but it strikes me that using a config.site satisfies that. LDFLAGS and CPPFLAGS are the correct mechanism to tell your configure script the non-standard location of libraries, so any solution that does not use those would be outside the normal scope of the autotools. (Of course, the best solution is to install the libraries in a standard location so your toolchain can find them with no extra effort on your part. Perhaps you are using gcc and can set LIBRARY_PATH and CPATH.)

answered Apr 20 '12 at 13:43

William Pursell

204,365
48
270
300

The config.site seems nice, but I'd need to ship it to other people requiring to build the same components. – milton Apr 20 '12 at 14:49
By keeping stuff inside autotools, I mean not having to create something else than configure.ac and Makefile.am, like an autogen.sh script to pass the required flags. – milton Apr 20 '12 at 14:51
@milton--no, you do not need to ship it to people. Assume the user knows how to use their system. If they install libraries in standard location, they don't need to do anything. If they install in non-standard locations, they need to tell the configure script about that, and the normal way is via LDFLAGS/CPPFLAGS. There is nothing for the maintainer to do in you situation! – William Pursell Apr 23 '12 at 04:14
1

Perhaps I'm not making this question in a clear way. These sets of flags is required for declaring dependencies between the sub-projects, therefore it'll be distributed so the user does not have to figure out how to entangle and build them. – milton Apr 23 '12 at 19:45
1

Ah...I see the issue. This is a total kludge (but using the autotools as a package management system is a kludge!), but in subprojN/Makefile.am, you should be able to add "AM_CPPFLAGS = -I$(srcdir)/../../subprojX/include" – William Pursell Apr 23 '12 at 21:16
You're right, @WilliamPursell, that's an awkward purpose to dig in, but since all subpackages use autotools for building, it seemed ok to me to use the same technology to keep them properly together. Could you format the previous comment as an answer so I can mark it as a possible solution? At least until someone figure out a proper way to pass a ABS_TOP_TOP_SRCDIR variable from the inner configure.ac to the outer scripts. – milton Apr 24 '12 at 21:46

How can I propagate automake variables in a sub-package setup?

2 Answers2