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)
* take tools paths and flags from the toolchain
* correct toolchain data extraction, correct cmake flags and environment
* framework script: export variables intended to be used in config script
config script can create child processes which could use this variables
* cmake: prepend relative [to the execroot] paths with "$EXT_BUILD_ROOT/"
unfortunately, CMake does not understand relative paths
(sometimes it runs tests for the passed compiler and for that
concatenates the passed relative path to some tmp directory created for test)
we replace only paths starting with external/ and <top-package-name>/,
so we are quite fine to not make a mistake with replacing some not related to paths text;
the targets for replacement take very different form (judging by examining
toolchain definitions), for instance "-Lexternal/something"
* test data for cross compilation for android and with --crosstool_top
data files taken from bazel examples and bazel test data;
NB one of the interesting things is that we need to specify tools dependency on android sdk and ndk, so that cmake_external shell script have access to these tools
* remove cross compilation example with CROSSTOOL for now
* add very simple CMake library (test data)
* rename target to indicate it is not a test, but example
* adjust android example:
rename the target to indicate it is not a test but example,
add android ndk sources as additional tool for cmake target,
(otherwise it is not available in sandbox)
use more simple cmake-built library
* corrections to the framework & cmake:
- correct search for the root directory of the filegroup (when it is not under external)
- it was a mistake to specify shared library linker, specify CMAKE_AR instead
- unfortunately, I have not discovered how to modify CMake behaviour to pass the custom static flags (rcsD) before "-qc <target>" to the ar linker; option from documentation does not work. To be investigated. For now, do not pass the static cxx linker options, taken from Bazel toolchain.
* allow usage of underscore in external libraries rules
* iterate the name string with index (correct review comment)
sorry for autoformatting changes; the real changes are in lines 259, 260
* iterate the name string with index (correct review comment)
i.e. not single libraries, because in general case several build targets
can be created by a single CMake/configure-make build, and several of them linked to the next dependency
