* Fix a way of wiping CMake cache entry values defined by toolchain from a command line, in case user specified empty values for these cache entries explicitly in cmake_external target
- it was a problem that we did not check that there was some value in the "toolchain" dict before we pop() - reported in comment in #292
- make code which does wiping empty values more explicit
* Additionally, if non-empty value for CMAKE_RANLIB was not specified by user or Bazel toolchain, put empty value for it to forbid CMake to auto detect it
context: https://github.com/bazelbuild/rules_foreign_cc/issues/252
* Add test for user's redefined value for CMAKE_BUILD_TYPE
* 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)
* 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
* fix(cmake): Use "Debug" and "Release" instead of "DEBUG" and "RELEASE"
These values are case-sensitive in cmake and give this error currently:
```
CMake Error at CMakeLists.txt:23 (message):
CMAKE_BUILD_TYPE must be one of: Debug, Release (current value: 'RELEASE')
```
* update test data
Fix the code to work with Bazel HEAD:
- convert depset to list for iteration (libraries to link)
- _build_tools() are just creating the file, not contributing anything to the text of constructed BUILD file, so make a call to this method separately.
This PR adds @bazel_version repository which contains single def.bzl
file which contains a BAZEL_VERSION constant that can be used to perform
conditional logic bazed on the Bazel version.
As a result, rules_foreing_cc are now compatible with Bazel 0.24 - 0.27
(at least regarding configure_features :)
For cmake_external and configure_make, do not prepend relative install prefix path with "./", as it is recognized as relative and gets appended to the current build directory anyway, forming the path /tmp/something/./install_prefix - which does not make much sense.
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
- explicitly pass the values of these options to corresponding compilation/link flags lists; add them to the end of the lists of they are not already there
- please see the test in test/standard_cxx_flags_test
* Improve outputs handling: wrapper script in shell-abstract manner
- extract wrapper script creation into a separate function,
- simplify the script and log names, also output the wrapper script text,
- introduce more shell primitives
related to #204
* Correct review comments
If the user passes empty string for some cache entry, for instance,
CMAKE_BUILD_TYPE, then the corresponding computed value
(computed from the Bazel's build type or Bazel C/C++ toolchain)
should not be used.
I.e., user passes "CMAKE_BUILD_TYPE": "", and there will be no
-DCMAKE_BUILD_TYPE in the cmake call.
Some configure scripts rely on being called from their parent directory (they call other files as if they are in the same directory). For this case, we should copy/symlink the contents of the directory under our build root, and run configure from there.
New attribute in configure_make rule: "configure_in_place".
Also, add documentation for configure_make.
* Register shell toolchain implementations in the correct order
so that the default implementation is the last
* Refactor shell toolchain to allow users register custom shell toolchains.
- define your own shell toolchain file(s) by copying @rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains/impl:linux_commands.bzl,
and modifying the methods.
- create a mapping: a list of ToolchainMapping with the mappings between created file(s) and execution or/and target platform constraints.
- in the BUILD file of some package, call "register_mappings" macro from "@rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains:defs.bzl", passing the mappings and toolchain_type_ = "@rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains:shell_commands"
- in the WORKSPACE file of your main repository, when you initialize rules_foreign_cc, pass the mappings and the package, in which BUILD file you called "register_mappings" macro
* Correct typo
* 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
* 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
* 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
otherwise during test execution too much is accumulated in that same directory,
and CMake gives up after searching in some amount of that subdirectories, and tests blink
* Allow execution on Windows, use utils_win.sh, copy instead of symlink
* Prepare for execution on Windows: set up environment, convert path
also rename TMPDIR since it can clash with widely used variable
We should take the default PATH passed by Bazel, not that from cc_toolchain for Windows, because the PATH under msys2 is different and that is which we need for shell commands
* 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
apparently, is it possible to just take the needed environment variables from cc_common, and not do any calls to rules_apple or platform-dependent initialization
- initialize apple tools on workspace level properly using universal install_ws_dependency() function
- pass proper environment variables to the shell script action
- pass proper hidden attributes to framework function rules in case of osx os
- also, clean up WORKSPACE file putting example repositories into a separate file
- correct: repositories needed by framework function itself should be defined in the same single function in workspace_definitions.bzl
- unfortunately, it is not possible to move android initialization anywhere from WORKSPACE file
