Error when using make distcheck

[jerome hamm]

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.

My rules (leeched from the upower project) are the following:
<Makefile.am>
udevrules_DATA = \
95-evvgc.rules
<configure.ac>
# UDEV for device permission acces setting
AC_ARG_WITH([udevrulesdir],
AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev
rules]),
[],
[with_udevrulesdir=$($PKG_CONFIG --variable=udevdir
udev)"/rules.d"])
AC_SUBST([udevrulesdir], [$with_udevrulesdir])

Someone in the #autotools channel told that it should try to copy the files
in a subfolder of the test folder (not the system root).
What I also don't understand is why it doesn't work when I try fakeroot
make distcheck ...
What am I doing wrong?

I can send you the tarball if you need.

Cheers,
Jérôme.

[Peter Johansson]

Post by jerome hamm
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.
<Makefile.am>
udevrules_DATA = \
95-evvgc.rules
<configure.ac>
# UDEV for device permission acces setting
AC_ARG_WITH([udevrulesdir],
AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev
rules]),
[],
[with_udevrulesdir=$($PKG_CONFIG --variable=udevdir
udev)"/rules.d"])
AC_SUBST([udevrulesdir], [$with_udevrulesdir])
Someone in the #autotools channel told that it should try to copy the files
in a subfolder of the test folder (not the system root).
What I also don't understand is why it doesn't work when I try fakeroot
make distcheck ...
What am I doing wrong?

This sounds more like a question for the automake folks, but have you
read this section in the Automake manual:

http://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths

Cheers,
Peter

[Roger Leigh]

Post by Peter Johansson

Post by jerome hamm
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.
<Makefile.am>
udevrules_DATA = \
95-evvgc.rules
<configure.ac>
# UDEV for device permission acces setting
AC_ARG_WITH([udevrulesdir],
AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev
rules]),
[],
[with_udevrulesdir=$($PKG_CONFIG --variable=udevdir
udev)"/rules.d"])
AC_SUBST([udevrulesdir], [$with_udevrulesdir])
Someone in the #autotools channel told that it should try to copy the files
in a subfolder of the test folder (not the system root).
What I also don't understand is why it doesn't work when I try fakeroot
make distcheck ...
What am I doing wrong?

This sounds more like a question for the automake folks, but have
http://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths

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?


Regards,
Roger

[David A. Wheeler]

Post by jerome hamm
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.

Subject: Re: Error when using make distcheck

...

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,
- 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