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
It would be great to have bitcode support added to the sample.
From the research I had earlier, it's the -fembed-bitcode flag that has to be added to compiler and linker flags.
I tried it before, but I think I may have missed couple options, like Swift compiler flags or maybe even ldflags (?).
Ideally, the bitcode option should be an on/off option in .buckconfig, which could then be controlled from command line.
The reason: to be able to build different projects in monorepo with and without bitcode.
We actually have a setup, where one app can enable bitcode but another one cannot (due to 3-rd party pre-built binary missing bitcode).
I think building with/without bitcode, would mean that different cache directory should be used.
Or, what I tried as well, everything that can be built with bitcode, should be built with bitcode, but then when, say a library, is used in an app that doesn't support bitcode, the bitcode can be stripped out of the binary. That, or each library can generate two artifacts, one with bitcode, one stripped, so then the apps/target products can pick the one fitting their needs.
The text was updated successfully, but these errors were encountered:
It would be great to have bitcode support added to the sample.
From the research I had earlier, it's the
-fembed-bitcode
flag that has to be added to compiler and linker flags.I tried it before, but I think I may have missed couple options, like Swift compiler flags or maybe even
ldflags
(?).Ideally, the bitcode option should be an on/off option in
.buckconfig
, which could then be controlled from command line.The reason: to be able to build different projects in monorepo with and without bitcode.
We actually have a setup, where one app can enable bitcode but another one cannot (due to 3-rd party pre-built binary missing bitcode).
I think building with/without bitcode, would mean that different cache directory should be used.
Or, what I tried as well, everything that can be built with bitcode, should be built with bitcode, but then when, say a library, is used in an app that doesn't support bitcode, the bitcode can be stripped out of the binary. That, or each library can generate two artifacts, one with bitcode, one stripped, so then the apps/target products can pick the one fitting their needs.
The text was updated successfully, but these errors were encountered: