Are there shell equivalents to PREFIX etc.?

[Andy Falanga (afalanga)]

My question is, I hope, quite simple. I have a case where I made some
distribution, installation and uninstall hooks in my Makefile.am:

|EXTRA_DIST = setupenv.sh bootstrap tests dist-hook: rm -rf $$(find
$(distdir)/tests -name \*.swp -o -name \*.pyc) install-exec-hook: mkdir
-p $(prefix)/unit_tests/unittest2 for f in tests/*.py; do \ cp $$f
$(prefix)/unit_tests; \ done for f in tests/unittest2/*.py; do \ cp $$f
$(prefix)/unit_tests/unittest2; \ done uninstall-hook: rm -r
$(prefix)/unit_tests |

Ordinarily, this works just fine. However, when building the RPM for
this software, the prefix is set to an alternative location in /opt. I
would have thought that the rules I've written would have worked with
the RPM build system. This isn't quite the case though. When executing
my install hook, the mkdir command fails because the common user doesn't
have permissions to make directories in /opt/..... .

The RPM system, if you're not familiar, "localizes" the installation in
that is makes the install process into to a faux location, usually
~/rpmbuild/BUILDROOT. So, in this case, this would be
~/rpmbuild/BUILDROOT/opt/..... . Is there a means of re-writing the
rule that I have for installation/uninsta

[Nick Bowler]

Hi Andy,

(Note that your mailer seems to have completely mangled all whitespace,
particularly the newlines, in your make snippet. This makes it very
hard to read. I have tried to manually correct it in the quoted text).

Post by Andy Falanga (afalanga)
My question is, I hope, quite simple. I have a case where I made some
EXTRA_DIST = setupenv.sh bootstrap tests
rm -rf $$(find $(distdir)/tests -name \*.swp -o -name \*.pyc)
mkdir -p $(prefix)/unit_tests/unittest2
for f in tests/*.py; do \
cp $$f $(prefix)/unit_tests; \
done
for f in tests/unittest2/*.py; do \
cp $$f $(prefix)/unit_tests/unittest2; \
done
rm -r $(prefix)/unit_tests
Ordinarily, this works just fine. However, when building the RPM for
this software, the prefix is set to an alternative location in /opt. I
would have thought that the rules I've written would have worked with
the RPM build system. This isn't quite the case though. When executing
my install hook, the mkdir command fails because the common user doesn't
have permissions to make directories in /opt/..... .

I suspect your immediate problem is simply that your rules are not
respecting ${DESTDIR}. See the Automake manual, section 12.4 "Staged
Installs"[1]. The RPM packager is almost certainly using this feature,
so you need to support it. "make distcheck" tries to check that your
package properly supports this function, and probably would have caught
this issue.

Basically, all filenames that point to installed file locations must
start with ${DESTDIR}, for example:

install-exec-hook:
mkdir -p ${DESTDIR}${pkgdatadir}/foo
cp ${srcdir}/file1 ${DESTDIR}${pkgdatadir}/foo

Fixing this is probably enough to make the RPM packager happy.

Note that your rule should most likely also specify ${srcdir} on the
source filename (unless these are generated files), otherwise VPATH
installations may fail (distcheck should catch this too).

As an aside, packages generally should not install files directly in
${prefix}; consider defining a separate directory variable, such as:

unittestdir = ${prefix}/unit_tests

Finally, these files look to me like they really belong in a
package-specific installation directory by default, such as:

unittestdir = ${pkglibexecdir}/unit_tests

[1] https://gnu.org/software/automake/manual/automake.html#Staged-Installs

Hope that helps,
Nick

[Andy Falanga (afalanga)]

Post by Nick Bowler
Hi Andy,
(Note that your mailer seems to have completely mangled all whitespace,
particularly the newlines, in your make snippet. This makes it very
hard to read. I have tried to manually correct it in the quoted text).
I suspect your immediate problem is simply that your rules are not
respecting ${DESTDIR}. See the Automake manual, section 12.4 "Staged
Installs"[1]. The RPM packager is almost certainly using this feature,
so you need to support it. "make distcheck" tries to check that your
package properly supports this function, and probably would have caught
this issue.

This was indeed the problem. Until now, I didn't realize that DESTDIR
was an autotools "thing". I saw its use in the process used by this
team (predates my introduction), but thought it was a "tribal knowledge"
application. I now recall reading about DESTDIR when I first schooled
myself on Autotools, but since I hadn't used it before now, it was
subtly disregarded.

Thank you much for this information.

Andy

P.S. thanks for the note on my mailer.