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

Fri Jun 19 04:36:19 PDT 2020

Sorry, I missed Chris and Aaron saying similar things.

On Fri, 19 Jun 2020 at 11:45, Russell Gallop <russell.gallop at gmail.com>
wrote:

> +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/880f7a5c/attachment.html>