You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Collect .lo files from dependencies as binaries in apple_framework_pa… (#943)
…ckaging
When `alwayslink` is `True`, `objc_library` can produce an `.lo` file
instead of an `.a` file.
From the `cc_library` docs (which I believe also apply to
`objc_library`):
https://bazel.build/reference/be/c-cpp#cc_library
> Use cc_library() for C++-compiled libraries. The result is either a
.so, .lo, or .a, depending on what is needed.
>
> If you build something with static linking that depends on a
cc_library, the output of a depended-on library rule is the .a file. If
you specify alwayslink=True, you get the .lo file.
>
> The actual output file name is libfoo.so for the shared library, where
foo is the name of the rule. The other kinds of libraries end with .lo
and .a, respectively. If you need a specific shared library name, for
example, to define a Python module, use a genrule to copy the library to
the desired name.
I'm not 100% sure if this is valid (does a .framework bundle with an .lo
file as its binary make sense?), and the non-VFS codepath that [uses
libtool to merge the `objc_library` and `swift_library` binary might
break](https://github.com/bazel-ios/rules_ios/blob/f7dcd0c4f90985495bba517dc8cc7d86ce7f7632/rules/framework/framework_packaging.py#L19).
But if [no binary is set in the `AppleBundleInfo` provider,
`rules_xcodeproj` treats `apple_framework_packaging` targets as
unsupported.](https://github.com/MobileNativeFoundation/rules_xcodeproj/blob/41929acc4c7c1da973c77871d0375207b9d0806f/xcodeproj/internal/automatic_target_info.bzl#L497)
0 commit comments