This change introduces support for building libc++abi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Basically lgtm, some questions about the declare_args (mirroring https://reviews.llvm.org/D60253#1456632 a bit)
llvm/utils/gn/secondary/libcxxabi/src/BUILD.gn | ||
---|---|---|
5 ↗ | (On Diff #194050) | Does this one have to be settable? That seems like an implementation detail from a distance. |
17 ↗ | (On Diff #194050) | Wouldn't you always want this? What's an example where one would want to statically link c++abi but export its symbols? They only thing I can think of is when linking it into libc++.dylib, which which case we probably want a toggle for that instead? Why is the default false? Why is this settable? |
38 ↗ | (On Diff #194050) | no trailing " |
LLVM uses CMake as a build system, and we should not start checking-in support for other build systems. This sort of thing is what's fine to keep downstream only, otherwise there's an implication that upstream should somehow support that build system, which isn't the case. For example, when we make a change to CMake, we don't want to have to update the gn-based build system.
Similarly, we use a Xcode project to build libc++/libc++abi/libunwind, but we don't check those in upstream (and I've been working hard to switch us over to the CMake build, actually).
Hmm, sorry, I missed the fact that there was already this support for other components. Well, as long as there's no assumption that we'll maintain this in any way, I'm not concerned with this.
For those without context, it would be really helpful if every GN commit had a link to documentation about what GN is, and how LLVM supports it. The initial commit had a note, maybe the LLVM docs should have this?
llvm/utils/gn/README.rst has a readme with links etc. It explicitly mentions that this build config is unsupported and that there's no expectation to keep that build up to date, as requested by ldionne.
I thought it would remove it upon resigning from the revision. I accepted the revision since there didn't seem to be a way of just removing my "request for changes". Please ignore my approval, too.
llvm/utils/gn/secondary/libcxxabi/src/BUILD.gn | ||
---|---|---|
5 ↗ | (On Diff #194050) | We have a concrete use case for this in Fuchsia where we build multiple different variants of libc++ using the multilib layout, including one without exceptions support, see D60926. |
17 ↗ | (On Diff #194050) | I've tried to match the CMake build where this is disabled by default. I agree with your reasoning but I'm not sure whether we want to deviate from the CMake build? |
llvm/utils/gn/secondary/libcxxabi/src/BUILD.gn | ||
---|---|---|
17 ↗ | (On Diff #194050) | I think it's fine to deviate from CMake where it makes sense.
So if that's the only reason this is the way it is, I think it's fine to change it if you agree that that makes sense. |
llvm/utils/gn/secondary/libcxxabi/src/BUILD.gn | ||
---|---|---|
17 ↗ | (On Diff #194050) | It depends on the expected use case. If you want to build static libc++abi so you can link it into the shared libc++, then you want this option to be disabled. If you want to build static libc++abi so you can distribute it as an archive, you probably want it enabled. It seems like CMake build is optimized for the former, but in practice I'd argue that the latter is more common so I'm fine making that the default. |
Sorry, didn't realize I hadn't accepted this yet. lgtm with the change you had suggested below.
llvm/utils/gn/secondary/libcxxabi/src/BUILD.gn | ||
---|---|---|
17 ↗ | (On Diff #194050) | Sounds good. |