[Mesa-dev] Meson's default build type

Thu Nov 2 18:45:10 UTC 2017

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.

Regards,
Andres

> 
> My vote is `debug` (or maybe `debugoptimised`), but I'm not strongly
> opposed to `release` either.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 