> > 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 <rleigh@xxxxxxxxxxxxx>
> To: autoconf@xxxxxxx, automake@xxxxxxx
> Subject: Re: Error when using make distcheck
> Message-ID: <20131120133621.GL13543@xxxxxxxxxxxxx>
...
> 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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
