So that you can use select statements on it. The current modivation
is to convert a module from make to bp with minimal soong config
variable boilerplate.
Bug: 342006386
Bug: 346922064
Test: m nothing --no-skip-soong-tests
Change-Id: I48d5a11ad3aa65c24cc199458634a5fdbeab2f64
To handle static inline functions, bindgen generates a C file which is
expected to be compiled and linked into dependents on the generated
bindgen source.
This CL adds support for cc modules ingesting this output and for
bindgen to produce it (and link it against the bindgen rust_library
variant as well).
Bug: 290347127
Test: m blueprint_tests
Test: Example module with static inline functions builds locally
Change-Id: I167a8356eb6e0059fc21169fd3bfc6bf4d9c812f
Adds support for bindgen to be able to handle `static inline`
functions. This is done by adding a new boolean field to the `BindgenProperties`
struct, `Handle_static_inline` (default to false).
If this field is true, then the flags to trigger bindgen support of
static inline functions are passed in.
The rust-bindgen documentation list two ways of handling `static inline`
functions, both specified with command line args.
1) --generate-inline-functions
2) --experimental --wrap-static-fns
Option 1 requires some extra effort on the part of the C library developer, in
that they have to expose the function symbols: the docs (linked below) explain
that this is often done by compiling the library with inlining disabled, which
can be detrimental to performance.
Option 2 requires no effort on the part of the C library developer, but it does
require the `--experimental` flag, since this feature is still under development.
This CL goes with option 2.
Relevant docs: https://github.com/rust-lang/rust-bindgen/discussions/2405
This CL also adds a new test: TestBindgenHandleStaticInlining in bindgen_test.go
Test: m blueprint_tests
Change-Id: If28000e3f3ccecc65c4cae1c62d7bf455454239a
Static libraries were being appended to the list of header library
dependencies. They should not be. This also makes sure we track them
appropriately in Make.
Test: m blueprint_tests
Change-Id: Ifa664f09fe2102aea57d22cbaaeba71f0c26074d
UseVndk is a function to check if the module can use VNDK libraries, but
this function was also used to check if the module is installed in the
treblelized partition (vendor or product). As of VNDK deprecation,
UseVndk funtion will return false even when the module is installed in
vendor / product partition, so we need a separated function to check
this. This change introduces a new function 'InVendorOrProduct' which
replaces UseVndk based on its usage.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Change-Id: Ic61fcd16c4554c355f6005894a4519b044b27fe5
cc modules can use __ANDROID_VENDOR_API__ to read BOARD_API_LEVEL
that is the API level of the vendor surface.
Bug: 313822931
Test: check ninja commands to have -D__ANDROID_VENDOR_API__=<version>
Change-Id: Iceb5918cbfce0f24929d02d7e3caf1e9942b88e8
rust_bindgen modules which defined cpp_std with a .h file were not
correctly emitting the `-x c++` flag. This CL addresses that, and
ensures that if either cpp_std or c_std is set then the appropriate
behavior occurs no matter the file extension.
Bug: 304269101
Test: Soong tests
Change-Id: I71a8ae30ac0ed502d9d3fbf2f3039b0c56529d39
For device build, rust defaults to dylib linkage for rustlibs deps. `dylibs` prop was provided for flexibility.
By removing it, we're enforcing users to either use the default linkage (dylibs for device and rlibs for host) or rlibs prop explicitly. This means no dylibs for host modules. This makes sense because host modules always uses rlib linkage against libstd. The flexibility with dylibs prop opened room for linkage collisions because the dependencies don't link against libstd the same way.
Test: go test
Change-Id: I2fc221daa8a9bb42bdcf6d9823c723a4ddabe7b5
Add a new Bindgen_flag_files property to bindgen modules
that let users specify files that contain extra flags for
bindgen.
Bug: 242243245
Test: presubmit
Change-Id: I21d987c08ac417c04aaa3bfb3b75d563fc662d5b
Switch custom_bindgen to use any HostToolProvider
instead of just Rust modules, so any host binary can
be used as the bindgen wrapper.
Bug: 242243245
Test: presubmit
Change-Id: I9ba189b2857b3049dcf14842c178ce5846bab2f7
Currently, Bazel sets __ANDROID_APEX_MIN_SDK_VERSION__ based on the cc library's min_sdk_version while Soong does based on apex's min_sdk_version. This causes a diff in the clang commands.
Digging further, we realized __ANDROID_APEX_MIN_SDK_VERSION__ isn't used anywhere so we might just delete it altogether instead of fixing it.
Bug: 265134933
Test: presubmit
Change-Id: I08e89dc8f6ef86669248ea5c47de6603e9d2ffbb
Musl libclang.so is in musl/lib, not musl/lib64.
Bug: 216192129
Test: m USE_HOST_MUSL=true host-native -k
Change-Id: Id12630d5c0f51d85278f8562b3d988458a56021a
Generated bindings are intended to be slim translation layers, usually
consisting of nothing more than type signatures and constants.
Generally, they should also be used in exactly one location by the safe
wrapper for these bindings. By preventing them from building as
`dylib`s, we avoid the per-library overhead of these non-reused pieces
of code.
Additionally, default visibility restrict all bindgen modules to their
subpackages. This is being done both:
* to encourage use of a single safe bindings crate
* to avoid diamond dependency graphs with mixed rlib/dylib dependencies
Bug: 166332519
Test: m; Make sample module use dylib bindgen dependency, see build failure.
Change-Id: I8e9d9cb851c2ec99f4ed63e6e18c4ba26b29721c
Building rust code with musl enabled can load proc macro crates built
against musl into rustc, so we have to use a version of rustc also
built against musl.
Bug: 216192129
Test: m USE_HOST_MUSL=true host-native
Change-Id: Icd23b542a4b64a975850a8a4bb4b69183cc6c2c6
Add a rust toolchain for musl libc, use std library built from source,
and add default dependencies on musl libc.
Bug: 216192129
Test: m USE_HOST_MUSL=true host-native
Change-Id: Ic5ff4487db9693aeb08a13405f4d18465eecdc4b
rust_bindgen calls are missing a large set of -D cflags which control
how headers are interpretted for certain variations (such as
-D__ANDROID_VNDK__). This CL introduces the full set of these flags.
Bug: 205609024
Test: rust_bindgen vendor variant builds correctly.
Change-Id: Id781c1f88352e9c238c49619f0dce20f804cfc77
Rename the ninja variables that have an extraneous Clang in the name,
since there are no longer any non-Clang variables.
Bug: 68947919
Test: no change to command lines used to build mmma bionic
Change-Id: I081d5e1d423a66d55faece6cb1d265cd5e504d5f
Remove cflags that are not handled by clang from the global defaults,
and remove calls to ClangFilterUnknownCflags.
Squash lists of clang-specific default flags into the main default
flags lists.
Rename Toolchain.Clang*flags to Toolchain.*flags.
Rename Go variables with Clang in the name that have no non-Clang
equivalent.
Remove unused ninja variables.
Bug: 68947919
Test: no change to build.ninja for aosp_cf_x86_64_phone-userdebug or aosp_crosshatch-userdebug
Change-Id: Id287945315d53e5eaef197adbbb4f1302f2e3680
The set of Clang flags passed to bindgen from the toolchain was
incomplete. In addition to ToolchainClangCflags(), we also need to call
ClangCflags().
Bug: 184081465
Test: m libgrpc_bindgen
Change-Id: I0b62345fee2f55ba18b4a0c4d825f0447c99db06
Custom_bindgen is handled by adding a relevant dependency tag.
Flags and Ld_flags are not paths/references to other modules.
Test: go test soong tests
Change-Id: Ic6a69521102318b3b9f29b59560bcefbc9aff8fa
Rustc unstable option "link-native-libraries" is used to prevent the
linkage of other libraries via the #[link] directive. Add a dependency
to libclang_rt.builtins, similarly to cc.
Bug: 141331117
Test: lunch aosp_crosshatch-userdebug; m
Change-Id: I5c232291a5dd08a99e6a12a1295e30bb8e4fcaf1
This is useful when experimenting with new compiler flags that the
existing compiler does not support.
Change-Id: I45b8a2980b247d60a7f4e2ba55169267aeceef2b
