* 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
* 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>
* Added `targets` API to all existing build rules
* Updated examples
* Restore making the make toolchain always available.
* Add support for generator cmake parsing and setting CMAKE_MAKE_PROGRAM
* Cleaned up duplicate generator arguments
* Fixed cmake tests
* Updated docs
* Addressed PR feedback
* Fixed missing and incorrect generators
* Fixed `generate_args` name
* Use `.format()` instead of `%` for constructing `make_commands`.
I'm about to add a third substitution parameter to these lines, and it's
already getting a bit crowded. This is a no-op change, but should make
the follow-up commits more readable.
* Add `make_toolchain` toolchain type.
Add a toolchain that implements it using the pre-installed system
`make`. Make use of this toolchain in the `make()` rule.
* Use the `make` toolchain in configure and cmake scripts as well.
This allows the registered `make` toolchain to be used not just in make,
but also in cmake and configure_make targets. As a result, one can
either ship their own `make`, built for the execution environment, or
use a custom `make`, e.g. one that calls `emmake make`.
To make this backwards compatible with `make_commands`, the substitution
will only replace the leading word `make` from any line in
`make_commands`. Thus, existing rules that specify a `make_commands`
attribute that refers to the binary simply as `make` should still work
with any toolchain implementation that provides the binary.
* Update `README.md`.
Describe the new toolchain type.
* Add `BootstrapMake` to bootstrap a `make` toolchain.
This allows the `make` toolchain to be used even without GNU Make being
pre-installed on the system.
* Add example Gnu Make boostrap target.
Test manually using:
```
$ cd examples
$ bazel build //build_make_itself:maketool
```
Allow to specify working directory for cmake_external
For LLVM case, when main CMakeLists.txt is in the /llvm subdirectory in the source tree
Co-authored-by: Andy Yankovsky <weratt@gmail.com>
* Update README.md because of Bazel 0.22.0 release
- with Bazel 0.22.0, no flags are required to use rules_foreign_cc
- improve Bazel versions related information
- add link to "rules_foreign_cc take-aways"
* Correct headers in README
- with Bazel 0.22.0, no flags are required to use rules_foreign_cc
- improve Bazel versions related information
- add link to "rules_foreign_cc take-aways"
* Extract shell fragments into a toolchain
Construct script in framework.bzl using special notation for calling
shell fragments, defining and referencing environment variables;
have the script converted from this special notation into a real script
(see README.md notes.)
The special notation is used to keep script construction in code still readable.
Tools scripts (cmake, ninja) were also converted.
* Fix reference to environment variables in examples
.. and reference it correctly $$var_name$$ so it is replaced further
* Review comments: documentation, explicitly mark functions from toolchain
- mark functions from shell toolchain as ##funname##, so that they
can not be mixed with usual shell functions
* Fix operating system name for windows in toolchain file
* Additional env vars for windows
* Correct cmake tool build
* Do not build ninja on Windows
* When run on Windows under msys, find utility from Window could "leak"...
into the script. Use heuristics to use /usr/bin/find if it exists.
Also, use pwd -W to get Windows-styled paths (for cmake)
* Extract cmake and ninja into a toolchain; provide defaults.
In the workspace-level rule registration function, default toolchain
implementations are registered for all platforms, which are calling
the cmake and ninja just by name, assuming they are preinstalled.
Also, the user can pass the custom toolchains in the initialization
function, they will be registered before the defaults.
* Do not run ninja build test for now without nested workspaces support
* Corrections after merge
* Always build ninja from sources for tests, correct initialization order
* Add example of using prebuilt artefact in the native tools toolchain.
* Review comments, have native_tool_toolchain#target, not label
+ improve documentation
* Correct ninja toolchain label
* Correct documentation in native_tools_toolchain.bzl
The rule supports both old and new API;
however, for switching the implementations, I had to use code generation - copying the actual implementations for different API variants into a generated repository.
I did not invent any other mechanics to deal with non existing top level symbols like CcInfo or CcCompilationInfo.
Design document about the new API: https://github.com/bazelbuild/proposals, Partial C++ Starlark API
Introduced in the commit: eb139371c9
Javier Maestro