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.