> I've conceded defeat to bazel. I've lost interest in the battle but I wish > you luck if you wish to take it up...
My interest in bazel is the minimum necessary to get tensorflow-related projects working. FWIW, bazel 5 builds and works on macOS, but previous versions do not, and I strongly doubt whether any magic selection of compiler will get them to work: https://github.com/bazelbuild/bazel/issues/15876 My takeaway is to avoid any version prior to version 5 (implying that the existing MacPorts bazel state is both broken and obsolete), and that only if absolutely necessary previous versions can be obtained from binary downloads from github. Personally, I have also adopted the stance of avoiding bazel entirely unless absolutely necessary. > On Jul 14, 2022, at 05:54, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: > > Hi > >> On 13/07/2022 10:50 pm, Ryan Schmidt wrote: >>> On Jul 13, 2022, at 11:46, Steven Smith wrote: >>> How does one reconfigure the bazel Portfile to use a previous version of >>> clang that has a chance of working to build previous versions of bazel, >>> which are in turn necessary to build the tensor flow packages. >> If certain compilers that MacPorts might choose will not build a port, add >> their names to compiler.blacklist and MacPorts will choose another compiler. >> If you only want to exclude certain versions of a compiler (such as {clang < >> 700 >= 900}), include the compiler_blacklist_versions portgroup. >> If you've excluded all compilers MacPorts might choose, add a suitable >> compiler to compiler.fallback. > > This is all correct from the MacPorts side, but bazel is a different beast. > It goes out of its way to not use the 'standard' ways of selecting compilers > etc. That is why the bazel PG and portfile has all the convoluted logic it > does to try and enforce the MP choice. I know this logic is fragile, it > always has been. > > Personally, I've conceded defeat to bazel. I've lost interest in the battle > but I wish you luck if you wish to take it up... > > Chris
