Re: Error when using make distcheck

[David A. Wheeler]

> > On 11/20/2013 06:45 AM, jerome hamm wrote:
> > >Hi,
> > >
> > >I am trying to pack some software using udev rules, which therefore needs
> > >to copy some files to /lib/udev/rules.d.
> > >When I try and run make distcheck, at the step where it must  install the
> > >files in /lib/udev/rules.d it hopelessly fails because of permission 
> > >issues.

> From: Roger Leigh <address@hidden>
> To: address@hidden, address@hidden
> Subject: Re: Error when using make distcheck
> Message-ID: <address@hidden>
...
> This has been a bug in automake since forever, and a source of massive
> frustration.  The fix (to automake) is also very simple.
> 
> The assumption automake makes is that everything you want to install
> will go under the configured prefix.  While this is a nice ideal,
> reality isn't so simple.  Examples:
> - udev rules (as above)
> - pam configuration (similar)
> - nss modules
> - any third party loadable modules/plugins
> - cups printer drivers
> 
> All of the above have a common theme.  The software is installed into the
> configured prefix, but it also needs to integrate with other software
> which is /already installed into a different prefix/.  If I install it
> into my prefix then the other software won't be able to make use of it.
> Example: udev isn't going to look in /opt/mypackage/lib/udev/rules.d;
> it does need installing to /lib/udev/rules.d.
> 
> automake supports this just fine.  It's even already happening outside
> this special case if you configure with /usr as the prefix with
> /etc as sysconfdir--it's installing outside the prefix.  What's broken
> is just "distcheck"; if it set DESTDIR then it would work just fine.
> As it is, it overrides prefix in a broken way, causing the above
> problems.
> 
> In your specific case, because it overrides prefix, and you're not
> using prefix in your install path, it still tries to use the full
> path.  If it used DESTDIR correctly, it would be able to install it
> into a staging directory without trouble.
> 
> I've now encountered this in a number of projects, for all of the above
> example reasons.  In all cases the project built and distributed fine
> but failed distcheck, and our only choice was to not use distcheck.
> I've brought the issue up on this list a couple of times, and both times
> I was told that what I was doing wasn't supported and was buggy.  BUT...
> the important point here is that automake is clearly not supporting the
> above use cases, so is falling short of the real needs of many projects.
> Can't we just fix distcheck to use DESTDIR when doing the test install
> and move on?

I'd like that fixed in automake, but in the meantime,
here's how I handle it... and this solution is *autoconf* related
(so we're in the right mailing list for a change :-) ).

Basically, in configure.ac, determine if you're doing "make distcheck"
by seeing if $prefix contains "/_inst".  Here's code for configure.ac:

# Is this a normal install, or a "make distcheck"?  We need to disable
# the tests in a "make distcheck" that won't work.
is_make_distcheck=no
AS_CASE([$prefix],
  [*/_inst],
    [AC_MSG_NOTICE([[Prefix ends in /_inst; this is a 'make distcheck'.]])
     is_make_distcheck=yes])
AM_CONDITIONAL([IS_MAKE_DISTCHECK], [is_enabled "$is_make_distcheck"])
AC_MSG_CHECKING([final decision IS_MAKE_DISTCHECK (running "make distcheck"?)])
AM_COND_IF([IS_MAKE_DISTCHECK], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no])])


Then in Makefile.am, disable the tests if IS_MAKE_DISTCHECK is true, e.g.:

# The installchecks won't work in a "make distcheck", because
# they won't be installed in the final location used by the tools.
if IS_MAKE_DISTCHECK
installcheck-local:
        echo "Running 'make distcheck'; local installchecks disabled."
else !IS_MAKE_DISTCHECK
installcheck-local: installcheck-clisp installcheck-guile
endif !IS_MAKE_DISTCHECK


Yes, it's awkward, but it works.  Then "make distcheck" works as intended.

--- David A. Wheeler