<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 25, 2020, at 19:29, Stephen Neuendorffer <<a href="mailto:stephen.neuendorffer@gmail.com" class="">stephen.neuendorffer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="">I'd be interested to know what you think of this proposal, which is on the same lines: <a href="https://reviews.llvm.org/D85140" class="">https://reviews.llvm.org/D85140</a></div></div></div></blockquote><div><br class=""></div><div>I think that's interesting, but it's somewhat orthogonal to what I was talking about IIUC. Your proposal revolves around standardizing some of the parameters used to customize the build of various LLVM projects, whereas what I was suggesting is standardizing how different LLVM projects (only the runtimes to be specific) link against base system libraries.</div><div><br class=""></div><div>I also don't think that a standardization like the one proposed in D85140 makes sense for all projects. For example, it doesn't strike me that it makes sense for the runtime projects to have a (e.g.) LIBCXX_INSTALL_UTILS CMake variable. It might make sense for some other projects though.</div><div><br class=""></div><div>Louis</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Steve</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 7:03 AM Louis Dionne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2020, at 23:52, Petr Hosek <<a href="mailto:phosek@chromium.org" target="_blank" class="">phosek@chromium.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">Using more interface libraries is definitely the right direction and a modern way to use CMake. I'm not sure if we can get to a single interface target since different runtimes have different requirements. I was assuming that we would have one interface target per dependency and use the existing CMake support where it already exists, for example use the FindThreads module to handle pthreads.</div><div class=""><br class=""></div><div class="">I mostly want to ensure that we're not letting the perfect be the enemy of the good. We've been talking about more major CMake refactorings for some time, but we haven't made much progress so far, partially because nobody has a clear idea what the end state is going to look like. I think that this proposal can be implemented pretty quickly (it's mostly just a bunch of grep & sed) and while it's not the end state we want, it's a stepping stone which would make an immediate impact on users. After this change, we can start introducing interface targets and later factoring those out once we make more progress on setting up the common CMake infrastructure. Does that make sense?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Sure, I agree. It is indeed difficult to make time for (and justify) improving to the build system. I'll take a look if you send a patch.</div><div class=""><br class=""></div><div class="">Louis</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">On Tue, Sep 22, 2020 at 12:42 PM Louis Dionne <<a href="mailto:ldionne@apple.com" target="_blank" class="">ldionne@apple.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 22, 2020, at 15:28, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">From the "not largely affected" camp:<br class=""><div class=""><br class=""></div><div class=""> - the churn doesn't feel that major for HAS_ and ...</div><div class=""> - the uniformity feels nice</div><div class=""><br class=""></div><div class="">and in general feels nice and in pursuit of the longer term goals here. </div><div class=""><br class=""></div><div class="">-eric</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 22, 2020 at 11:58 AM Petr Hosek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">We've been using the runtimes build for a while now and we're very happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks.<div class=""><br class=""></div><div class="">When running checks like check_c_compiler_flag, check_cxx_compiler_flag or check_library_exists, CMake caches the resulting variable and doesn't run the check again. The problem is that in LLVM, each subproject uses different variable names for results of these checks. For example, most subprojects check if pthread is available and store the result in:</div><div class=""><br class=""></div><div class=""></div><div class="">COMPILER_RT_HAS_LIBPTHREAD (compiler-rt)</div><div class="">LIBCXX_HAS_PTHREAD_LIB (libc++)<br class=""></div><div class="">LIBCXXABI_HAS_PTHREAD_LIB (libc++abi)<br class=""></div><div class="">LIBUNWIND_HAS_PTHREAD_LIB (libunwind)<br class=""></div><div class="">HAVE_LIBPTHREAD (llvm)<br class=""></div><div class=""><br class=""></div><div class="">This means that even though this check would ideally be performed just once (per target) and reused everywhere, it's performed 5 times. The same is true for most flags and library checks.</div><div class=""><br class=""></div><div class="">I think that this is really unnecessary and could be easily improved by unifying CMake variable names used in checks across subprojects to benefit from caching.</div><div class=""><br class=""></div><div class="">I've looked at naming conventions used across all subprojects and I'm proposing the following:</div><div class=""><br class=""></div><div class="">C_SUPPORTS_${mangled_name}_FLAG for check_c_compiler_flag</div><div class="">CXX_SUPPORTS_${mangled_name}_FLAG for check_cxx_compiler_flag<br class=""></div><div class="">HAVE_${mangled_name} for check_library_exists</div></div></blockquote></div></div></blockquote><div class=""><br class=""></div><div class="">IMO, these issues are a manifestation of the fact that we basically have (at least) 4 times the same overall logic, once for each runtime project: compiler-rt, libunwind, libcxxabi, libcxx.</div><div class=""><br class=""></div><div class="">At the end of the day, what we're trying to achieve is link against the right system libraries when building the various runtimes. Would it make sense to instead bundle together the logic of searching for these libraries and adding the right compiler flags? We could use interface targets to achieve that. IOW, from libc++'s CMake, I'd love to just be able to write:</div><div class=""><br class=""></div><div class=""> target_link_libraries(cxx PUBLIC runtimes-system-libraries)</div><div class=""><br class=""></div><div class="">This would add -lpthread, -lgcc -lgcc_s, -lSystem or whatever else is needed on the system. I think this approach would provide more build system simplification and be more robust in the long term than relying on a naming convention to achieve sharing. What do you think?</div><div class=""><br class=""></div><div class="">Louis</div><div class=""><br class=""></div></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>