[Mesa-dev] Meson's default build type

Fri Nov 3 16:31:14 UTC 2017

On 2017-11-03 05:25 AM, Michel Dänzer wrote:
> On 02/11/17 07:45 PM, Andres Rodriguez 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.
> 
> Builds without debugging symbols also result in noise in bug reports.
> 
> 

Agreed, sorry that I worded myself poorly.

I meant to argue just for optimizations enabled ( didn't meant to sound 
like I am against debug symbols ). So something like debugoptimized 
would be a good default from my POV.

Regards,
Andres