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
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
* Correct the problem with dependent output files/directories
A rule should not return files and their parent directory;
therefore, create a copy directory for the install directory, which we use in the next-step external builds, and reduce other outputs to the lowest level (library files, binary files, include directories).
* Correct review comments: add documentation, revert not related change.
* Do not pass the rule context as argument into shell utilities functions;
only pass the actions factory and other specific parameters.
(review comments)
* 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
