4

I have the following Autotools code for installing a systemd service file, which must be installed outside of $prefix to a directory given by a pkg-config variable:

(I know this is not proper, but I can't change the way systemd works.)

configure.ac

AC_ARG_WITH([systemdsystemunitdir],
    AS_HELP_STRING([--with-systemdsystemunitdir=DIR],
        [Directory for systemd service files]),
    [],
    [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)])
AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])

When you run make distcheck, your package gets installed into a temporary staging directory and then uninstalled. Since installing something outside of $prefix will break that, I must override the --with-systemdsystemunitdir configuration option for distcheck. I do it like so, since the location of the staging directory is available in the variable $dc_install_base. I can't pass an absolute path here, and $prefix or any other $prefix-derived variable such as $libdir will not be correct during the distcheck run itself.

Makefile.am

AM_DISTCHECK_CONFIGURE_FLAGS = \
    --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)

My question is twofold:

  • This feature ($dc_install_base) doesn't seem to be documented anywhere. Is it officially supported or an implementation detail? Usually Automake-private variables have two consecutive underscores in them, I believe.

  • Is there a better way to do what I'm trying to do? I know the Autotools way would be to set systemdsystemunitdir to a subdirectory of $prefix by default, and let the user or the distro override it. However, it's an important requirement to me that one should be able to extract the package from the tarball, run ./configure && make and sudo make install and have everything just work. If the systemd file were installed anywhere else besides the location given by pkg-config, it would not work, and what's more, fail silently.

ptomato
  • 56,175
  • 13
  • 112
  • 165
  • 1
    It's safe to say that if it isn't documented, then it isn't supported. The older a variable is, the less likely it is to use the "__" convention -- I certainly wasn't doing that in the old days. One question is why you would need this; the basic idea behind distcheck is that the testing simulates what a user would do; and in ordinary builds this isn't available. – Tom Tromey Oct 25 '15 at 16:19
  • I should have asked the question in the form of what I was trying to do. I will edit it to reflect that, thank you for the comment! – ptomato Oct 25 '15 at 17:50
  • @TomTromey Hopefully this has become a better and more answerable question now. – ptomato Oct 25 '15 at 18:06

1 Answers1

4

A bit late but...

I had a similar problem with gobject-introspection and I (hopefully) resolved by adding a couple of configure options and something like:

AM_DISTCHECK_CONFIGURE_FLAGS= \
    --with-girdir='$$(datadir)/gir-1.0' \
    --with-typelibdir='$$(libdir)/girepository-1.0'

In your case I think the following should work:

AM_DISTCHECK_CONFIGURE_FLAGS = \
    --with-systemdsystemunitdir='$$(prefix)/$(systemdsystemunitdir)'

The trick is that you must protect $(prefix) against two expansions: the make expansion (hence the double $$) and the shell expansion performed during the configure call (hance the single quotes).

ntd
  • 7,372
  • 1
  • 27
  • 44