[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_SUBST'ing foodir correctly?

From: Wouter Verhelst
Subject: Re: AC_SUBST'ing foodir correctly?
Date: Thu, 26 May 2016 16:31:07 +0200
User-agent: Mutt/1.6.0 (2016-04-01)

On Tue, May 24, 2016 at 06:11:47PM +0200, Mathieu Lirzin wrote:
> Wouter Verhelst <address@hidden> writes:
> > (if you need the full files, they're in the git repository at
> >
> This URL doesn't work for me.

Sorry, that should've been
(I typed it from memory, incorrectly as always :)

> > However, now my "make distcheck" fails, because the "make install"
> > target disregards DESTDIR and tries to install files in the actual
> > systemd unit directory, rather than the staging one. Clearly this means
> > I'm doing something wrong, but I'm not sure what the proper way for
> > doing this would be.
> ‘systemdsystemunitdir’ seems not affected by DESTDIR because IIUC
> PKG_CHECK_VAR set it to something like "/lib/systemd/system" instead of
> "${libdir}/systemd/system".
> I suppose it would work better to define it manually like
> this:
>   if SYSTEMD
>     systemdunitdir = $(libdir)/systemd/system
>     systemdunit_DATA = address@hidden
>   endif

Well. That would work, yes, but it wouldn't work *better*. The whole
point is that I do not want to hardcode such things, so that if a user
installs systemd units in </usr/local/brokenstuff/systemd> and the
pkg-config files are where they need to be, everything works as expected.

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?

< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

reply via email to

[Prev in Thread] Current Thread [Next in Thread]