[Mesa-dev] Meson's default build type

[Matt Turner]

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.