[Mesa-dev] Meson's default build type

[Matt Turner]

On Fri, Nov 3, 2017 at 6:28 PM, Christian Schmidbauer
<ch.schmidbauer at gmail.com> wrote:
>> On Thu, Nov 2, 2017 at 11:45 AM, Andres Rodriguez <andresx7 at gmail.com> wrote:
>>>
>>>
>>> On 2017-11-02 01:52 PM, Eric Engestrom wrote:
>>>>
>>>> On Thursday, 2017-11-02 17:39:53 +0000, Eric Engestrom wrote:
>>>>>
>>>>> On Thursday, 2017-11-02 09:46:05 -0700, Chad Versace wrote:
>>>>>>
>>>>>> On Wed 01 Nov 2017, Dylan Baker wrote:
>>>>>>>
>>>>>>> Quoting Ilia Mirkin (2017-11-01 16:05:17)
>>>>>>>>
>>>>>>>> On Wed, Nov 1, 2017 at 7:03 PM, Dylan Baker <dylan at pnwbakers.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Quoting Ilia Mirkin (2017-11-01 15:52:56)
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 1, 2017 at 6:49 PM, Chad Versace
>>>>>>>>>> <chadversary at chromium.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Wed 01 Nov 2017, Dylan Baker wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Quoting Chad Versace (2017-11-01 14:43:28)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wow. 10 seconds from a clean checkout to an installed Vulkan
>>>>>>>>>>>>> driver.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Glad that it's working out for you guys!
>>>>>>>>>>>>
>>>>>>>>>>>> Can I convince you to wire the anvil and i965 android/arc++ bits?
>>>>>>>>>>>> ;)
>>>>>>>>>>>>
>>>>>>>>>>>> JFYI, the meson build will (I consider it a bug if it doesn't)
>>>>>>>>>>>> turn off all
>>>>>>>>>>>> glapi, egl, and glx if there are no dri or gallium drivers built
>>>>>>>>>>>> unless you
>>>>>>>>>>>> force them on.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks for turning that stuff off. Last time I tried to build just
>>>>>>>>>>> Vulkan without GL (maybe 1.5 years ago), Autotools didn't allow it.
>>>>>>>>>>> It
>>>>>>>>>>> insisted that i965 was a build dependency for anvil.
>>>>>>>>>>>
>>>>>>>>>>>> It also avoids building the glsl compiler unless there's a driver
>>>>>>>>>>>> that uses it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I expected the buildtime to be much longer because I expected it to
>>>>>>>>>>> build the GLSL compiler too. I was surprised and happy to discover
>>>>>>>>>>> that
>>>>>>>>>>> it builds only the SPIR-V compiler.
>>>>>>>>>>>
>>>>>>>>>>>> And it defaults to debug, which might be surprising, but people
>>>>>>>>>>>> around here thought that default debug is a feature.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Huh... For infrastructure projects like Mesa (as opposed to test
>>>>>>>>>>> projects like Piglit), I expect the default build to be the release
>>>>>>>>>>> build. But I can understand why others would want default=debug.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> autotools defaults to debug disabled. I think that's how almost
>>>>>>>>>> every
>>>>>>>>>> project does it... debug enabled is definitely a surprise.
>>>>>>>>>>
>>>>>>>>>>    -ilia
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well, for distros they likely want to set the buildtype to plain
>>>>>>>>> (meson adds no
>>>>>>>>> compiler flags except ones the project defines), and then add their
>>>>>>>>> default
>>>>>>>>> flags via CFLAGS and CXXFLAGS. That is certainly *not* what anyone
>>>>>>>>> except a
>>>>>>>>> distro (or some kind of build infrastructure like jenkins or gentoo)
>>>>>>>>> would want.
>>>>>>>>> Xorg's default is debugoptimzed, for reference.
>>>>>>>>
>>>>>>>>
>>>>>>>> --enable-debug enables -DDEBUG in mesa. Are you saying that this is
>>>>>>>> the default? Or are you just saying that you're not adding extra
>>>>>>>> -O100073 options?
>>>>>>>
>>>>>>>
>>>>>>> The meson build keys -DDEBUG on the builtype, debug or debugoptimized
>>>>>>> you get
>>>>>>> -DDEBUG, anything else, you don't. The way mesa is setup if you don't
>>>>>>> have
>>>>>>> -DNDEBUG you have to have -DDEBUG or asserts happen for member of
>>>>>>> structures
>>>>>>> that don't exist.
>>>>>>>
>>>>>>> I'm not dead set on debug as the default buildtype, it's what we have
>>>>>>> ATM
>>>>>>> though. I asked around here and the feeling was that builtype debug by
>>>>>>> default
>>>>>>> was a feature. If the larger community disagrees we can change it.
>>>>>>
>>>>>>
>>>>>> When making this decision, I think we should also consider the needs of
>>>>>> non-developers who build and install Mesa from source to get the latest
>>>>>> version or bugfix. I strongly suspect those people want
>>>>>> buildtype=debugoptimized or buildtype=release.
>>>>>>
>>>>>> I think it's important for Mesa to follow the established convention of
>>>>>> most other Linux projects: if a user downloads the source, builds, and
>>>>>> installs, then the user gets a working installation suitable for normal
>>>>>> usage. Today, Meson doesn't give that because it builds Mesa with -O0.
>>>>>>
>>>>>> Some context... I install a lot of packages from source on my work
>>>>>> machine because I often want or need newer versions of some packages
>>>>>> than what's available through the package manager.
>>>>>
>>>>>
>>>>> How do you ensure it integrates correctly with your system [1], other
>>>>> than by using the package manager's package and updating the version
>>>>> number locally?
>>>>>
>>>>>    [1] by "integrate" I mean things like installing things in the right
>>>>>    locations, removing stale files from old packages, providing new
>>>>>    dependencies for other packages, etc.
>>>>>
>>>>> I also install newer version of stuff on various machines, but if I had
>>>>> to configure each project manually to integrate with my system, then
>>>>> I would just give up. That burden does not scale :P
>>>>>
>>>>> The only way I can make this work is by grabbing the existing package,
>>>>> bumping the version and recompiling it. Part of the configuration set in
>>>>> the package is the various optimisation flags, be that through
>>>>> buildtype=release or buildtype=plain + manual cflags.
>>>>>
>>>>> (Note that for Meson, Arch provides a wrapper [2] that sets all the
>>>>> options to the right values for ease of use.)
>>>>> [2]
>>>>> https://git.archlinux.org/svntogit/packages.git/tree/meson/trunk/arch-meson
>>>>>
>>>>
>>>> I think I wasn't clear, but my point was that IMHO the only time someone
>>>> would build something without going through a package is when they're
>>>> dev'ing it, in which case buildtype=debug is what they want.
>>>>
>>>> It's not too hard to ask all the devs to manually set it every time
>>>> though,
>>>> especially since we're all used to having to do it with autotools.
>>>
>>>
>>> I think this is one of the better reasons to go with an optimized build type
>>> by default.
>>>
>>> Additionally, it is very easy for a developer to realize that a build is
>>> missing debug symbols (you'll get the feedback from your debugger
>>> immediately). However, a user might never notice that their build is not
>>> optimized. This can lead to a bad experience that could've easily been
>>> avoided, and possibly some noise in bug reports.
>>>
>>> As Eric mentioned, the cost of setting the build type from a dev point of
>>> view is minimal and probably worth offsetting the issues mentioned above.
>>
>> This makes sense to me.
>>
>> In the autotools system we have today, we have --enable-debug, which
>> adds -g and -O0 if some -g* and -O* are not already in CFLAGS. It also
>> adds -DDEBUG which turns on lots of debugging code that has extra
>> runtime cost, like nir_validate. Without --enable-debug, we pass
>> -DNDEBUG to disable assertions, and otherwise use autotools' default
>> CFLAGS (-g -O2) or whatever the user specified.
>>
>> Meson's debug build should correspond to --enable-debug.
>> debugoptimized vs release is a little less obvious. Perhaps
>> debugoptimized should default to -g -O2 but leave assertions enabled,
>> and release should default to -g -O2 -DNDEBUG?
>>
>> Under that system, I agree that the default build type should be debugoptimized.
>
> Does this mean that it is not easily possible to keep asserations in
> general but remove heavy extra runtime cost (like nir_validate)?

That's the main difference between debug and debugoptimized.

> FWIW, it would be great if there would be a "debugoptimized" which
> tries to keep the overhead minimal and still allow debugging in a
> sensible, but not complete, way.

Yes... we call it "debugoptimized" :)