Re: bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel
> On 14 Jan 2022, at 3:14 am, Steven Smith 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//embedded_tools/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/
bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel
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//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?
smime.p7s
Description: S/MIME cryptographic signature
Re: Question regarding supported_archs noarch
On 2022-1-14 04:12 , Jason Liu wrote: Hi all, A hopefully quick and simple question regarding 'supported_archs noarch'. Is 'noarch' meant to specify that the build itself isn't supposed to be architecture-specific, or does it mean that the final output products are not architecture-specific? Strictly speaking it refers to the installed files, but it's pretty unusual to require specific archs during build but only install noarch files. (BTW, not installing any Mach-O files doesn't guarantee that a port is noarch - it's possible to have architecture-specific information in other file types.) I have a subport that basically runs through the entire build, including compiling the source code, but then in the end simply throws away those compiled objects, and the only files that are retained (i.e. staged into destroot) are the game data files, which are basically just a bunch of text files and images (which are not architecture-specific). It seems that the upstream developers wrote the makefiles this way because some of the game data files get generated during the compile process, and they never bothered to cleanly split off the generating of the game data files into a separate makefile that can be run by itself. Whether this would work with the subport marked noarch depends on the build system and its dependencies. If it links with external libraries, not having them available for the right archs could certainly make the build fail (pointlessly, since the file failing to link won't be installed). That may be an uncommon case, but the best idea would be to see if there's a different Makefile target you can run that just builds and installs the data, and if not, maybe add one. - Josh
Question regarding supported_archs noarch
Hi all, A hopefully quick and simple question regarding 'supported_archs noarch'. Is 'noarch' meant to specify that the build itself isn't supposed to be architecture-specific, or does it mean that the final output products are not architecture-specific? I have a subport that basically runs through the entire build, including compiling the source code, but then in the end simply throws away those compiled objects, and the only files that are retained (i.e. staged into destroot) are the game data files, which are basically just a bunch of text files and images (which are not architecture-specific). It seems that the upstream developers wrote the makefiles this way because some of the game data files get generated during the compile process, and they never bothered to cleanly split off the generating of the game data files into a separate makefile that can be run by itself. -- Jason Liu
