[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_SUBST'ing foodir correctly?
Re: AC_SUBST'ing foodir correctly?
Mon, 27 Jun 2016 14:35:53 -0700
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
> > 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.