[MacPorts] #64442: bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel
MacPorts
noreply at macports.org
Fri Jan 14 19:30:14 UTC 2022
#64442: bazel build points to builder directory
_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel
--------------------------------------------+-------------------------
Reporter: essandess | Owner: missa-prime
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.7.1
Resolution: | Keywords:
Port: bazel, py-tensorflow-metadata |
--------------------------------------------+-------------------------
Changes (by ryandesign):
* status: new => assigned
* owner: (none) => missa-prime
Comment:
The replacement of the unqualified "clang" and "clang++" in
wrapped_clang.cc with their full paths is being performed by the bazel 1.0
portgroup. The bazel 1.0 portgroup also requests the use of the
compiler_wrapper 1.0 portgroup, thus the full compiler paths are to
temporary wrapper scripts that are only valid for the duration of the port
build. The "bazel/bazel-3.7" part of the path you showed tells us this
path was generated while building the bazel-3.7 subport of the bazel port;
this path must be baked into the files installed by bazel-3.7 somewhere,
though I also cannot find it.
Regardless what compiler path is baked into bazel-3.7, it is wrong that
py-tensorflow-metadata is trying to use it. Ports must
[wiki:UsingTheRightCompiler use the compiler MacPorts tells them to use].
However, given all the other problems we already know about with bazel, it
would not surprise me if bazel makes it impossible to use the right
compiler. If that's the case, then bazel must not bake temporary compiler
paths into itself; it should bake in paths to compilers that are
guaranteed to exist, like /usr/bin/cc and /usr/bin/c++.
--
Ticket URL: <https://trac.macports.org/ticket/64442#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list