* Build under bazel sandbox instead of /tmp, and remove redundant printf
Build artifacts under /tmp are not cleaned up after a failed build, for
the ease of debugging. However, this can quickly fill up the /tmp partition
if the build is large. Build under the sandbox directory instead, and
rely on standard bazel cleanup scheme.
Also remove a print from the cleanup function, which somehow causes empty
newlines to be printed in bazel build output.
* Avoid infinite recursion in symlink_to_dir.
This is a somewhat hackish approach to exclude *.ext_build_deps from
symlinks when creating the symlink forest. This is necessary in cases
where an entire directory is added to the includes, e.g. when setting
includes = ["."] where the directory itself contains a cmake_external()
rule that depends on the very rule containing the includes = ["."].
* Also avoid using a temp directory when bootstrapping make or cmake itself.
* Remove the ##tmpdir## shell toolchain command.
It is no longer necessary now that all its uses are gone.
Co-authored-by: Lauri Peltonen <lape@iki.fi>
* Allow setting env vars
Also, bring all runfiles of data deps along for execution - currently
data deps which consist of more than one file aren't copied into the
action, which means that they will fail at runtime when they try to use
their runfiles.
* Update docs
handle filename containg space.
cmake prebuilt archive contains such filename in docs etc.
also fix symlink to a directory. [ -L "$1" ] returns success
for it, but it would fail "cp $1 $2" as
cp: -r not specified; omitting directory ...
Fixes: #405, #406
Co-authored-by: UebelAndre <andre.brisco@gmail.com>
* Fix test target on macOS with Bazel@HEAD
supports_dynamic_linker feature was removed from cc toolchain for macOS,
cc_binary should be used to build shared library.
Context: bazelbuild/bazel#4341 (comment)
* Fix test on Windows
* Makes additional_inputs accept targets
Makes additional_inputs attribute also accept bazel Targets
as inputs, just like lib_source attribute already does.
* Stop checking for input is of type 'Target'
Update the patch so it follows the current code style.
Stop checking if the input is of type 'Target' as additional_inputs
attribute shall accept just 'Target' type.
Fix the same issue in additional_tools attribute.
* Added `data` attribute for files needed by the rule at runtime.
* Updated documentation
* Added examples
* Enable runfiles on windows
* Also gather transitive runfiles
Otherwise if I put anything in additional_tools I get an error about
depset not being iterable.
This matches the for loop just above, which does the to_list conversion.
Co-authored-by: UebelAndre <andre.brisco@gmail.com>
The former has been deprecated and will break by
--incompatible_use_platforms_repo_for_constraints, as announced in
https://github.com/bazelbuild/bazel/issues/8622.
Fixes #354.
Co-authored-by: UebelAndre <andre.brisco@gmail.com>
This change allows rules_foreign_cc to work on architectures other
than x86_64.
Bug: bazelbuild/bazel#11628
Test: manual. no longer fails with "ln: illegal option -- t" on darwin_arm64
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
```
James Sharpe