[llvm-dev] wasteful cmake defaults

[David Chisnall via llvm-dev]

On 17/11/2020 18:25, Luke Drummond via llvm-dev wrote:
>> -- No build type selected, default to Debug
> It appears that llvm's configuration forces Debug builds if the user
> does not specify the build type.
> 
>      https://github.com/llvm/llvm-project/blob/9218ff50f93085d0a16a974db28ca8f14bc66f64/llvm/CMakeLists.txt#L57-L60
> 
> I've just done a build of llvm and clang 10 in debug mode for X86 and
> ARM targets and it weighs in at a whopping 75GiB. I feel that forcing
> Debug builds in the absence of an option to be a wasteful default. It is
> a valid and useful thing to call cmake without specifying a build type;
> absence of a command line switch does not always imply absence of a
> choice.

I think you are conflating two things somewhat here:

  - Is it useful to do an -O0 build without assertions or debug info?
  - What is the most useful default build configuration?

These are somewhat separable.  As others have said, the first can be 
achieved by specifying a release build with -O0 in the CXXFLAGS.  This 
is honestly not something I've ever considered doing, because the extra 
time to run a handful of tests at -O0 is likely to offset any build-time 
improvements.  It's useful if you want to get an LLVM binary quickly, 
but not so useful if you want to actually run it.  If you run it and it 
doesn't work, then you'll still need to do a debug build to get useful 
debug information.  As such, I'm not sure that I understand the use case.

In terms of the most useful build configuration to be the default, I 
think there are a bunch of users that we need to consider:

  - Developers of LLVM
  - Developers of downstream projects that use LLVM
  - Package builders
  - CI admins.

Some of these are easy.  CI admins are likely to want to configure their 
builds explicitly and so won't want to use the defaults.  Package 
builders are going to want a Release build, but generally put that in 
their configuration for the package file and so don't care too much what 
the default is.

Developers of LLVM and downstream projects are similar.  Downstream 
projects come in two flavours:

  - Ones that depend on an LLVM release version existing
  - Ones that ship their own LLVM as a submodule.

The second is less of a problem because it will be driving the LLVM 
build from its own build infrastructure and so has a one-time cost for 
configuration and anyone building that project inherits the benefits.

The first is more of a problem because build configurations of LLVM 
change its ABI, so you need to match the LLVM build to the downstream 
project's build configuration.  This is generally fairly easy to do by 
just pointing at the llvm-config built by the specific LLVM output, so 
you can easily have Debug / Release / Whatever builds of your project 
using different llvm-config versions.  Supporting this means that you 
are already propagating config from LLVM and people building your 
project in anything other than a relase configuration need to do a 
non-default build of LLVM.

This leaves LLVM developers.  I'd assume that these are the people 
building LLVM manually the most often and so it makes sense to provide 
them with a default that makes sense.  Unfortunately, there isn't a 
single one that makes sense for developers.

For the last few years, I've been following Chandler's suggestion and 
building a Release + Asserts build and a Debug + ASan + expensive checks 
build whenever I work on LLVM.  Release with asserts is reasonably fast 
running the tests and fast to build, so a compile-test cycle is not too 
bad.  When that fails, I can switch to the other build and get something 
that's easy to debug.  I also generally try to run the entire test suite 
in this configuration once before merging to master because it picks up 
memory management bugs that may not actually break anything in the 
(simple) test cases.

The default isn't for either of those.  I'd be quite happy for the 
default to be either Debug + ASan + expensive tests or Release + 
Asserts, but given that I have to manually configure one of them, 
there's limited value in needing less manual configuration for the other.

Perhaps the right solution is for the build to fail and tell people to 
pick one if they don't specify CMAKE_BUILD_TYPE.

David