poor handling for `make install prefix=relative-path`

[Dan Bonachea]

Currently make install prefix=relative-path starts an installation and then fails horribly, leaving install directories littered inside the build tree.

autotools users probably know not to do this, but it's still an unfriendly behavior that could be avoided.

The top-level logic should check for this case and either issue an explanatory error or convert the prefix to an absolute path.

[Paul Hargrove]

UNtested:

--- a/bld/Makefile.rules
+++ b/bld/Makefile.rules
@@ -32,6 +32,10 @@ install-hook: force
         install_to="$(prefix)" install_common

 install install-opt install-debug: force
+       @if [[ ! '$(prefix)' =~ ^/ ]]; then \
+          echo 'ERROR: installation prefix must be an absolute path'; \
+          exit 1; \
+        fi
        @$(MAKE) -C $(BLDDIR) $@ || $(MAKE) failure TARGET=installation
        @$(MAKE) install-hook || $(MAKE) failure TARGET=installation
        @echo; \

[Paul Hargrove]

Improved version of the patch above now in pull request 192

[Paul Hargrove]

makefile: validate install prefix

This commit adds logic in Makefile.rules to validate the value of $(prefix) is an absolute path before recursing for any of the install targets.

Resolves issue 344: "poor handling for make install prefix=relative-path"

→ <<cset 82346c3f52e3>>