* Don't use deprecated targets for the preinstalled toolchains
* Add option to the repository macro for using built version of the build tools.
* Fix buildifier complaint
* Create BUILD_TMP directory when building make
* Corrections to toolchain setup for make_tool, cmake_tool and ninja_tool
* Fix path to built tools
* Attempting to fix make_tool for RBE
* Disable dependency tracking for make build
* Add cc_toolchain deps
* Add a built_toolchains.bzl file to be able to select the version to build
* Address buildifier issues
* Use geolocated mirror redirect for downloading make srcs
* Update docs
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
```
Fix the code to work with Bazel HEAD:
- convert depset to list for iteration (libraries to link)
- _build_tools() are just creating the file, not contributing anything to the text of constructed BUILD file, so make a call to this method separately.
This PR adds @bazel_version repository which contains single def.bzl
file which contains a BAZEL_VERSION constant that can be used to perform
conditional logic bazed on the Bazel version.
As a result, rules_foreing_cc are now compatible with Bazel 0.24 - 0.27
(at least regarding configure_features :)
* Windows, tests: fix for native test wrapper
In this PR:
- Update `@bazel_skylib` to 0.8.0, which has a
Windows-compatible unittest.bzl
- Fix unittest-using tests. Correct usage of
`unittest.end(env)` is to return its value.
Result: //test:all now passes with Bazel 0.25.0rc3
and --incompatible_windows_native_test_wrapper
* Register Skylib toolchains
* rules_foreign_cc_dep registers unittest toolchains
* Address review comments
* Add bazel_skylib_workspace to WORKSPACE files
* Remove stale toolchain init code
* Register shell toolchain implementations in the correct order
so that the default implementation is the last
* Refactor shell toolchain to allow users register custom shell toolchains.
- define your own shell toolchain file(s) by copying @rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains/impl:linux_commands.bzl,
and modifying the methods.
- create a mapping: a list of ToolchainMapping with the mappings between created file(s) and execution or/and target platform constraints.
- in the BUILD file of some package, call "register_mappings" macro from "@rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains:defs.bzl", passing the mappings and toolchain_type_ = "@rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains:shell_commands"
- in the WORKSPACE file of your main repository, when you initialize rules_foreign_cc, pass the mappings and the package, in which BUILD file you called "register_mappings" macro
* Correct typo
As Bazel 0.22.0 is broken for rules_foreign_cc on Windows, we do not want to run any tests with this version on CI. So we are selecting the list of tests to run according to recorded-in-workspace Bazel version.
But list of tests can not be empty! Instead, have a test that just prints the Bazel version.
* 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
* Allow execution on Windows, use utils_win.sh, copy instead of symlink
* Prepare for execution on Windows: set up environment, convert path
also rename TMPDIR since it can clash with widely used variable
* cmake toolchain files support
* extract cmake script consruction code into a separate file
for further testing
* simplify cmake script creation code
* first four tests for CMake script creation functions
* + move_dict_values_test for CMake script creation functions
* + reverse_descriptor_dict_test for CMake script creation functions
* + toolchain_and_user_values_test for CMake script creation functions
* add create_cmake_script_no_toolchain_file_test for CMake script creation
* do not insert executable linker rule option if it uses cxx compiler
since it would be the same as default
add one more test for command line
* add test for cmake script with toolchain file
* add test for cmake script with toolchain file with user values
* propagate information about target into CMake toolchain file
apparently, is it possible to just take the needed environment variables from cc_common, and not do any calls to rules_apple or platform-dependent initialization
- initialize apple tools on workspace level properly using universal install_ws_dependency() function
- pass proper environment variables to the shell script action
- pass proper hidden attributes to framework function rules in case of osx os
- also, clean up WORKSPACE file putting example repositories into a separate file
- correct: repositories needed by framework function itself should be defined in the same single function in workspace_definitions.bzl
- unfortunately, it is not possible to move android initialization anywhere from WORKSPACE file
