2
0
Fork 0
mirror of https://github.com/bazel-contrib/rules_foreign_cc synced 2024-12-04 08:02:31 +00:00
Commit graph

17 commits

Author SHA1 Message Date
Marcel Hlopko 6b2f454a41 Use forward compatible version of _configure_features (#271)
This PR fixes the bug introduced in https://github.com/bazelbuild/rules_foreign_cc/pull/270.

hlopko@ should not be allowed to code undercaffeinated.
2019-05-28 10:55:13 +02:00
Marcel Hlopko 604f1e1c9f Guard cc_common.configure_features with a version check (#270)
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 :)
2019-05-28 10:31:58 +02:00
Marcel Hlopko 9c6480858a Migrate for incompatible_require_ctx_in_configure_features (#260)
This PR migrates rules_foreign_cc for bazelbuild/bazel#7793
2019-05-10 15:51:44 +02:00
irengrig bf99a0bf00
Fix #254 (Linker flags passed to ar). (#256)
Fix #254 (Linker flags passed to ar).
2019-05-10 15:49:21 +02:00
irengrig f00cd27f06
Pass --copt, --cxxopt, --conlyopt, --linkopt to cmake_external/configure_make rules (#235)
- 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
2019-03-11 16:50:39 +01:00
irengrig bcb7a345f7
Remove support for the versions of Bazel before 0.22 (#234)
- as 0.23 is already released
- to have only one variant of framework code
2019-03-11 16:34:56 +01:00
irengrig d6d2f0761a
Adapt to the new Starlark API. (#157)
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
2018-11-27 10:06:23 +01:00
irengrig b3552bfef8
Fix dynamic libraries (#141)
* 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
2018-10-23 16:49:20 +02:00
irengrig 0d5f5c2da7
Replace cc_common.create_symlink_library_to_link calls (#117)
... with cc_common.create_library_to_link
2018-10-02 12:39:58 +02:00
irengrig 8dca26ac29
Pass the value of --compilation_mode dbg to the rule and to CMake (#96)
CMAKE_BUILD_TYPE=DEBUG (otherwise RELEASE)
Can be overriden by user passing CMAKE_BUILD_TYPE in cache_entries
2018-09-14 10:18:38 +02:00
irengrig 169cdca87b
More corrections for building on Windows (#89)
* Get cc_toolchain environment variables also for linking

* Correct environment setup

* Add Windows tests for Ninja and NMake generators
2018-09-12 15:20:31 +02:00
irengrig 06970670ae
Correct checking the shared library to also filter out empty values (#82) 2018-09-10 11:22:39 +02:00
irengrig 515c15a392
Add a feature of generating CMake toolchain file and writing tools and flags information there (#70)
* 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
2018-08-30 13:12:51 +02:00
irengrig 86b28882a2
correct work in osx: take environment from cc_common (#67)
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
2018-08-28 13:36:20 +02:00
irengrig 97b339b91e
escape quotes in toolchain flags and variables (#66) 2018-08-28 11:52:10 +02:00
irengrig 85b4e59103
correct bugs with shared and interface libs in cc_toolchain_util.bzl (#38) 2018-08-20 16:46:24 +02:00
irengrig 067d4be22e
use tools paths and flags from the toolchain (#7)
* 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.
2018-08-06 15:23:18 +02:00