workspace: hard code paths instead of using pkg-config

[jamiesnape]

pkg-config files are frequently broken since they are (unfortunately) rarely tested by upstream projects and are frequently patched by distribution packagers. On Focal, libjpeg.pc and yaml-cpp.pc are broken at release, while on Mac, numerous files are broken on an ongoing basis. We only support three configurations, so hard coding paths is not a huge deal at this time.

[EricCousineau-TRI]

If possible, I would like to request that hard-coded paths be hoisted to top-level constants, easy to discover if possible, and easy to hack with (with standard disclaimer of at-your-own-risk).

That seems to be the case presently, just wanted to make sure I formulated the request.

Example workflow:
#13027 (comment)

[jwnimmer-tri]

Would a local_repository_override parameter meet the need? That would allow for a certain uniformity across different rule types.

Example for github archives:

drake/tools/workspace/github.bzl

Lines 40 to 43 in 6a068e3

	local_repository_override: optional local repository override can be
	used for temporary local testing; instead of retrieving the code
	from GitHub, the code is retrieved from the local filesystem path
	given in the argument.

[EricCousineau-TRI]

I think so, as long as it can affect all occurrences of the Python interpreter; I'm guessing you could do that by generating a Skylark file with that macro, and then pull it back out?

[jwnimmer-tri]

Ah, I see now. I think you are talking about python interpreter paths, not pkg-config paths. This issue is just about pkg-config.

However, I think you're right in any case that if more info about the python interpreter ends up being hard-coded, we should be sure there's a mechanism to adjust it for experimentation. But I think as long as we follow DRY like we usually do, the places to adjust for experimentation will be few.

[EricCousineau-TRI]

Sounds good. Sorry to clutter the scope, just hopped through the philosophical link from #13400.
Thanks!

[jwnimmer-tri]

After #17231 wraps up, we will be using much less via pkg-config. What remains will be approximately this:

eigen
fmt
glew
glib
blas
lapack
spdlog
x11
zlib

I think those will be sufficiently safe to leave alone without much risk.