1
hermetic_cc_toolchain/toolchain/defs.bzl

336 lines
12 KiB
Python
Raw Normal View History

2021-04-10 01:05:01 +03:00
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("@bazel_tools//tools/build_defs/repo:utils.bzl", "read_user_netrc", "use_netrc")
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
load("@bazel-zig-cc//toolchain/private:defs.bzl", "target_structs", "zig_tool_path")
# Directories that `zig c++` includes behind the scenes.
_DEFAULT_INCLUDE_DIRECTORIES = [
"libcxx/include",
"libcxxabi/include",
"libunwind/include",
]
2021-04-10 01:05:01 +03:00
_fcntl_map = """
GLIBC_2.2.5 {
fcntl;
};
"""
_fcntl_h = """
#ifdef __ASSEMBLER__
.symver fcntl64, fcntl@GLIBC_2.2.5
#else
__asm__(".symver fcntl64, fcntl@GLIBC_2.2.5");
#endif
"""
2022-01-25 11:05:35 +02:00
# Official recommended version. Should use this when we have a usable release.
URL_FORMAT_RELEASE = "https://ziglang.org/download/{version}/zig-{host_platform}-{version}.{_ext}"
2022-01-25 11:05:35 +02:00
# Caution: nightly releases are purged from ziglang.org after ~90 days. A real
# solution would be to allow the downstream project specify their own mirrors.
# This is explained in
# https://sr.ht/~motiejus/bazel-zig-cc/#alternative-download-urls and is
# awaiting my attention or your contribution.
URL_FORMAT_NIGHTLY = "https://ziglang.org/builds/zig-{host_platform}-{version}.{_ext}"
2022-01-25 11:05:35 +02:00
# Author's mirror that doesn't purge the nightlies so aggressively. I will be
# cleaning those up manually only after the artifacts are not in use for many
# months in bazel-zig-cc. dl.jakstys.lt is a small x86_64 server with an NVMe
# drive sitting in my home closet on a 1GB/s symmetric residential connection,
# which, as of writing, has been quite reliable.
URL_FORMAT_JAKSTYS = "https://dl.jakstys.lt/zig/zig-{host_platform}-{version}.{_ext}"
_VERSION = "0.10.0-dev.4301+uber2"
_HOST_PLATFORM_SHA256 = {
"linux-aarch64": "3c7011445567160e7fdf9b015f298c04fcbdf48ae6df14b198eb262425419cf3",
"linux-x86_64": "1f939605dea8786200b40e3b2518d10a26c698039200a4ce55b6f2e5ec42e348",
"macos-aarch64": "48633c4c4ab8b77ba2332f9e4840cde89efc6288887ed36b31f38e4e978ed519",
"macos-x86_64": "5d4067ec2670bc103a1b0f00faf633aa605ef377e1f94616f89e4913ffe7f91e",
"windows-x86_64": "b6570086dc0dd44ed886d4e8de499a879fb5885d60526523461c663181e2ae81",
2022-05-29 19:35:16 +03:00
}
_HOST_PLATFORM_EXT = {
"linux-aarch64": "tar.xz",
"linux-x86_64": "tar.xz",
"macos-aarch64": "tar.xz",
"macos-x86_64": "tar.xz",
"windows-x86_64": "zip",
}
def toolchains(
version = _VERSION,
url_formats = [URL_FORMAT_NIGHTLY, URL_FORMAT_JAKSTYS],
2022-05-29 19:35:16 +03:00
host_platform_sha256 = _HOST_PLATFORM_SHA256,
host_platform_ext = _HOST_PLATFORM_EXT):
"""
Download zig toolchain and declare bazel toolchains.
The platforms are not registered automatically, that should be done by
the user with register_toolchains() in the WORKSPACE file. See README
for possible choices.
"""
2021-04-10 01:05:01 +03:00
zig_repository(
name = "zig_sdk",
version = version,
url_formats = url_formats,
host_platform_sha256 = host_platform_sha256,
2022-05-29 19:35:16 +03:00
host_platform_ext = host_platform_ext,
host_platform_include_root = {
"linux-aarch64": "lib/zig",
"linux-x86_64": "lib",
"macos-aarch64": "lib",
"macos-x86_64": "lib/zig",
"windows-x86_64": "lib",
2021-06-16 12:44:16 +03:00
},
2021-04-10 01:05:01 +03:00
)
_ZIG_TOOLS = [
"c++",
"cc",
"ar",
"ld.lld", # ELF
"ld64.lld", # Mach-O
"lld-link", # COFF
"wasm-ld", # WebAssembly
2022-11-17 15:47:46 +02:00
"build-exe", # zig
"build-lib", # zig
"build-obj", # zig
]
_ZIG_TOOL_WRAPPER_WINDOWS_CACHE_KNOWN = """@echo off
if exist "external\\zig_sdk\\lib\\*" goto :have_external_zig_sdk_lib
set ZIG_LIB_DIR=%~dp0\\..\\..\\{zig_include_root}
goto :set_zig_lib_dir
:have_external_zig_sdk_lib
set ZIG_LIB_DIR=external\\zig_sdk\\{zig_include_root}
:set_zig_lib_dir
set ZIG_LOCAL_CACHE_DIR={cache_prefix}\\bazel-zig-cc
set ZIG_GLOBAL_CACHE_DIR=%ZIG_LOCAL_CACHE_DIR%
"{zig}" "{zig_tool}" {maybe_target} %*
"""
_ZIG_TOOL_WRAPPER_WINDOWS_CACHE_GUESS = """@echo off
if exist "external\\zig_sdk\\lib\\*" goto :have_external_zig_sdk_lib
set ZIG_LIB_DIR=%~dp0\\..\\..\\{zig_include_root}
goto :set_zig_lib_dir
:have_external_zig_sdk_lib
set ZIG_LIB_DIR=external\\zig_sdk\\{zig_include_root}
:set_zig_lib_dir
if exist "%TMP%\\*" goto :usertmp
set ZIG_LOCAL_CACHE_DIR=C:\\Temp\\bazel-zig-cc
goto zig
:usertmp
set ZIG_LOCAL_CACHE_DIR=%TMP%\\bazel-zig-cc
:zig
set ZIG_GLOBAL_CACHE_DIR=%ZIG_LOCAL_CACHE_DIR%
"{zig}" "{zig_tool}" {maybe_target} %*
"""
_ZIG_TOOL_WRAPPER_CACHE_KNOWN = """#!/bin/sh
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
set -e
if [ -d external/zig_sdk/lib ]; then
ZIG_LIB_DIR=external/zig_sdk/{zig_include_root}
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
else
ZIG_LIB_DIR="$(dirname "$0")/../../{zig_include_root}"
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
fi
export ZIG_LIB_DIR
2022-08-29 14:44:38 +03:00
export ZIG_LOCAL_CACHE_DIR="{cache_prefix}/bazel-zig-cc"
export ZIG_GLOBAL_CACHE_DIR="{cache_prefix}/bazel-zig-cc"
2022-10-01 18:53:38 +03:00
{maybe_gohack}
exec "{zig}" "{zig_tool}" {maybe_target} "$@"
"""
2021-08-05 09:47:34 +03:00
_ZIG_TOOL_WRAPPER_CACHE_GUESS = """#!/bin/sh
set -e
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
if [ -d external/zig_sdk/lib ]; then
ZIG_LIB_DIR=external/zig_sdk/{zig_include_root}
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
else
ZIG_LIB_DIR="$(dirname "$0")/../../{zig_include_root}"
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
fi
if [ -n "$TMPDIR" ]; then
_cache_prefix=$TMPDIR
elif [ -n "$HOME" ]; then
if [ "$(uname)" = Darwin ]; then
_cache_prefix="$HOME/Library/Caches"
else
_cache_prefix="$HOME/.cache"
fi
2021-06-10 09:10:48 +03:00
else
_cache_prefix=/tmp
2021-06-10 09:10:48 +03:00
fi
export ZIG_LIB_DIR
2021-08-05 09:47:34 +03:00
export ZIG_LOCAL_CACHE_DIR="$_cache_prefix/bazel-zig-cc"
2021-06-10 09:10:48 +03:00
export ZIG_GLOBAL_CACHE_DIR=$ZIG_LOCAL_CACHE_DIR
2022-10-01 18:53:38 +03:00
{maybe_gohack}
exec "{zig}" "{zig_tool}" {maybe_target} "$@"
"""
# The abomination below adds "-O2" to Go's link-prober command. Saves around
# 25s for the first compilation for a particular architecture. Can be deleted
# if/after https://go-review.googlesource.com/c/go/+/436884 is merged.
# Shell hackery taken from
# https://web.archive.org/web/20100129154217/http://www.seanius.net/blog/2009/03/saving-and-restoring-positional-params
2022-10-01 18:53:38 +03:00
_ZIG_TOOL_GOHACK = """
quote(){ echo "$1" | sed -e "s,','\\\\'',g"; }
for arg in "$@"; do saved="${saved:+$saved }'$(quote "$arg")'"; done
while [ "$#" -gt 6 ]; do shift; done
if [ "$*" = "-Wl,--no-gc-sections -x c - -o /dev/null" ]; then
# This command probes if `--no-gc-sections` is accepted by the linker.
# Since it is executed in /tmp, the ZIG_LIB_DIR is absolute,
# glibc stubs and libc++ cannot be shared with other invocations (which use
# a relative ZIG_LIB_DIR).
exit 0;
fi
eval set -- "$saved"
"""
def _zig_tool_wrapper(zig_tool, zig, is_windows, cache_prefix, zigtarget, zig_include_root):
2022-11-17 14:04:25 +02:00
if zig_tool in ["c++", "build-exe", "build-lib", "build-obj"]:
maybe_target = "-target {}".format(zigtarget)
else:
maybe_target = ""
kwargs = dict(
zig = str(zig).replace("/", "\\") + ".exe" if is_windows else zig,
zig_tool = zig_tool,
cache_prefix = cache_prefix,
2022-10-01 18:53:38 +03:00
maybe_gohack = _ZIG_TOOL_GOHACK if (zig_tool == "c++" and not is_windows) else "",
2022-11-17 14:04:25 +02:00
maybe_target = maybe_target,
zig_include_root = zig_include_root.replace("/", "\\") if is_windows else zig_include_root,
)
2022-05-29 19:35:16 +03:00
if is_windows:
if cache_prefix:
return _ZIG_TOOL_WRAPPER_WINDOWS_CACHE_KNOWN.format(**kwargs)
else:
return _ZIG_TOOL_WRAPPER_WINDOWS_CACHE_GUESS.format(**kwargs)
else: # keep this comment to shut up buildifier.
if cache_prefix:
return _ZIG_TOOL_WRAPPER_CACHE_KNOWN.format(**kwargs)
else:
return _ZIG_TOOL_WRAPPER_CACHE_GUESS.format(**kwargs)
def _quote(s):
return "'" + s.replace("'", "'\\''") + "'"
2021-04-10 01:05:01 +03:00
def _zig_repository_impl(repository_ctx):
arch = repository_ctx.os.arch
if arch == "amd64":
arch = "x86_64"
os = repository_ctx.os.name.lower()
if os.startswith("mac os"):
os = "macos"
2022-05-29 19:35:16 +03:00
if os.startswith("windows"):
os = "windows"
host_platform = "{}-{}".format(os, arch)
2021-04-10 01:05:01 +03:00
zig_include_root = repository_ctx.attr.host_platform_include_root[host_platform]
zig_sha256 = repository_ctx.attr.host_platform_sha256[host_platform]
2022-05-29 19:35:16 +03:00
zig_ext = repository_ctx.attr.host_platform_ext[host_platform]
2021-04-10 01:05:01 +03:00
format_vars = {
"_ext": zig_ext,
2021-06-16 12:44:16 +03:00
"version": repository_ctx.attr.version,
"host_platform": host_platform,
2021-04-10 01:05:01 +03:00
}
2022-03-18 06:30:42 +02:00
# Fetch Label dependencies before doing download/extract.
# The Bazel docs are not very clear about this behavior but see:
# https://bazel.build/extending/repo#when_is_the_implementation_function_executed
# and a related rules_go PR:
# https://github.com/bazelbuild/bazel-gazelle/pull/1206
for dest, src in {
"platform/BUILD": "//toolchain/platform:BUILD",
"toolchain/BUILD": "//toolchain/toolchain:BUILD",
"libc/BUILD": "//toolchain/libc:BUILD",
"libc_aware/platform/BUILD": "//toolchain/libc_aware/platform:BUILD",
"libc_aware/toolchain/BUILD": "//toolchain/libc_aware/toolchain:BUILD",
}.items():
repository_ctx.symlink(Label(src), dest)
for dest, src in {
"BUILD": "//toolchain:BUILD.sdk.bazel",
2022-09-21 13:14:29 +03:00
# "private/BUILD": "//toolchain/private:BUILD.sdk.bazel",
}.items():
repository_ctx.template(
dest,
Label(src),
executable = False,
substitutions = {
"{zig_sdk_path}": _quote("external/zig_sdk"),
"{os}": _quote(os),
"{zig_include_root}": _quote(zig_include_root),
},
)
2022-03-18 07:04:49 +02:00
urls = [uf.format(**format_vars) for uf in repository_ctx.attr.url_formats]
2021-04-10 01:05:01 +03:00
repository_ctx.download_and_extract(
auth = use_netrc(read_user_netrc(repository_ctx), urls, {}),
2022-03-18 07:04:49 +02:00
url = urls,
2021-04-10 01:05:01 +03:00
stripPrefix = "zig-{host_platform}-{version}/".format(**format_vars),
sha256 = zig_sha256,
2021-04-10 01:05:01 +03:00
)
for zig_tool in _ZIG_TOOLS:
for target_config in target_structs():
zig_tool_wrapper = _zig_tool_wrapper(
zig_tool,
str(repository_ctx.path("zig")),
os == "windows",
repository_ctx.os.environ.get("BAZEL_ZIG_CC_CACHE_PREFIX", ""),
zigtarget = target_config.zigtarget,
zig_include_root = zig_include_root,
)
2022-05-29 19:35:16 +03:00
repository_ctx.file(
zig_tool_path(os).format(
zig_tool = zig_tool,
zigtarget = target_config.zigtarget,
),
zig_tool_wrapper,
)
2021-04-10 01:05:01 +03:00
repository_ctx.file(
"glibc-hacks/fcntl.map",
content = _fcntl_map,
)
repository_ctx.file(
"glibc-hacks/glibchack-fcntl.h",
content = _fcntl_h,
)
2021-04-10 01:05:01 +03:00
zig_repository = repository_rule(
attrs = {
"version": attr.string(),
2021-04-10 02:58:05 +03:00
"host_platform_sha256": attr.string_dict(),
"url_formats": attr.string_list(allow_empty = False),
"host_platform_include_root": attr.string_dict(),
2022-05-29 19:35:16 +03:00
"host_platform_ext": attr.string_dict(),
2021-04-10 01:05:01 +03:00
},
environ = ["BAZEL_ZIG_CC_CACHE_PREFIX"],
2021-04-10 01:05:01 +03:00
implementation = _zig_repository_impl,
)
def filegroup(name, **kwargs):
native.filegroup(name = name, **kwargs)
return ":" + name
2022-05-29 19:35:16 +03:00
def declare_files(os, zig_include_root):
2022-09-21 13:14:29 +03:00
filegroup(name = "all", srcs = native.glob(["**"]))
2021-06-16 12:44:16 +03:00
filegroup(name = "empty")
2022-05-29 19:35:16 +03:00
if os == "windows":
native.exports_files(["zig.exe"], visibility = ["//visibility:public"])
native.alias(name = "zig", actual = ":zig.exe")
else:
native.exports_files(["zig"], visibility = ["//visibility:public"])
2021-06-16 12:44:16 +03:00
filegroup(name = "lib/std", srcs = native.glob(["lib/std/**"]))
2021-04-10 01:05:01 +03:00
lazy_filegroups = {}
for target_config in target_structs():
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
for d in _DEFAULT_INCLUDE_DIRECTORIES + target_config.includes:
d = zig_include_root + ("\\" if os == "windows" else "/") + d
if d not in lazy_filegroups:
lazy_filegroups[d] = filegroup(name = d, srcs = native.glob([d + "/**"]))