Manually patch binaries to fix macOS native builds

[connorworley]

This isn't the prettiest, but it demonstrates a potential fix for macos using install_name_tool.

[connorworley]

I think I can refactor this to avoid the extra copy step on non-macOS platforms

[connorworley]

I think it probably is a bazel problem (something to do with cc_library vs cc_import) but I don't really know how to fix it. Maybe we can run with this approach and revisit the problem later.

[noamzaks]

In that case, I think it would be better to replace our use of cc_library to cc_imports.

I tried to do so, but:

• The cc_library_shared definition in deps_utils needs to replace cc_library with filegroup I think, so that later it can be used in cc_import of a library stub like so:

  cc_import(
  name = "visa",
  shared_library =
      "@__bazelrio_edu_wpi_first_ni-libraries_visa_linuxathena//:shared_libs",
  visibility = ["//visibility:public"],
  )

• I think the above breaks some of our custom digging into the CcInfo's, but more importantly
• For libraries like OpenCV which have a bunch of .sos the above filegroup needs to split into many targets, and then we can create a cc_import definition for each one (And a cc_library which pulls them all together)

Consequently, I think our options for achieving this are:

• Create our own mirror for all of the built artifacts but in the form of raw files instead of archives like Artifactory/Maven provides. I think we can just make the generate_dependencies script also generate a directory with all of the library and header zips and then use something like GitHub Pages to host it (Something like /opencv/4_5_2_1/gapi/library.so.zip and /opencv/4_5_2_1/headers.zip)
• Make each dependency have it's own build file contents and be careful because opencv for instance has different versions across years which cause different .so names

I'm in favor of the first option.

I think kicking this can down the road can cause more issues and make the project less readable, but at the same time, simulation on macOS is definitely a required feature, so I leave it to you guys to decide about merging this.

[noamzaks]

On second thought, after testing on https://github.com/noamzaks/bazel-test-cpp-library

I think cc_import might also be bugged on macOS...

dyld[96783]: Library not loaded: libfoo.so
  Referenced from: /private/var/tmp/_bazel_noamzaks/347e8076471125fc8ec55128ba990c2f/execroot/__main__/bazel-out/darwin_arm64-fastbuild/bin/main
  Reason: tried: 'libfoo.so' (no such file), '/usr/local/lib/libfoo.so' (no such file), '/usr/lib/libfoo.so' (no such file), '/private/var/tmp/_bazel_noamzaks/347e8076471125fc8ec55128ba990c2f/execroot/__main__/bazel-out/darwin_arm64-fastbuild/bin/main.runfiles/__main__/libfoo.so' (no such file), '/usr/local/lib/libfoo.so' (no such file), '/usr/lib/libfoo.so' (no such file)

[connorworley]

https://github.com/bazelbuild/bazel/issues/7415 seems relevant