2

I tend to build binaries from sources. My usual setup is the following

$HOME/build -> this gets the sources
$HOME/programs -> this is where the build happen, so where the binaries are

Once this is done I put the following in my bashrc

export MYNEWBINDIR = $HOME/programs/...
export PATH=$MYNEWBINDIR:$PATH

My question is: is it the recommended way ? For instance I could just create a local $HOME/bin, symlinks all the binaries there and just add it to the path...

Kusalananda
  • 333,661
statquant
  • 351

1 Answers1

8

It is more or less left up to the individual to do as they wish, but I would recommend that you leave directories already used by the base system or by any package manager alone, always. You really do not want to confuse a package manager by overwriting files that it has previously installed! So definitely leave /bin alone.

On most system, /usr/local should be a safe area for you to install things into, although this is also used by package managers on some systems (FreeBSD and OpenBSD for example, since they regard software installed from ports/packages as local software.

See also the entries "Filesystem Hierarchy Standard" and "Unix filesystem" at Wikipedia.

Some Unices also have a hier(7) manual that you may refer to. (The link goes to OpenBSD's version, but it's also available on at least Ubuntu amongst the Linuxes. In OpenBSD's case it documents the directories that system software is aware of, so it doesn't mention /opt, for example).

Where you build stuff doesn't really matter as it's a directory that you are likely to remove when you're done anyway. It's a good idea to do it away from the actual installation directories though. I've worked on systems that had source trees in /bin and /usr/local, which is just extremely untidy.

I'd also recommend that you do an actual make install for the software, rather than running the executables from within the build directory, unless you're tweaking the build. Collecting the executables in a single location makes your PATH cleaner and easier to set, unless you really want a distinct PATH element for each piece of software, obviously.


Personal opinion below:

For software that I build solely for myself, I tend to use a private hierarchy under $HOME/local for installations.

When compiling programs that uses the GNU autotools, and therefore has a configure script, this is really easy. You just say

$ ./configure --prefix="$HOME/local"

in the configuration stage, before make and make install.

When compiling programs that uses CMake, one can achieve the same by

$ cmake -DCMAKE_INSTALL_PREFIX="$HOME/local" .

before the make and make install steps. The same effect (by other means) may be had when installing Perl modules etc.

Then you'll obviously have to add $HOME/local/bin to your path...

Personally, I use GNU Stow too, which means I don't really specify $HOME/local as the installation prefix but $HOME/local/stow/thing-2.1 when I configure the sofware package thing-2.1.

After installing:

$ cd "$HOME/local/stow"
$ stow thing-2.1

The contents of the $HOME/local/stow/thing-2.1/bin directory will show up (using symlinks) in $HOME/local/bin (and similarly for any lib or other directory installed under thing-2.1).

Stow makes it really easy to uninstall software. No need to hunt down every little file that was installed by one make install just to uninstall and remove a piece of software, instead just

$ cd "$HOME/local/stow"
$ stow -D thing-2.1
$ rm -rf thing-2.1
Kusalananda
  • 333,661
  • OK good, so you suggest I do what I suggested, but using this stow utility... Does it deals with libs the same way? – statquant Jan 15 '17 at 22:32
  • @statquant Yes. Do read the documentation for it. – Kusalananda Jan 15 '17 at 22:49
  • As well as /usr/local, there is /opt both a way for admin to share stuff to other users. /opt uses a different layout than /usr/local, /opt is used for programs that are self contained (but usually bigger). – ctrl-alt-delor Jan 16 '17 at 12:46