This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] Move CMake file to src, avoid using globs
ClosedPublic

Authored by phosek on Apr 29 2019, 12:58 PM.

Details

Summary

This addresses the longstanding FIXME and makes libc++ build more
similar to other runtimes. This is also necessary to enable the use
of script for synchronizing source lists between the CMake and GN
builds which relies on explicit source lists.

Diff Detail

Repository
rCXX libc++

Event Timeline

phosek created this revision.Apr 29 2019, 12:58 PM
thakis accepted this revision.Apr 29 2019, 6:09 PM

I'd remove the GN build bits from the CL description. The GN build shouldn't be motivation for changing anything in CMake land since it's not supported. But I think it's a good change on its own. I'm not a libc++ code owner, so wait for one of mclow or ericwf or ldionne too.

This revision is now accepted and ready to land.Apr 29 2019, 6:09 PM
EricWF accepted this revision.Apr 30 2019, 12:05 AM

LGTM.

As the CMake docs suggest, we should never have been doing this.
Thanks for cleaning it up.

ldionne accepted this revision.Apr 30 2019, 8:42 AM

I just landed https://reviews.llvm.org/D60969, this may need rebasing.

Last time this came up, we wanted to implement a check to ensure no source files were forgotten, as in do a glob and compare to the explicit list of files. The original plan was to use llvm_process_sources for that, but we couldn't do that cos libc++'s build can't rely on LLVM being around yet (though maybe we ought to reconsider that at some point with the upcoming monorepo move...). Do you think it's worth implementing that?

Last time this came up, we wanted to implement a check to ensure no source files were forgotten, as in do a glob and compare to the explicit list of files.

Is it possible to forget a file, without it failing some lit test?
Are globs used elsewhere in llvm's cmake for this reason? I hope not. I don't remember it causing much issues.

The original plan was to use llvm_process_sources for that, but we couldn't do that cos libc++'s build can't rely on LLVM being around yet (though maybe we ought to reconsider that at some point with the upcoming monorepo move...).

Passing-by 2 cent: that seems like an unreasonably high price for an insufficiently motivating reason.

Do you think it's worth implementing that?

[...]
The original plan was to use llvm_process_sources for that, but we couldn't do that cos libc++'s build can't rely on LLVM being around yet (though maybe we ought to reconsider that at some point with the upcoming monorepo move...). Do you think it's worth implementing that?

Whatever we do, I think it's important not to assume that all of LLVM is around for building libc++. The standalone build currently works well without LLVM around (actually, better than the non-standalone one because LLVM pollutes global CMake variables), and I think we should keep that working.

Last time this came up, we wanted to implement a check to ensure no source files were forgotten, as in do a glob and compare to the explicit list of files.

Is it possible to forget a file, without it failing some lit test?
Are globs used elsewhere in llvm's cmake for this reason? I hope not. I don't remember it causing much issues.

The original plan was to use llvm_process_sources for that, but we couldn't do that cos libc++'s build can't rely on LLVM being around yet (though maybe we ought to reconsider that at some point with the upcoming monorepo move...).

Passing-by 2 cent: that seems like an unreasonably high price for an insufficiently motivating reason.

Do you think it's worth implementing that?

llvm_process_sources gets used implicitly all over LLVM's build system, and it implements the glob check. We don't use globs to construct the actual source list, just to verify it.

I agree that llvm_process_sources by itself isn't enough reason to introduce an LLVM dependency in libc++'s build system, but the general sentiment at the time was that we wanted to share more build infrastructure as well.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 30 2019, 11:38 PM