On Sun, Mar 11, 2018 at 1:43 AM Eli Schwartz via arch-dev-public < arch-dev-public@archlinux.org> wrote:
> While we are at it, someone has seen fit to create some arbitrary meson > wrapper called "arch-meson" (note we have never shipped an arch-cmake > nor an arch-configure, nor an arch-setup-py nor even an arch-make etc.), > which aside for being somewhat magical also most certainly sets > --buildtype release > > I distinctly remember this being something we do not want to support in > makepkg due to us being fundamentally opposed to the end result where > e.g. Debian packaging has magic in every which direction and you have to > have a degree in Debian packaging plus go spelunking through addons > provided by six or seven packages just to figure out how the actual > build system for packages is being configured and run. > It's not magical. This doesn't even compare to dpkg-buildpackage's hooks and buildsystem handling, which changes behavior drastically based on what's installed and what the source tree looks like. arch-meson is just a wrapper providing some defaults. You don't use the wrapper, you don't get the defaults. For that matter, I'm all for putting an arch-configure helper into our autoconf package. I've had all kinds of issues because builds forgot to set or mishandled some installation directory option from autoconf's general set. We should avoid having to repeat the same options over and over. I *know* that meson's buildtype=plain does the sane thing and delegates > to the environment *FLAGS (or rather, the makepkg.conf *FLAGS and > OPTIONS=(debug) if specified). > I did not use plain because meson handles languages other than C and C++. Our FLAGS override the buildtype arguments anyway. We get the best of both worlds. We can move arch-meson's buildtype to debugoptimized as soon as we start building debug packages.
