Good Practices: Compiling from Source #3

In my first post, I wrote about the configuration step in compilation. In my last post, I wrote about the compile step. This post is about the last step, installation.

Rubber Hits the Road

You’ve configured and compiled your project, and all the files that the project needs to run are built and ready to be used. They’re in the build directory after the compile, and need to be put in the filesystem the right way.
For example, if you built a command line executable, it has to be put somewhere where the default $PATH variables can find the executable. It also has to put any libraries it needs in a place where they can be found when the executable runs. These are very particular places, and the install command knows where to put these.

You can install the projects via running:
make install
Likely though, you’re installing to directories that are owned by root, so you might have to do
sudo make install
to get the right permissions.

If your plan is to just install this one custom program, and then never, ever compile another program again, then you’re pretty much done. You can run the program and see if it works now! However, if you plan on compiling a lot of programs, I advise taking a more complicated and flexible approach.

Conquering Chaos

The problem with using “make install” with all the default system directories is that it gets too chaotic too fast if you’re installing dozens upon dozens of custom sources. When you do make install, it can scatter dozens of files accross your filesystem (usually in the standard places for things). If you’re installing dozens of things from source, with dozens of installed files per project, you’ll soon end up with hundreds of files in your filesystem that your package manager doesn’t know about!

Now, if you’ve been doing this for years and years, you’ll end up with a huge amount of old files on your systems, and you never know when you might accidentally use a super old file. Also, you might want to delete a file, but won’t be able to remember where its from or what it does. You should keep the chaos on your system to a minimum, and this takes some careful practice.

What I generally try to do, is leave the standard directories alone, and just let my package manager manage them. If I compile something myself, I will put it in a special folder (a “Kevin-Compiled” folder, if you will), where its easy to keep track, ( and delete ) things I compiled myself if I ever need to. It also makes it easier to monitor the project that you are working on. To give an example, if I install ‘libusb-dev’ for my development via apt-get, I will let my package manager keep track of the files, and upgrade it if necessary. If I compile the source for ‘libusb’ myself, then I will usually install it to /opt/libusb. (some people prefer /usr/local/ to /opt, but /opt is less typing, so thats what I use 😀 )

Advantages of /opt

  1. If I totally and absolutely screw up an installation of the source I was compiling, recovering from my mistake is as simple as “rm -rf /opt/*” and then re-running the “make install” from the source directories I was working on. If you install to the standard directories, you may not be able to figure out what exactly the install did to your system, and (in extreme cases) could force you to reinstall your whole root partition!
  2. With some clever scripting, you can configure your entire system to run in ‘development mode’ (eg, prefer the libraries in /opt) and then easily switch back to running in ‘normal mode’, by preferring all the libraries that are installed by default by the package manager. If you’re partway through developing something (say, the X server) and its not working, you can always switch modes and get proper functionality back.
  3. You can chown /opt to yourself, and never have to run ‘sudo make install’, you can just run ‘make install’. Its better if you never have to escalate permissions to do a simple development test.
  4. You never overwrite a file that is managed by the package manager. If you have libusb installed by the package manager, and then make install the libusb libraries over the ones installed by the package manager, you’ve overwritten the known-working versions of this library! You’ll have to uninstall that package and reinstall it to get the working version back.
  5. You can see all the files installed by a make install very easy. You can just navigate to /opt, and do “find .” and see each and every file installed by that library! This makes them easy to delete or modify in other ways.

Disadvantages of /opt

  1. This can be difficult to set up, as it takes a fair amount of knowledge concerning how the linker work, how the $PATH variable works, etc.
  2. Its somewhat tedious to manage things this way.
  3. Its oftentimes an extra step to figure out how to instruct the build system to install to “/opt” instead of to “/”. In some frustrating situations, I’ve seen the install directory option even ignored. Most the time this is a simple extra command during the configure.
  4. Sometimes, you can’t cleanly install everything to /opt. For various reasons, sometimes things are hard-coded to your standard paths, and it might take you a second look to figure out why things arent working.
I use the /opt installation, because it mitigates damage, and is worth the setup cost to me because I hardly ever do fresh installs. I’ll blog later about how specifically to set up your system like this well!

Conclusion

I’ve walked through a lot of common problems during the compilation from source that I’ve had to figure out ways to avoid. I’m hoping that this will either help you install things from source by yourself, without forums and wikis, more often, and more easily. Happy coding!

This entry was posted in Coding, Open Source, Ubuntu. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *