* Attempt to catch shell script errors proactively with 'set -euo pipefail'
* Fix up uninitialised variable use
* Fix osx shell function
* Fix to unbound variable in windows commands
* 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
* 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
* Added `data` attribute for files needed by the rule at runtime.
* Updated documentation
* Added examples
* Enable runfiles on windows
* Also gather transitive runfiles
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>
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>
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
* Implement support for "pure" GNU Make in make.bzl
Usage: load("@rules_foreign_cc//tools/build_defs:make.bzl", "make")
make(name = <name>, lib_source = <source>), please see more arguments
in make.bzl
Add test in examples/simple_make (runs only on Linux because of Makefile contents)
* examples: cmake_crosstool: Remove executable bit from BUILD
There is no reason for BUILD file to be an executable.
Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
* examples: Add shebang to the bash script
print_bazel_version.sh is a bash script, but it did not contain a
shebang.
Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
* Fix replace_in_files function in windows_commands.bzl
Filter files by types, where the absolute paths need to be replaced.
* Add one more hello world example
* Include test into windows list, remove from Mac OS list
The line number doesn't match the exact location of the position of the content. This is tolerable with patch command line tool, but it won't work with a more strict patch implementation.
Context: https://github.com/bazelbuild/bazel/pulls
Fix #232 - enable usage of Bazel-built libraries as dependencies of cmake_external and configure_make.
- fix logic of reading library data described by C/C++ Bazel interface (as CcInfo.linking_context appeared)
- symlink transitive include directories under $EXT_BUILD_DEPS
- gather all possible transitive include directories to pass to CMake, pass transitive include directories to CMAKE_PREFIX_PATH so that the transitive include directories were scanned by CMake
- fix logic of passing transitive libraries into CPPFLAGS (configure_make)
- add test with the chain: Bazel lib -> CMake lib -> Bazel cc_test
- add synthetic configure-make test with the chain: Bazel lib -> configure_make lib -> Bazel cc_test
- also notice, that passed include directories from Bazel C/C++ Sandwich interface are not always existing; for now, make symlinking code resistant to that
see https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Preset-Output-Variables.html
* 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
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
* Reorganize examples to be in a separate workspace
This will help to define native tools toolchains for examples
* Remove examples-related part from main WORKSPACE file
* Copy .bazelrc to the examples workspace.
* correction for Bazel HEAD compatibility
* Changes to run nested workspace tests from main workspace
* Improve the boost rule including user_options attribute.
Then --with-<library> parameter can be passed to build only that library
Modify examples to demonstrate how to use it.
However, building examples takes too long time, so do not include them into the tests.
* Add crosstool example; does not work with cmake rule yet
the code is taken from Bazel test data (bazel_toolchain_test_data)
* Make crosstool compilation of cmake_external + cc_binary work
To build example, cd examples/cmake_crosstool bazel build //:libhello_test
Changes:
1) Initially suggested in #124: put $EXT_BUILD_ROOT on path, so that relative paths can be resolved by CMake
2) Toolchain tools are references as relative paths, and they themselves refer to external repository with external/ prefix.
This will not work with CMake, as CMake also perform compiler tests and the build is performed in some temp directory.
We need to convert to absolute paths.
I did a trick with checking of $EXT_BUILD_ROOT is defined and then using it as a prefix.
3) I had to change the visibility of the cc-compiler-k8 toolchain to public
4) For CMake crosstool file, CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, CMAKE_AR need to be absolute, so in cases when they are relative and not under external directory, force paths conversion
* move cmake_hello example with static library into a subdirectory
* Fix #139; correct arguments to create_library_to_link
However, the test (which should link the externally built shared library to the calling .c file) fails with assertion that the .so file is in a "wrong" directory, so I am providing it here for additional work [possibly] on Bazel side; and I do not include it into the tests list
* As cc_common.create_library_to_link is now broken for shared libraries,
use the "old" variant cc_common.create_symlink_library_to_link.
As it will later be removed (and create_library_to_link fixed),
it is safe to check for the existence of create_symlink_library_to_link and call it.
Now the test with shared library built by CMake runs, so add it ot the [non-Windows, for now] suite.
* Adapt building shared library with cmake test for mac
* increment version
* Add comment on CMAKE_MACOSX_RPATH
* External C/C++ libraries rules need to pass transitive info
- to have the same interface as cc_library to hide the "implementation details",
so that the information about the install directory and its contents of non-direct external dependencies of external library was available for external build
- this is particularly needed for configure-make rule, where we do not control the way needed libraries are found, so we want to provide the install directory and the -L, -I flags (include and library directories to be searched) consistently,
pointing to the directories under $EXT_BUILD_DEPS
- as a side effect, *.la files that contained links to absolute paths of dependencies (pointing somewhere under ...sandbox/bazel-out/...) now will point to directories under $EXT_BUILD_DEPS and so will be replaced correctly/will not point to paths under the previous sandbox
* External C/C++ libraries rules need to pass transitive info [improve]
By review comments;
- rename to do not collate with internally reserved list, dir, provider
- rename providers to use the same "foreign_cc" prefix and be shorter
- improve providers description
- return back output groups to do not reduce the flexibility
* External C/C++ libraries rules need to pass transitive info [improve]
By review comments:
- some more renames
* External C/C++ libraries rules need to pass transitive info: version++
* Correct review comments
* correct shell utilities: params differ on mac, remove debug print,
+ correct a bug on windows
* Simplify the example, libz is also needed by libgd
* Framework function: simplify code gathering deps, collect_libs public
* Correct configure-make: get all lib files, also built with bazel
and pass them in LDFLAGS; correct the linking paths (add prefix)
* Make maximum line length for shell = 80
* Improve comments to the _InputFiles provider
* implements pcl cmake_external build rule
* Improve example with building PCL (Point Cloud Library):
- build boost library and use it as dependency
- add/correct some properties
* implements pcl cmake_external build rule
* Improve example with building PCL (Point Cloud Library):
- build boost library and use it as dependency
- add/correct some properties
* 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
UebelAndre