in reply to local::lib & multiple architectures
I finally thought of a succinct way to say it ... ./configure
We’ve all seen “the miracle of automake” at work, where we see a bunch of messages like this one:
Checking to see if libxyzzy is installed ... yes.
... and what is actually happening here is that environment-specific decisions are being made on-the-fly to decide exactly how to build and then link this source-code package together, so that, in the end, It Just Works™ Everywhere. So, “the same C-language software,” when compiled on this machine vs. that one, might be of altogether different construction, and have an altogether different set of library dependencies, even though the resulting .dll or .so file-name is exactly the same.
Everybody, as far as I know, uses this or something like it. It all “just happens,” courtesy of CPAN, but you don’t necessarily know what each individual package-designer decided to do and you don’t want to have to care. Therefore, build on a “typical target” where automake can “see” whatever it needs to see and you don’t have to care exactly what it chooses to react to.