There's now a top level bzl_library @rules_foreign_cc//:bzl_srcs that contain the .bzl sources for the build rules defined in this repo.
Stardoc support was also added to ensure the bzl_library structure is correct and usable outside of the repo. In addition to this, new documentation can be generated by running bazel run //docs:generate_docs from the root of rules_foreign_cc/examples to output @rules_foreign_cc_tests//docs:README.md.
* 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
```
* 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
* external build framework macro and cmake_external rule
* declare deps headers as inputs as well; correct sed expression
* use symlinking instead of copying, filter duplicates
* correct detect root
* corrections for copying tools and include directories
* correct review comments
* provide a way to pass modified attributes to the framework function
create a function that creates a dict from ctx.attr,
replaces/adds values and creates a resulting struct;
have mandatory attributes as mandatory parameters to this function
* correct review comments
* correct detect_root
* introduce parameter for passing user defined link options
* add documentation, define default static library to be built
* correct/improve documentation
* more correct gathering headers and include directories from dependencies
* correct review comments
* correct passing transitive link options
