[llvm-dev] wasteful cmake defaults

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 23 08:43:25 PST 2020


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.

—
Mehdi

On Mon, Nov 23, 2020 at 8:22 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

> > >     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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201123/0d2dbb9a/attachment.html>


More information about the llvm-dev mailing list