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
