[Mesa-dev] Meson's default build type

Sat Nov 4 01:28:11 UTC 2017

> 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)?

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.