bazel/rules_foreign_cc
2
0
Fork 0
mirror of https://github.com/bazel-contrib/rules_foreign_cc synced 2024-12-04 08:02:31 +00:00
Code Issues Releases Activity
rules_foreign_cc/tools/build_defs/BUILD

56 lines
2 KiB
Python
Raw Normal View History

Added bzl_libraries for stardoc support (#453) 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.
2021-01-22 14:25:49 +00:00
load("@bazel_skylib//:bzl_library.bzl", "bzl_library")
Extract cmake and ninja into a toolchain; provide defaults. (#192) * 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
2019-01-08 11:25:16 +00:00
toolchain_type(
name = "cmake_toolchain",
visibility = ["//visibility:public"],
)
toolchain_type(
name = "ninja_toolchain",
visibility = ["//visibility:public"],
)
Add a GNU Make toolchain (#379) * 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 ```
2020-09-07 08:48:26 +00:00
toolchain_type(
name = "make_toolchain",
visibility = ["//visibility:public"],
)
Extract cmake and ninja into a toolchain; provide defaults. (#192) * 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
2019-01-08 11:25:16 +00:00
# Preinstalled cmake will always be the default, if toolchain with more exact constraints
# is not defined before; registered from workspace_definitions.bzl#rules_foreign_cc_dependencies
toolchain(
name = "preinstalled_cmake_toolchain",
toolchain = "@rules_foreign_cc//tools/build_defs/native_tools:preinstalled_cmake",
toolchain_type = "@rules_foreign_cc//tools/build_defs:cmake_toolchain",
)
# Preinstalled ninja will always be the default, if toolchain with more exact constraints
# is not defined before; registered from workspace_definitions.bzl#rules_foreign_cc_dependencies
toolchain(
name = "preinstalled_ninja_toolchain",
toolchain = "@rules_foreign_cc//tools/build_defs/native_tools:preinstalled_ninja",
toolchain_type = "@rules_foreign_cc//tools/build_defs:ninja_toolchain",
export rules (#18)
2018-08-13 12:30:15 +00:00
)
Add a GNU Make toolchain (#379) * 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 ```
2020-09-07 08:48:26 +00:00
# Preinstalled make will always be the default, if toolchain with more exact constraints
# is not defined before; registered from workspace_definitions.bzl#rules_foreign_cc_dependencies
toolchain(
name = "preinstalled_make_toolchain",
toolchain = "@rules_foreign_cc//tools/build_defs/native_tools:preinstalled_make",
toolchain_type = "@rules_foreign_cc//tools/build_defs:make_toolchain",
)
Added bzl_libraries for stardoc support (#453) 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.
2021-01-22 14:25:49 +00:00
bzl_library(
name = "bzl_srcs",
srcs = glob(["**/*.bzl"]) + [
"@rules_foreign_cc_bazel_version//:def.bzl",
],
visibility = ["//:__subpackages__"],
deps = [
"//tools/build_defs/native_tools:bzl_srcs",
"//tools/build_defs/shell_toolchain/polymorphism:bzl_srcs",
"//tools/build_defs/shell_toolchain/toolchains:bzl_srcs",
"@bazel_skylib//lib:collections",
"@bazel_skylib//lib:versions",
],
)
Copy permalink