On Thu, Nov 2, 2017 at 11:45 AM, Andres Rodriguez <andre...@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 <dy...@pnwbakers.com> >>>>>> wrote: >>>>>>> >>>>>>> Quoting Ilia Mirkin (2017-11-01 15:52:56) >>>>>>>> >>>>>>>> On Wed, Nov 1, 2017 at 6:49 PM, Chad Versace >>>>>>>> <chadvers...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
