[Mesa-dev] Meson's default build type

[Eric Engestrom]

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

> For most of those
> packages, I expect the project's default build configuration to install
> what I want. For example, I want the below commands to do the right
> thing:
> 
>     ./configure
>     make
>     make install
> 
>     OR
> 
>     cmake -GNinja .
>     ninja
>     ninja install
> 
> I'm not developing nor debugging these packages. I just want to install
> and use them.
> 
> If I had to read each individual project's detailed build instructions
> in order to a working, optimized build on my system, then I would just
> give up. That burden does not scale.
> 
> If projects begin deviating from that convention, then I believe that
> negatively impacts the ecosystem.
> 
> Just my two cents