Re: AC_SUBST'ing foodir correctly?

[Mike Miller]

On Thu, Jun 23, 2016 at 15:18:51 +0200, Wouter Verhelst wrote:
> Please remember that I'm installing a file for systemd to use, not a
> file for nbd to use (in this particular case it's a systemd
> configuration file, but it could equally well have been a plugin, or an
> extension, or whatever).

I have run across this dilemma several times in my use of automake. Yes,
this is a recurring tension between automake's $(prefix)-rooted design
philosophy and the practical need to install a file in another project's
configuration directory or namespace.

> > > I was under the impression that automake looks at DESTDIR for every
> > > foodir it looks at, but apparently that's not the case then? That seems
> > > broken; after all, I don't think a staging directory should depend on
> > > whether or not something was part of a given prefix. Is there any
> > > explanation available somewhere on why this behaviour occurs? Would a
> > > patch that changes this behaviour be acceptable?

I think the point is that automake by design expects both that every
file will be installed under $(prefix) by default *and* that $(DESTDIR)
will be respected if defined.

You can of course choose to break either one or both of those
assumptions, but then other features of automake may break, such as the
'distcheck' target.

> > Every default installation directories are expected to be subdirectories
> > of the 'prefix' variable.  This is verified by ‘make distcheck’ and
> > specified in GNU coding standards:
> > 
> >   
> > https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables
> > 
> > So it is unlikely that a patch is going to be accepted in Automake.
> 
> Not even for the --foreign mode of automake?

I can't speak for the automake maintainers, but to me this seems like a
different class of incompatibility than what --foreign covers.

> > However I guess the default pkg-config file could be fixed in Systemd.
> 
> That would mean the nbd build will break for everyone who did a
> non-default build of systemd... not a very attractive proposal.

IMHO the best way to address this is to configure your project
differently for 'distcheck' from a typical system install. We already do
this for every autotools-based project that uses $(sysconfdir).

One way would be to defer the "correct" definition of $(systemdunitdir)
until the sysadmin installs it or the deb or rpm package is built. Your
default build could define it to be rooted anywhere under $(prefix), and
it would be up to the caller of 'make install' to override as needed.
This is pretty simple, but also easy to forget.

Another way would be to default $(systemdunitdir) as you have it, and
require that 'make distcheck' is called with a command-line override
based on $(prefix) so that it passes. Also simple, but the only one who
needs to remember it is the maintainer running 'distcheck'.

If automake supported something like a $(AM_DISTCHECK_MAKEFLAGS)
variable, that might make the latter option a little easier.

A third option might be to either reuse your --enable-systemd option or
add a different AC_ARG_ENABLE option to select whether the value of
$(systemdunitdir) is rooted in $(prefix) or comes straight from
systemd.pc. Specifically, something like

  ./configure --disable-systemd        ## not installed
  ./configure --enable-systemd=system  ## installed in /lib/systemd
  ./configure --enable-systemd=rooted  ## installed in $(libdir)/systemd
  ./configure --enable-systemd         ## choose your favorite default

One advantage of using a configure option over a makefile variable
override is that there *is* a $(AM_DISTCHECK_CONFIGURE_FLAGS), so you
can encode exactly how 'make distcheck' differs from a default build, if
that's what you want.

HTH,

-- 
mike