-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement C++ Starlark API #4570
Comments
Working towards #4570. RELNOTES:none PiperOrigin-RevId: 205274676
Bazel@HEAD now accepts |
Is there a better way to traverse the API than Would like to see if it better fits bazelbuild/rules_rust#108 |
Working towards bazelbuild#4570. RELNOTES:none PiperOrigin-RevId: 205274676
CcLinkingHelper has new functionality to support transitive linking. This is not exposed to Skylark yet. GitHub issue #4570 RELNOTES:none PiperOrigin-RevId: 213824305
*** Reason for rollback *** b/116592380 *** Original change description *** C++: Make cc_binary's linking go through CcLinkingHelper. CcLinkingHelper has new functionality to support transitive linking. This is not exposed to Skylark yet. GitHub issue #4570 RELNOTES:none PiperOrigin-RevId: 214451346
CcLinkingHelper has new functionality to support transitive linking. This is not exposed to Starlark yet. GitHub issue #4570 This was rolled back because in the refactoring I started passing headers to the linking action that were not passed before. These headers have mistakes and cannot be pre-processed, so when they were passed as inputs to the linking action, the compilation action was executed whereas before it wasn't. Fixed and added test to make sure the behavior is the same as before. RELNOTES:none PiperOrigin-RevId: 214785687
*** Reason for rollback *** Breaks nightly *** Original change description *** C++: Remove more CcLinkParams Tracking: bazelbuild#4570 RELNOTES:none PiperOrigin-RevId: 229584100
Tracking: bazelbuild#4570 Fixes conversion bug from old API to new that was already present before the original CL but was only triggered with it. RELNOTES:none PiperOrigin-RevId: 229910560
*** Reason for rollback *** b/123103413. *** Original change description *** C++: Remove more CcLinkParams Tracking: bazelbuild#4570 Fixes conversion bug from old API to new that was already present before the original CL but was only triggered with it. RELNOTES:none PiperOrigin-RevId: 230094550
Working towards bazelbuild#4570 RELNOTES:none PiperOrigin-RevId: 230526082
Working towards #4570 RELNOTES:none PiperOrigin-RevId: 232843780
This required looking at the rule context and we want to stop doing that from behind the C++ Starlark API. This was only used by one target in the depot that is broken anyway. Temporarily in case this breaks anyone in Bazel, rather than using an incompatible flag, we can fix anyone broken by this using a rule feature. If no one complains, this replacement will be removed in a later release. #4570 RELNOTES:none PiperOrigin-RevId: 232848408
No instances of RuleContext left. #4570 RELNOTES:none PiperOrigin-RevId: 233590830
Bazel 0.22 contains further updates to the new C++ API: bazelbuild/bazel#4570 It seems these removed access to the unmangled library names for C library dependencies. On MacOS dynamic libraries contain the path to the unmangled library in their "library name", which means that targets linking against these dynamic libraries will reference the unmangled target. We need to patch them to instead refer to the mangled target relative to `@rpath`. As we no longer have access to the unmangled targets, we can no longer easily patch the targets. Furthermore, GHC generates intermediate dynamic libraries which will try to load the unmangled libraries. Without them available, we cannot make this step pass sucessfully. We work around this by copying and patching the link library dependencies to change their "library name" to the mangled name relative to `@rpath`. Then we no longer need to patch the targets depending on these libraries, as the linker will write the correct linking commands into them.
Bazel 0.22 contains further updates to the new C++ API: bazelbuild/bazel#4570 It seems these updates removed access to the unmangled library names for C library dependencies. On MacOS, dynamic libraries contain the path to the unmangled library relative to the working directory in their "library name", which means that targets linking against these dynamic libraries will reference the unmangled target. These references are invalid if a binary is executed in a different working directory, and are unnecessarily long, which makes it easy to exceed the MACH-O header size limit on MacOS. Previously, rules_haskell would patch these load commands based on the unmangled libraries to point to the mangled libraries under a single RPATH entry. This shortened the load commands. Now that the unmangled libraries are no longer available, this patching is performed in a [linker wrapper script][osx_wrapper], similar to how Bazel itself handles this. Furthermore, GHC generates intermediate dynamic libraries which will try to load the unmangled libraries. The wrapper script approach allows to patch the intermediate library with additional RPATHs to avoid load failures during GHC compilation steps. The Hazel target for the swagger2 library, for example, triggers this issue. [osx_wrapper]: https://github.com/bazelbuild/bazel/blob/6aab2719d678057c4ef8edc3dfcad56803454732/tools/cpp/osx_cc_wrapper.sh.tpl.
Bazel 0.22 contains further updates to the new C++ API: bazelbuild/bazel#4570 It seems these updates removed access to the unmangled library names for C library dependencies. On MacOS, dynamic libraries contain the path to the unmangled library relative to the working directory in their "library name", which means that targets linking against these dynamic libraries will reference the unmangled target. These references are invalid if a binary is executed in a different working directory, and are unnecessarily long, which makes it easy to exceed the MACH-O header size limit on MacOS. Previously, rules_haskell would patch these load commands based on the unmangled libraries to point to the mangled libraries under a single RPATH entry. This shortened the load commands. Now that the unmangled libraries are no longer available, this patching is performed in a [linker wrapper script][osx_wrapper], similar to how Bazel itself handles this. Furthermore, GHC generates intermediate dynamic libraries which will try to load the unmangled libraries. The wrapper script approach allows to patch the intermediate library with additional RPATHs to avoid load failures during GHC compilation steps. The Hazel target for the swagger2 library, for example, triggers this issue. [osx_wrapper]: https://github.com/bazelbuild/bazel/blob/6aab2719d678057c4ef8edc3dfcad56803454732/tools/cpp/osx_cc_wrapper.sh.tpl.
Also exposes additional methods in the API: merge_compilation_outputs and create_compilation_outputs #4570 https://docs.google.com/document/d/1cRRdHOPTTUXBbq9Cj9hk_WLnPqsGtAoQynYd7TKBQI8/edit?disco=AAAACkgMw7E RELNOTES:none PiperOrigin-RevId: 245731814
It's not yet clear whether the API is enough for languages other than C++. Therefore, remove language parameter documentation from the API. #4570 RELNOTES:none PiperOrigin-RevId: 245910010
The code was crashing on preconditions when passing wrong extensions for srcs and hdrs attribute in the C++ compile() API. #4570 RELNOTES:none PiperOrigin-RevId: 245925608
It's not yet clear whether the API is enough for languages other than C++. Therefore, remove language parameter documentation from the API. bazelbuild#4570 RELNOTES:none PiperOrigin-RevId: 245910010
#4570 RELNOTES:none PiperOrigin-RevId: 245947851
Bugs fixed: - Creating static libraries during transitive link - Could not return None from linking_outputs' executable or library_to_link - Null pointer exception when not passing compilation_outputs to link() #4570 RELNOTES:none PiperOrigin-RevId: 245956660
#4570 RELNOTES:C++ Starlark API for compilation and linking is no longer whitelisted PiperOrigin-RevId: 245964332
Sandwich is ready: |
Hey @oquenchil . How to pass data to CcModule.java:290
Currently it is being calculated to "ignored", producing command line like (Windows): Repro case is here: |
Also, dynamic libraries in
|
*** Reason for rollback *** b/123103413. *** Original change description *** C++: Remove more CcLinkParams Tracking: bazelbuild/bazel#4570 Fixes conversion bug from old API to new that was already present before the original CL but was only triggered with it. RELNOTES:none PiperOrigin-RevId: 230094550
Tracking: bazelbuild/bazel#4570 Fixes conversion bug from old API to new that was already present before the original CL but was only triggered with it. RELNOTES:none PiperOrigin-RevId: 229910560
*** Reason for rollback *** Breaks nightly *** Original change description *** C++: Remove more CcLinkParams Tracking: bazelbuild/bazel#4570 RELNOTES:none PiperOrigin-RevId: 229584100
Tracking: bazelbuild/bazel#4570 RELNOTES:none PiperOrigin-RevId: 229181236
bazelbuild/bazel#4570 RELNOTES:none PiperOrigin-RevId: 227522672
Remove the flag for parts of the API that are stable. bazelbuild/bazel#4570 RELNOTES: None. PiperOrigin-RevId: 227516883
Description of the problem / feature request:
The API should expose to Skylark from Java the logic for the creation of compilation and linking actions.
Feature requests: what underlying problem are you trying to solve with this feature?
The main problem to solve is inter-operability between different rules/languages that have dependencies on C++ code.
Design doc:https://docs.google.com/document/d/1cRRdHOPTTUXBbq9Cj9hk_WLnPqsGtAoQynYd7TKBQI8/edit?disco=AAAACkgMw7E
The text was updated successfully, but these errors were encountered: