Hi,
The osmocom software that I do not install via apt but build myself gets
installed in $HOME/usr and I do things like:
export PATH="${PATH}:${HOME}/usr/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib"
export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig
MANPATH="${MANPATH}:${HOME}/usr/man"
Therefore I don't have to install to a destination outside my home
directory which in turn means I can avoid some sudo calls.
But that actually does not matter so much, you can mentally substitute
$HOME with '/' and append '/local' in the following if you want.
I don't install to $HOME/usr directly but use stow for 'managing' the
installations, so an installation goes like this:
$ mkdir -p $HOME/src/telco/osmo/libosmo-abis
$ cd $HOME/src/telco/osmo/libosmo-abis
$ git clone
git://git.osmocom.org/libosmo-abis
$ autoreconf -i
$ ./configure --prefix=$HOME/usr/stow/libosmo-abis
$ make
$ make install
$ STOW_DIR=$HOME/usr/stow stow libosmo-abis
This has two advantages:
* Good visibility of what is installed by a package.
$ tree $HOME/usr/stow/libosmocore
* Possibility of uninstalling a package even if the Makefile is not
present.
For me those two advantages outweigh the small additional effort of
using stow.
Because of that workflow I sometimes run into situations in which make
runs fail because either header files are not found during compilation
or libraries are not found during linking. The reason is that autotools
variables pointing to pkgconfig supplied directories point to a
destination under the prefix path with which configure was called. If a
dependency was not mentioned in a Makefile.am the required files are not
found because the other dependencies are in other directories.
For a system on which the osmocom-own dependency libs are installed in
distinct directories, current openbsc master HEAD requires the attached
patch for a build to succeed.
I admit that in most situations the dependencies are installed in the
same directory so this does not matter, but it is still a small bug.
Therefore I propose to modify the jenkins build scripts so that they use
distinct, stow managed directories for the dependencies. That should
help to detect oversights, although admittedly developers would have to
adapt their workflows to use stow as well in their daily hacking.
Otherwise an oversight would be detected by jenkings and not locally
which in turn would require additional cleanup commits which is not so
nice.
What is your gut feeling? Does the increased correctness of Makefiles.am
contents justify the (IMO rather small) additional effort of using stow?
Kind regards,
-Alex