* 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>
* 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
```
Fix shell function symlink_contents_to_dir, add test
- test for the case when we symlink the contents of two directories with the same inner directories (include)
- the test data of the test for shell script helper also changes, as it uses the real shell toolchain implementation text
- Fixes the issue from #330
Fix shell_script_helper.bzl to replace function calls inside function texts.
Add test for shell_script_helper.bzl.
In particular, this fixes the case when some of the shell toolchain functions calls other shell toolchain functions (symlink_contents_to_dir and symlink_to_dir).
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>
Rules_foreign_cc also currently is not using CcInfo.quote_includes.
Having them leads to symlinking directory trees without any reason.
Tests: we already have tests for transitive Bazel dependencies (//cmake_synthetic:test_bazel_transitive_deps, //cmake_with_bazel_transitive:test, //configure_with_bazel_transitive:test)
* Fix permission problem with replacing absolute path with sed, #306
- we can not modify files under Bazel's output directory
- so we can not modify pkg_config files, written there, for instance
- solution: only replace absolute paths in the files being created by the current target,
using the environment variable as the replacement value ($EXT_BUILD_DEPS)
* Wrap environment variable in ${} in replace string
Apparently, it is not the problem for build outputs, but deps directory that is created by script.
What is even more problematic is that this directory can be accessed while building this target in parallel for different configurations. So even if we clean it before using, we might break the build of the parallel target.
Solution: create temp directory to be used as deps directory.
(Additionally, this demonstrates the benefits of sandboxed execution.)
Be resilient with Bazel-built transitive dependencies duplicates
- it is possible that some duplicate libraries, built with Bazel, will be passed as inputs to cmake_external or configure_make. rules_foreign_cc should filter duplicates out rather then fail.
- add a test (which just builds the target) //cmake_synthetic:lib_with_duplicate_transitive_bazel_deps
Adapt rules_foreign_cc for working with libtool instead of ar.
- for CMake, pass "<TARGET>" as the output file when forming linker flags with cc_common. CMake will later replace <TARGET> with the actual output file. Fill CMAKE_C_CREATE_ARCHIVE and CMAKE_CXX_CREATE_ARCHIVE CMake variables with 'CMAKE_AR %Bazel-link-flags% <OBJECTS>' call, where CMAKE_AR will take the path to libtool.
Related documentation: https://cmake.org/cmake/help/v3.15/variable/CMAKE_LANG_ARCHIVE_CREATE.html?highlight=cmake_%20lang%20_archive_create
- for configure_make, for the libevent example, we need to skip specifying the libtool from Bazel's toolchain as a linker, because libevent script uses it's own libtool and manages to pass the output file to it, but not to the libtool we are passing. Let it do so as it is a customized script.
Do it with specifying empty string for the $AR environment variable.
Other examples with configure_make work fine.
This fixes https://github.com/bazelbuild/bazel/issues/9258
