bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel

[Steven Smith]

Thanks. Please see https://trac.macports.org/ticket/64442.

> On Jan 14, 2022, at 08:30, Christopher Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> 
> 
> please open a trac ticket and we will discuss there. better than a mailing list.
> 
>> On 14 Jan 2022, at 11:55 am, Steven Smith <steve.t.smith at gmail.com> wrote:
>> 
>> Chris, Thanks, and concur on the wonderfulness of bazel.
>> 
>> To be clear, I am not building bazel-3.7 here. I am building py38-tensorflow-metadata, which uses bazel-3.7. I’ve attached the log file. It was produced with a build (please see attached Portfile) that adds `bazel.build_opts-append --sandbox_debug`, not that I see that helping a diagnosis.
>> 
>> FWIW, I looked in the binary /opt/local/libexec/bazel-3.7/bin/bazel for the string “_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel” but it’s not there, at least not in plain text. I have no idea how this path is being introduced at the build stage. 
>> 
>> 
>> Attachments:
>> <main.log.xz>
>> <Portfile>
>> 
>> 
>> 
>>>> On Jan 14, 2022, at 2:52 AM, Christopher Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>> 
>>>> 
>>> 
>>>> On 14 Jan 2022, at 3:14 am, Steven Smith <steve.t.smith at gmail.com> wrote:
>>>> 
>>>> I’m trying to build/update py-tensforflow-metadat and am hitting this (bizarre) bazel issue.
>>>> 
>>>> First, the build fails with the error:
>>>> 
>>>>> :info:build Execution platform: @local_config_platform//:host
>>>>> :info:build Use --sandbox_debug to see verbose messages from the sandbox
>>>>> :info:build xcrun: error: can't exec '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc' (errno=No such file or directory)
>>>> 
>>>> 
>>>> Weird that bazel wants to look in a MacPorts build directory.
>>>> 
>>>> Searching for this string in ${worksrcpath}, it appears in the file created during the build stage:
>>>> 
>>>> ${worksrcpath}/bazel_build/install/<hash>/embedded_tools/tools/osx/crosstool/wrapped_clang.cc:
>>>> 
>>>>>   if (binary_name == "wrapped_clang_pp") {
>>>>>     tool_name = "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cxx";
>>>>>   } else if (binary_name == "wrapped_clang") {
>>>>>     tool_name = "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc";
>>>> 
>>>> This is not the file from https://github.com/bazelbuild/bazel/blob/master/tools/osx/crosstool/wrapped_clang.cc
>>>> 
>>>> I’m stumped. Does anyone have insight on what’s causing this weird bazel build issue?
>>>> 
>>> 
>>> The above is intentional, and performed by the bazel build to (attempt) to work around issues with the bazel build on older systems, which is spectacularly difficult to work with . Specifically see
>>> 
>>> https://github.com/macports/macports-ports/blob/6569ac3bcc84a00f72513d0f8ceebb6b6cec1576/devel/bazel/Portfile#L259
>>> 
>>> why you see the above I cannot say. Please also post a complete log, not just snippets like above.
>>> 
>>> is there a specific reason you are building bazel-3.7 from source ? binary tarballs are availing for 10.11 and newer
>>> 
>>> https://ports.macports.org/port/bazel-3.7/details/
>>> 
>>> Chris
>>> 
>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220114/14ed33bd/attachment-0001.htm>