[Mesa-dev] Meson's default build type

[Chad Versace]

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. 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