wasteful cmake defaults

I have no strong opinion on this topic personally (I always set the build type to something if I’m not generating a Visual Studio project), but this “non-optimized, non-asserting, non-debug-info-containing” build that you get when not specifying the build type to CMake is a quirk that I feel most CMake users expect at this point. I don’t think there’s any real value in providing a useful default if nobody accepts the default anyways due to having been burned in the past.

Thanks,

Christopher Tetreault

I’ll comment that not all new developers of LLVM have experience w/cmake. A while back, we did a hack-a-thon for folks interested in learning about LLVM. We had many, many, many new contributors who lost most of the day to build times and build sizes because of the defaults. (The size issue was almost the bigger problem; many didn’t have enough free space to complete a unoptimized/debug build.)

Personally, I think we should either a) change the defaults or b) put a prominent warning in the docs.

Philip

https://llvm.org/docs/GettingStarted.html#common-problems

Should it be more prominent?

Michael

<llvm-dev@lists.llvm.org>:

Personally, I think we should either a) change the defaults or b) put a prominent warning in the docs.

https://llvm.org/docs/GettingStarted.html#common-problems

Should it be more prominent?

It doesn’t look like disk space is mentioned in the common problems, just memory usage. Earlier on that page it mentions that a debug build of llvm and clang consume 15-20GB, but is that still accurate given the 75GiB quoted earlier in this thread?

Personally, I think we should either a) change the defaults or b) put a prominent warning in the docs.

https://llvm.org/docs/GettingStarted.html#common-problems

Should it be more prominent?

I don't think having this documented is all that helpful. I know that when I build a new project, if I see it has cmake, I just do cmake -G Ninja && ninja and don't bother reading the docs.

I think it would make the most sense to change the default to be Release+Asserts, because this is the most likely configuration to work on the average system.

-Tom

Personally, I think we should either a) change the defaults or b) put a prominent warning in the docs.

https://llvm.org/docs/GettingStarted.html#common-problems

Should it be more prominent?

I don't think having this documented is all that helpful. I know that when I build a new project, if I see it has cmake, I just do cmake -G Ninja && ninja and don't bother reading the docs.

Tom, you are definitely not the new user I'm worried about. :slight_smile:

Think undergrad w/little to no open source experience.

I think it would make the most sense to change the default to be Release+Asserts, because this is the most likely configuration to work on the average system.

+1

Because cmake's empty default for CMAKE_BUILD_TYPE (i.e. not
passinging any optimization flags i.e. use compiler defaults i.e.
unoptimized builds but also without the possibility to debug) is not
helpful for any use case, I habitually also pass
-DCMAKE_BUILD_TYPE=Release (or -DCMAKE_BUILD_TYPE=Debug when e.g. I
want a backtrace) to repositories using cmake. In the same sense I
habitually pass -j<n> to make because I rarely want to use only one
core of my multi-core CPU.

Michael

Can you expand on why release+asserts and not just release?
I can imagine folks just wanting to try clang out of the box and finding it “slow” because they don’t know that assertions have to be disabled explicitly for example.
Of course developers have to opt-in assertions, but they also have to think about opting in Debug info and sanitizers.

     > <llvm-dev@lists.llvm.org <mailto:llvm-dev@lists.llvm.org>>:
     >> Personally, I think we should either a) change the defaults or
    b) put a prominent warning in the docs.
     >
     > https://llvm.org/docs/GettingStarted.html#common-problems
     >
     > Should it be more prominent?
     >

    I don't think having this documented is all that helpful. I know that
    when I build a new project, if I see it has cmake, I just do cmake -G
    Ninja && ninja and don't bother reading the docs.

    I think it would make the most sense to change the default to be
    Release+Asserts, because this is the most likely configuration to work
    on the average system.

Can you expand on why release+asserts and not just release?
I can imagine folks just wanting to try clang out of the box and finding it "slow" because they don't know that assertions have to be disabled explicitly for example.
Of course developers have to opt-in assertions, but they also have to think about opting in Debug info and sanitizers.

The reason I prefer enabling asserts is because it gives you better information when something goes wrong, and I think this can be helpful for new users. But this is just a slight preference, I would support either Release+Asserts or Release as the default.

-Tom

> I don't think having this documented is all that helpful. I know
that
> when I build a new project, if I see it has cmake, I just do cmake -
G
> Ninja && ninja and don't bother reading the docs.
>
> I think it would make the most sense to change the default to be
> Release+Asserts, because this is the most likely configuration to
work
> on the average system.
>
>
> Can you expand on why release+asserts and not just release?
> I can imagine folks just wanting to try clang out of the box and finding
> it "slow" because they don't know that assertions have to be disabled
> explicitly for example.
> Of course developers have to opt-in assertions, but they also have to
> think about opting in Debug info and sanitizers.
>

The reason I prefer enabling asserts is because it gives you better
information when something goes wrong, and I think this can be helpful
for new users. But this is just a slight preference, I would support
either Release+Asserts or Release as the default.

-Tom

FWIW, within Sony our wrapper build script defaults to Release+Asserts.

We could default to Release+Asserts if the build type is empty; but if
it's not empty, we do what you asked (and Release would not imply Asserts).

Has anyone measured the compiler performance difference for +Asserts lately?
I have a vague memory that it was ~10% but that was quite a while ago.
--paulr

I thought about another possibility : when we’re not sure about the default, can we just not provide one?

If the user invoked Cmake without the option we display a nice error asking to set it explicitly.