Fixes cross-compiling from macos to linux.
see #997 for background.
I had to make a couple of extra changes to support this:
Setting CMAKE_SYSTEM_NAME manually causes CMAKE_SYSTEM_PROCESSOR to not be set. This breaks some builds that expect this variable to be set like libjpeg-turbo.
I made it so that the above variables are only set when cross-compilation is detected so that rules_foreign_cc only takes on responsibility of setting them when necessary.
* Add meson support
* Modify zlib to be detected via pkgconfig in dependent rules
* Modify zlib and expat to be linked to shared libs in dependent rules
* Add example usage of Meson rule
This commit adds the glib library to the "examples" build. glib requires
pcre2, so pcre and libgit2 (a dependent of pcre) have been
updated/modified
* Add example usage of meson_with_requirements macro
This commit adds mesa to the "examples" build.
This commit also changes the "examples" build to use the hermetic python
toolchain provided by rules_foreign_cc. As such, the python toolchain
built by rules_foreign_cc is no longer used, as it cannot be used in
workspace rules, .e.g pip_parse(). As such, the python2 build has been
removed from the examples as python2 is end-of-life.
Until Bazel 4.2.0, the built-in android toolchain required Python 2. As
such the minimum supported version has been upversioned to 4.2.0.
Note that the BAZEL_VC env var was removed from CI as mesa requires MSVC
2019.
* Set visibility for each target in foreign_cc_rule_variant
* Apply formatting changes
* Get meson examples working with bzlmod
Note that a newer version of pkgconfig than that installed in ubuntu 20
must be used to build libxau, therefore the built_pkgconfig_toolchain is
now registered
* Make cc_toolchain_utils.bzl more reusable
By using getattr, the helper functions in this file can be reused in
rules that do not define all of the framework attributes, e.g. bootstrap
rules.
* Bootstrap make reproducibly on Linux and macOS
Uses the Bazel C/C++ toolchain to bootstrap make and ensure that the
resulting binary contains no absolute and thus non-hermetic paths.
Building make reproducibly helps with remote caching and removes the
dependency on a C compiler installed on the host.
* Adds toolchain for freebsd.
* Address buildifier lint warnings.
* Use /usr/bin/env bash
* Leave the Linux-specific shebang alone.
* Adds note about Bazel CI issue requesting for FreeBSD support and experimental status.
* Fix typo.
* Clean up trailing whitespace.
* Updates bazel-skylib version for tests to pass on FreeBSD.
* Update foreign_cc/repositories.bzl
Co-authored-by: UebelAndre <github@uebelandre.com>
* Pass toolchain and user env variables to make invocation
* Rename configure --> make
* Add integration test coverage for make flag passing
This requires making the make_simple Makefile more realistic by
* using CXX and forwarding it to the wrapper;
* using CXXFLAGS instead of CXX_FLAGS and not overwriting its contents.
Certain (C)Make projects (such as [AFL++](https://github.com/AFLplusplus/AFLplusplus)) emit binaries that are symlinks to other emitted binaries. When built with `rules_foreign_cc`, this can lead to non-deterministic dangling symlink errors since Bazel visits the outputs in an unspecified order. This is fixed by resolving symlinks among the emitted binaries, just like it is already done for libraries.
Since 466c32c70f any changes you made
while testing rules_foreign_cc, or changes to those rules, would not
invalidate the CMakeCache.txt and lead to build issues. It wasn't the
case before that because new temp dirs were used each time.
* build OpenSSL using MSVC toolchain on Windows
* Display lib name in progress message
Before this commit, when building OpenSSL using MSVC, the progress
message would display "Building openssl_msvc_".
After this commit, the progess message would display
"Building openssl".
* Add test to verify linkage with OpenSSL libs
* Add test to verify linkage with Curl libs
Note that linker errors occur in applications that link with libssl
and libcrypto if libcrypto comes before libssl on the linker
command-line. Swapping the order of libcrypto and libssl in
BUILD.openssl.bazel resolved the issue.
The macros utilise bazel "transitions" to set the `make` toolchain used
in the configure_make(), cmake() or make() rules to
a given make variant toolchain, e.g. preinstalled_nmake.
Note that the msvc constraint was removed from the
`exec_compatible_with` attribute of `preinstalled_nmake_toolchain` as
the condition is not actually met even when building with msvc. See
https://github.com/bazelbuild/bazel/issues/7730.
This will be tested in PR#729
If a user specifies a PATH value as part of an `env` attribute, the
value will be prepended to the existing PATH.
An example requirement for this change is that the MSVC build of
OpenSSL requires that the Netwide Assembler (NASM) must be on the
PATH.
This change is required when using the MSVC toolchain on Windows,
as paths for tools such as the compiler contain whitespaces (e.g.
C:\Program Files\...)
Co-authored-by: UebelAndre <github@uebelandre.com>
* Convert MSVC flags by replacing slashes with dashes
This overcomes bugs in MSYS2 where leading slashes are converted to
paths, e.g. "/nologo" is converted to "C:\msys64\nologo".
This commit would modify the flag to become "-nologo". MSVC supports
both slashes and dashes for flags.
* Update foreign_cc/private/cc_toolchain_util.bzl
Co-authored-by: UebelAndre <github@uebelandre.com>
* Enable examples tests on windows
* Fixed windows absolute paths being treated as relative.
* Escape windows backslashes for sed replacement
* Improve `//cmake_hello_world_lib/static:libhello` example
James Sharpe