[llvm-dev] RFC: A top level monorepo CMake file

Fri Jun 19 03:45:38 PDT 2020

+1 for having a top level CMakeLists, but for a different reason.

Having many subproject CMakeLists.txt in the repo can be confusing for
Visual Studio CMake support, which tries to parse all subproject
CMakeLists.txt. AFAICT it isn't able to understand the structure with
llvm/CMakeLists.txt as the entry point. I have worked around this by adding
a simple top level CMakeLists.txt:

cmake_minimum_required(VERSION 3.4.3)
project(llvm-top-level)
add_subdirectory(llvm)

Which helps this use case. Note that this does affect the layout of the
build directory, moving things down into an llvm directory*.

I don't know whether this helps other GUIs/tools, but a top level
CMakeLists.txt is more conventional so it might.

I also strongly agree with doing this in small, planned, steps. There might
be a lot of use cases which are affected by these changes.

Regards
Russ

* which can be fixed up in llvm/CMakeLists.txt:
*** 292,295 ****
  # They are used as destination of target generators.
! set(LLVM_RUNTIME_OUTPUT_INTDIR
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
! set(LLVM_LIBRARY_OUTPUT_INTDIR
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
  if(WIN32 OR CYGWIN)
--- 292,295 ----
  # They are used as destination of target generators.
! set(LLVM_RUNTIME_OUTPUT_INTDIR
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
! set(LLVM_LIBRARY_OUTPUT_INTDIR
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
  if(WIN32 OR CYGWIN)

On Fri, 19 Jun 2020 at 09:48, Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> FWIW: +1 for me.
>
> I actually looked into doing this a couple of times already, but too many
> things are tangled for me to manage it, in particular around the runtimes.
> Having someone who understands the runtime situation driving it would make
> sense.
> I think I also tried to do "too much at once" instead of a sequence of
> smaller NFC refactorings to get closer to the desired state.
>
> --
> Mehdi
>
>
>
> On Thu, Jun 18, 2020 at 10:57 AM Louis Dionne via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi folks,
>>
>> Building any LLVM project currently requires invoking CMake inside
>> <monorepo-root>/llvm, while setting the projects to enable in the
>> LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing
>> for the LLVM subproject happens even when one doesn't really need or want
>> it. It's also not great from a build hygiene perspective, as LLVM globally
>> sets some flags and subprojects pick them up, when they don't really mean
>> to. For example, see this workaround:
>> https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L503-L507,
>> where we need to account for some flags that might have been set globally
>> by LLVM.
>>
>> I'm not sure about other projects, however this is quite problematic for
>> projects part of the C++ runtime (libc++/libc++abi/libunwind). Indeed, we
>> often try to build those projects targetting not widely supported
>> platforms, where the overall LLVM build doesn't work. For example, trying
>> to use the LLVM_ENABLE_PROJECTS approach for building libc++ for Apple's
>> DriverKit environment doesn't work, since it has a few unusual things that
>> the LLVM build chokes on. However, building libc++ standalone works just
>> fine because it has far fewer requirements. It's also not just an issue of
>> working vs not working: because of global flag pollution, building libc++
>> standalone and as part of the rest of LLVM can result in slightly different
>> flags being used, which could cause important and hard-to-diagnose issues.
>>
>> Hence, I think we should introduce a way to build LLVM projects (or at
>> least the runtimes) without going through
>> <monorepo-root>/llvm/CMakeLists.txt. What I suggest is to have a top-level
>> <monorepo-root>/CMakeLists.txt whose sole job is to include subprojects. We
>> could also place basic LLVM-wide things like the check for the minimum
>> CMake version there. More specifically, I would like to be able to do:
>>
>>     $ cd <monorepo-root>
>>     $ mkdir build
>>     $ (cd build && cmake <monorepo-root>
>> -DLLVM_ENABLE_PROJECTS="<projects-to-enable>")
>>
>> Pretty much the only difference with today is that you'd use `cmake
>> <monorepo-root>` instead of `cmake <monorepo-root>/llvm`.
>>
>> Like I said, this is a problem for the runtime projects, but I'm not sure
>> about other projects. For the runtime projects, another option would be to
>> only allow standalone builds. However, the runtime projects are often built
>> in lockstep, and so running three CMake commands when one would suffice is
>> both annoying and also an easy way to screw things up. Furthermore, the
>> current standalone builds add complexity to the projects, because they
>> require the ability to point to arbitrary headers/libraries from the other
>> projects, when we really always want to point to the just-built ones.
>>
>> Relationship with Petr Hosek's "Runtimes" build
>> ---------------------------------------------------------------
>> What I'm proposing isn't a replacement for itl. The "Runtimes" build can
>> be seen as a driver that sets up the individual libc++/libc++abi/libunwind
>> builds with the just-built toolchain, and for the provided targets. That's
>> really great, however it is built *on top of* the basic
>> libc++/libc++abi/libunwind builds. So basically, after my proposal, the
>> "Runtimes" build could simply build all elements from the runtime with a
>> single CMake invocation, as opposed to multiple invocations.
>>
>> Thoughts?
>> Louis
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/cc339d19/attachment.html>