Add use_runfiles aspect_hint to include runfiles for specific cc_libr…

[gkoreman]

Fixes #2477

Include all data from cc_libraries as runfiles or resources, depending on aspect_hints.
Provide aspect_hints for resource collection for all resource targets (eg, swift_library, cc_library, etc)

By default all data is now included from cc_libraries as runfiles and follows the expected runfiles folder structure, with files retaining their nested folders and being placed in /external/pkg_name/some/file.txt when included from a http_archive or local_repository.

The default behavior for other resource collecting targets like swift_library has not changed, and will continue to collect and process data as resources.

To allow modification of this default behavior, users may add aspect_hints to the target cc_library/swift_library/etc. There are three supported aspect_hints:
@build_bazel_rules_apple//apple:use_runfiles
@build_bazel_rules_apple//apple:use_resources
@build_bazel_rules_apple//apple:suppress_resources

Example

Here is an example of modifying the default behavior to bundle data.txt as a resource instead of a runfile.

cc_library(
    name = "libapp",
    srcs = ["main.cpp",],
    data = [":data.txt"],
    aspect_hints = ["@build_bazel_rules_apple//apple:use_runfiles"],
)

macos_application(
    name = "app_macos",
    deps = [":libapp"],
)

data.txt is bundled in Contents/Resources/data.txt

Note

Hints apply only to the target and do not affect transitive deps, however if a target includes runfiles then all runfiles are bundled (including transitive runfiles) regardless of the hints applied to transitive targets.

[brentleyjones]

I would like to flip the default, such that runfiles are collected by default for cc_library (but only it and the rules that currently don’t collect resources), and you need to use the aspect hint to make new rules collect resources instead. This will make it so the least number of people targets to use aspect hints. We will then need another aspect hint that tells the currently support resource collection rules to use runfiles instead. And we can have it be a build error when both are provided.

[luispadron]

Sweet! Left some comments I think we should address.

You'll also need to re-run buildifier as we updated the version and it adds more lints/formatting fixes

[luispadron]

@brentleyjones Would you have some time to review this as well? Thank you!

[gkoreman]

Runfiles are only placed in the root folder if that is where they exist in the workspace so it is unlikely that there will be conflicts. In simple projects I would expect this not to be an issue because the user will likely choose either to use runfiles or resources but not both. Larger projects with more complex transitive runfiles will have those files end up in subdirectories anyway so there shouldn’t be an issue there either.

…

On Tue, Aug 6, 2024 at 6:11 AM Brentley Jones ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In apple/internal/aspects/resource_aspect_hint.bzl <#2479 (comment)> : > + +By default a cc_library will add its runfiles to the Contents/Resources folder of a +`macos_application`. To alter this behavior and have it collect resources instead +you can add this pre-built aspect hint. This will cause resources to be collected +and processed like objc_library. + +```build +# //my/project/BUILD +cc_library( + name = "somelib", + data = ["mydata.txt"], + aspect_hints = ***@***.***_bazel_rules_apple//apple:use_resources"], +) +``` + +#### Collect runfiles of a objc_library Yeah, maybe. I'm just concerned with these files overiding/shadowing data files. Especially on iOS where there is no Resources folder, it's just in the root bundle. Maybe it's not an issue though? — Reply to this email directly, view it on GitHub <#2479 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE6Z6EDWWG4HF5UEOUCCHTZQDDPLAVCNFSM6AAAAABJ5EW6ECVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDEMRRGI3DONJTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>