* 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
Some libraries define not only C/C++ libraries and headers, but also
scripts for finding this libraries (pkg_config, CMake find/config scripts).
Another important use case is defining CMake functions to be used in the CMake build of the dependent targets.
As for CMake such scripts are searched for in the number of directory path combinations, relative to CMAKE_INSTALL_PREFIX, including for both Unix and Windows,
<prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/ (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (W/U)
acceptable solution would be copying the whole CMake install directory under the dependencies root $EXT_BUILD_DEPS, which is passed as CMAKE_INSTALL_PREFIX.
For the libraries, which put their CMake scripts into some other paths, user can add copy command using postfix_script parameter.
To be documented better.
In that case, the file itself should be linked to the target directory
It shows up if we depend on the library, which provides only header files,
and no information on the wrapping directory. Technically it is correct, but
then our linking script should be prepared to link individual files as well as wrapping directories.
Example: cc_import of header-only library.
Unfortunately, the prefix is never relative.
If the relative value is passed, current directory is used as base,
and the real prefix is $(pwd)/<relative-prefix>
However, keep any value, passed by user, as finally outside the build that value can be used.
When creating the directory structure for running cmake/configure,
search for underlying items, but exclude self (which used to be returned by find).
For that, use -mindepth option
Have explicit dict option "cache_entries" for passing CMake cache initializer key-values pairs to the rule.
This gives us ability to join user initializers and toolchain initializers. This might be useful with flags option.
irengrig