This is an archive of the discontinued LLVM Phabricator instance.

[CMake][runtimes] Add file level dependency to merge_archives commands
ClosedPublic

Authored by zero9178 on Mar 6 2021, 2:12 PM.

Details

Reviewers
ldionne
phosek
Group Reviewers
Restricted Project
Restricted Project
Commits
rG6359049c3504: [CMake][runtimes] Add file level dependency to merge_archives commands
Summary

Both libc++ and libc++abi have options of merging with another archive. In the case of libc++abi, libunwind can be merged into it and in the case of libc++, libc++abi can be merged into it.

This is realized using add_custom_command with POST_BUILD and the usage of the CMake generator expression TARGET_LINKER_FILE in the arguments. For such generator expressions CMake doc states: "This target-level dependency does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled" [1]

This patch adds a DEPENDS argument to both add_custom_command invocations so that the archives also have a file-level dependency on the target they are merging with. That way, changes in say, libunwind source code, will be updated in the libc++abi and/or libc++ static libraries as well.

[1] https://cmake.org/cmake/help/v3.20/command/add_custom_command.html

Diff Detail

Event Timeline

zero9178 created this revision.Mar 6 2021, 2:12 PM
zero9178 requested review of this revision.Mar 6 2021, 2:12 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMar 6 2021, 2:12 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript

Im afraid I dont understand the purpose of this change. libunwind isn't meant to be merged into libc++/libc++abi. The reasoning for libc++ to support merging libc++abi doesn't really apply to libunwind IMO. Can you please elaborate what exactly the reasoning for this is?

zero9178 added a comment.EditedMar 8 2021, 11:02 AM

Im afraid I dont understand the purpose of this change. libunwind isn't meant to be merged into libc++/libc++abi. The reasoning for libc++ to support merging libc++abi doesn't really apply to libunwind IMO. Can you please elaborate what exactly the reasoning for this is?

The option to merge libunwind into libc++abi has already existed prior to this patch since roughly 3 years. It's use case is mainly for static linking all parts of the runtime. The current implementation was created here: https://reviews.llvm.org/D60173 and the first implementation I could find that contained a discussion around the feature is here https://reviews.llvm.org/D39949.

What this patch adds is a simple file level dependency. If one was eg. doing incremental release builds and the sources of libunwind change, libunwind gets obviously rebuild. Currently, this would not lead to the merge script being run, therefore leading to any users of the toolchain working with an outdated version of libunwind inside of libc++abi. Likewise with libc++abi and libc++.

This patch simply adds a file level dependency, as is suggested by the cmake documentation, so that changes to libunwind would get merged into libc++abi and likewise with libc++abi into libc++.

Im afraid I dont understand the purpose of this change. libunwind isn't meant to be merged into libc++/libc++abi. The reasoning for libc++ to support merging libc++abi doesn't really apply to libunwind IMO. Can you please elaborate what exactly the reasoning for this is?

Since 058c04c3ddecb4ecc81655c91b7aa0e7a5ef0ab1 libcxxabi has explicit options for merging in libunwind. And while not strictly needed in the same sense as libcxxabi + libcxx, I can see that it could be convenient.

phosek accepted this revision.Mar 8 2021, 11:23 AM
phosek added a subscriber: phosek.

LGTM from me as the author of D60173.

Ping. I believe I also need approval from libc++ maintainers.

ldionne accepted this revision.Mar 18 2021, 10:42 AM
This revision is now accepted and ready to land.Mar 18 2021, 10:42 AM