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
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
* external build framework macro and cmake_external rule
* declare deps headers as inputs as well; correct sed expression
* use symlinking instead of copying, filter duplicates
* correct detect root
* corrections for copying tools and include directories
* correct review comments
* provide a way to pass modified attributes to the framework function
create a function that creates a dict from ctx.attr,
replaces/adds values and creates a resulting struct;
have mandatory attributes as mandatory parameters to this function
* correct review comments
* correct detect_root
* introduce parameter for passing user defined link options
* add documentation, define default static library to be built
* correct/improve documentation
* more correct gathering headers and include directories from dependencies
* correct review comments
* correct passing transitive link options
