Description
Currently, the install paths for binaries, libraries, and all other fun stuff is balled up into a single data structure InstallDirs. This kind of makes sense, if you think you are installing a "package". But you're really not; you may be installing any combination of components associated with the package. From this perspective, having all of InstallDirs in a single data structure is hogwash.
The reason it is nonsensical is that the standard install paths substitution includes a variable for $ipid. Pray tell, what is this supposed to mean for non-library components? If you use $ipid in binpath, thinking that this will let you install multiple copies of an executable for different dependency resolutions, you're wrong: if the library dep resolves the same way the executables will all clobber each other (since this "ipid" is derived purely from the library).
Another piece of nonsense: currently, the code is organized around the idea that we install "packages". That's nonsense, sometimes you just want to install the components you, you know, actually built. (#2780) Our installation code should be organized on a per-COMPONENT basis. And if I'm installing an executable, why am I computing library paths again?
InstallDirs should be atomized into a set of data structures, one per component, and install/configure modified to keep them separate accordingly. We should report install paths on a per component basis, rather than assume that there's one said of paths that applies to the entire package.