- 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.
this way the users can influence which install prefix will appear in the
generated code
install prefix have to be relative - we are doing the hermetic build
modify our shell script to copy the result of the build into the target directory
(we can not leave it in temp directory, it will be deleted)
