When I am installing a program with the make and make install method, there are (very often) many dependencies that need to be installed before the installation of the new program can begin. So currently, each time it gets to an error message that a dependency is missing, I install each of the dependencies manually.

I can see that make's man page doesn't list any simple option to go ahead and automatically install dependencies, so I am wondering if there is a workaround or a script to make that happen?

  • 2
    Makefiles, as part of a package, should be portable, but package installers are system specific. If you need to have dependencies installed for your package, it's likely that you need them even before compilation, not only before installation. So its a good manner to mention dependencies in README or INSTALL files of a package.
    – ikrabbe
    Jul 2, 2015 at 7:24
  • 1
    Depending on your OS/distribution, there may be a package management system that can help with this. For example, Debian and its distributions have auto-apt. Jul 2, 2015 at 7:42

1 Answer 1


That is not what makefiles are for. Makefile only handles building the software and installing it into the system in a generic way (without a package manager). It does not care (and should not care) if you have the requirements to actually run the application. That is by design. Consider several points:

1) If your distribution uses a package managers (almost all of them do in some way), you should not call make install directly anyway, because that bypasses the package manager and pollutes your system. In that case make install is called in a "sandbox" environment when you build the package, the installation gets packaged and the package is installed and handled by your package manager of choice.

2) There should be no requirement of installing everything in the "correct" order. In fact, this will most certainly lead to circular dependencies and it will be impossible to install. Even package managers usually get too strict about this which leads to problems. Also, when you are building a package (a buildscript calls make install), you actually don't intend to run the program and probably don't have the requirements installed anyway. You are after all just building a package that will be installed on some other computer.

3) There isn't a portable way of doing this. How will your make install which is by definition platform-independent, know where to look for the requirements (Hardwired urls or something? That would break in a second!). It cannot go through the package manager because it must run on all possibilities, including the future ones you haven't anticipated - also the versions change.

4) There isn't a one and only decision what to install. Shared libraries can be provided by different packages. There is more than one libc, even. And more than one package that provides OpenGL functionality (different graphics cards), different packages for matrix algebra, different libraries for media playback (vlc vs. gstreamer), and I could go on for ages. It's your choice how you design your systems and what components you use, it's the beauty of this modular design (instead of the old windows classic of putting everything on one CD/DVD, and thus having every library installed a thousand times by different packages, and gigabytes of installation for every application that shouldn't exceed 10MB with a sane design).

5) It's not the job of make install, it's a different level of maintenance. configure && make && make install handles checking what you have installed (for build-time dependencies), compiling the code and showing you where files should be put. Requirements on what versions of other software you need falls into the domain of packaging and distribution, which is a separate process -- the package manager, or the system admin if he installs things the traditional way. You should never mix these two concepts - it would lead to chaos. If things are separated into well defined layers, the developers can change things independent of the packagers and distribution maintainters: if the distro decides to repackage things with different names and use different alternatives, put things in different directories, they shouldn't expect the application developer, who takes care of the makefile, to know or care about this.

In short - no matter if the dependencies are build-time dependencies (without which the make cannot run - which is usually detected by the configure script), or the runtime dependencies, it shouldn't be done at the makefile level. Please don't do things the wrong way and consider the standards. If you are dealing with something that has no package yet (check the user-provided packages, it may be there already), you should investigate what is needed and actually build the package - it's better for others as well, who can then enjoy the package you made.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.