CMake standalone and compile flags

Hi,

I was looking into fixing this error that someone has when building flang: https://llvm.discourse.group/t/error-when-building-with-cmake/935

Then I noticed that flang/CMakeLists.txt still has this branch: https://github.com/llvm/llvm-project/blob/master/flang/CMakeLists.txt#L42 ; is there anyone that relies on it or can we simplify this file and the way the options are setup?

Thanks,

Hi Mehdi,

That branch enables out of tree builds; I believe there are people that still rely on those which is why we added that branch in when rewriting the CMake infrastructure.
There’s an open review to fix a similar issue as is reported in the discussion you linked but it seems to have stalled on a discussion about whether to continue to force Werror on, perhaps you could take a look at that and comment there if it fixes this issue or not?

The review is at https://reviews.llvm.org/D78306

Thanks

David Truby

Hi Mehdi,

That branch enables out of tree builds; I believe there are people that still rely on those which is why we added that branch in when rewriting the CMake infrastructure.

I assume that folks were relying on this before the merge in the monorepo, but are there still reason to maintain this from now on? Can we put an end-date on it?
I’m trying to figure out if this is just a transition thing or if this is really something useful on the long run (and why).

There’s an open review to fix a similar issue as is reported in the discussion you linked but it seems to have stalled on a discussion about whether to continue to force Werror on, perhaps you could take a look at that and comment there if it fixes this issue or not?

The review is at https://reviews.llvm.org/D78306

Thanks, that was roughly what I was about to start doing!
In general I think we should avoid doing directly set(CMAKE_CXX_FLAGS ... and instead use the add_flag_if_supported macros provided by LLVM, e.g.: https://github.com/llvm/llvm-project/blob/master/mlir/lib/CMakeLists.txt#L2

Werror is always difficult to maintain because different compilers (and compiler versions) have different handling (possibly even opposite!) warnings. It is a good thing to have for developers, but it may be a bit hostile to users to have it on by default.

To give an example of what I meant by “opposite”: http://clang-developers.42468.n3.nabble.com/Re-llvm-dev-New-warnings-when-building-trunk-with-GCC-9-td4062064.html

Basically either you get a warning with clang, or you get a warning with gcc, but there is no source construct that would satisfy both compiler. Having Werror on by default means that a user checking out the repo and building it may just hit an error for no good reason.
(Also it isn’t clear to me why flang should deviate from the rest of the repo on this)

Best,

I find out-of-tree builds useful so I can build multiple flangs without having to build multiple llvms.

Tim

Hi Mehdi,

That branch enables out of tree builds; I believe there are people that still rely on those which is why we added that branch in when rewriting the CMake infrastructure.

I assume that folks were relying on this before the merge in the monorepo, but are there still reason to maintain this from now on? Can we put an end-date on it?
I’m trying to figure out if this is just a transition thing or if this is really something useful on the long run (and why).

Most LLVM subprojects have out-of-tree builds. For eg: clang, lld, lldb, libcxx, openmp, clang-rt and it’s a useful option to have. mlir is an exception.

Isuru

Hi Mehdi,

That branch enables out of tree builds; I believe there are people that still rely on those which is why we added that branch in when rewriting the CMake infrastructure.

I assume that folks were relying on this before the merge in the monorepo, but are there still reason to maintain this from now on? Can we put an end-date on it?
I’m trying to figure out if this is just a transition thing or if this is really something useful on the long run (and why).

Most LLVM subprojects have out-of-tree builds. For eg: clang, lld, lldb, libcxx, openmp, clang-rt and it’s a useful option to have.

But I’d claim that most of them only have this because that was the norm until 6 months ago when everything merged in the monorepo :slight_smile:
(builtin/runtime libraries are a different case though, they often must built against a just-built compiler)

Tim had a good point about the usefulness of it though: scaling the builds of multiple flang variants against the same LLVM. I wonder how fragile / useful is this though (I never done so)? You likely have to disable LLVM_ABI_BREAKING_CHECKS if you’re trying to build a Debug flang against a release LLVM (or vice versa). If your LLVM is not a Debug one you also don’t have debug info for the LLVM data structure / libraries, this may be limiting when debugging flang.

mlir is an exception.

That’s because it is the only project that started after the monorepo was a thing and always assumed it.

Hi Mehdi,

That branch enables out of tree builds; I believe there are people that still rely on those which is why we added that branch in when rewriting the CMake infrastructure.

I assume that folks were relying on this before the merge in the monorepo, but are there still reason to maintain this from now on? Can we put an end-date on it?
I’m trying to figure out if this is just a transition thing or if this is really something useful on the long run (and why).

Most LLVM subprojects have out-of-tree builds. For eg: clang, lld, lldb, libcxx, openmp, clang-rt and it’s a useful option to have.

But I’d claim that most of them only have this because that was the norm until 6 months ago when everything merged in the monorepo :slight_smile:
(builtin/runtime libraries are a different case though, they often must built against a just-built compiler)

Tim had a good point about the usefulness of it though: scaling the builds of multiple flang variants against the same LLVM. I wonder how fragile / useful is this though (I never done so)? You likely have to disable LLVM_ABI_BREAKING_CHECKS if you’re trying to build a Debug flang against a release LLVM (or vice versa). If your LLVM is not a Debug one you also don’t have debug info for the LLVM data structure / libraries, this may be limiting when debugging flang.

It’s not only the build type. Some subprojects have cmake options that developers want to check. For eg: clang has lots of options that are specific to clang. https://github.com/llvm/llvm-project/blob/master/clang/CMakeLists.txt#L266-L275. This is useful for users too who may want a subproject with a different option from their package manager version or if the subproject is not available from their package manager.

Isuru

I believe out of tree builds are also used by distributors; For example most linux distributions have separate packages for llvm, clang, libcxx etc and I believe make this work by building out of tree. I’m not a distributor though so I’m not fully sure this is the case.

David

Other projects such as Clang
(https://github.com/llvm/llvm-project/blob/master/clang/CMakeLists.txt#L9),
Polly (https://github.com/llvm/llvm-project/blob/master/polly/CMakeLists.txt#L2),
lld (https://github.com/llvm/llvm-project/blob/master/lld/CMakeLists.txt#L2),
lldb (https://github.com/llvm/llvm-project/blob/master/lldb/CMakeLists.txt#L19),
libc++ (https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L31),
openmp (https://github.com/llvm/llvm-project/blob/master/openmp/CMakeLists.txt#L7)
support this build mode as well. This only subproject I could find
that does not support building to a pre-installed LLVM is MLIR.

Michael