${LDFLAGS} often contains additional (system) library directories that
also often contain old/already installed versions of the libraries to be
linked and are passed via ${{,FRAMEWORK_}LIBS}. While
${{,FRAMEWORK_}LIBS} pretty much always contains -Llocal_build_dir to
make the linker/compiler pick the newly built library for the later
referenced libraries, that location will be overridden and the build
system hence eventually tries to link against the old system library.
This issue is not seen often on Linux-based systems (since they don't
need to supply additional system library directories), but abundant on
others.
For instance, on macOS with MacPorts, LDFLAGS contains -L${prefix}/lib
(with /opt/local being the default prefix).
This leads to link calls such as these:
$LD ... -L${prefix}/lib ... -L../dependent_library -ldependent_library ...
which will, sadly, pick libdependent_library from ${prefix}/lib if the
software has been previously installed there.
Reordering both variables will lead to local library directories appear
earlier on the command line and hence have a higher priority, fixing the
issue.
* Recursively install framework headers, by adding and using a new
install-includes target.
* Install module.map if it exists.
* Don't include .framework in all target.
* Remove .frameworks with make clean.
gmake always includes files relative to the current directory, while
bmake includes them relative to the current Makefile - and current
Makefile means the current include. However, bmake has a variable
.CURDIR that always points to the current directory, but is missing in
gmake. Thus, .CURDIR is just set to "." if it's not set and always in
the include, thus making it work with both, bmake and gmake.
