On 03/13/2018 07:22 AM, Jan Alexander Steffens wrote:
> 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.

"I object on principle to ever using the wrapper" -- then why does the
wrapper exist if we don't use it because we don't have to?

This wrapper changes depending on which version of meson you have installed.

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

The fact that autoconf has weird bugs like needing to set localstatedir
and sysconfdir to their defaults minus the /usr prefix, is an autoconf
bug. Maybe we could work on having meson not require setting bizarre
options just to get sane defaults?

And arch-meson contains at least seven options that simply repeat the
defaults shown by running `meson ..; meson configure`.

(Setting the prefix automatically propagates to everything specified
with relative paths, which is most things, and libexecdir and sbindir
could just specify a *different* relative path.)

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

So other languages, which completely disregard our CFLAGS but which
meson itself has magic wrappers for... and the solution is to add a
magic script to use in the PKGBUILD which does not respect makepkg.conf
but can add debug symbols only loosely related to what we were trying to
get? A script which arbitrarily adds debug symbols to packages that were
rebuilt with OPTIONS=(!debug) by users who wanted to make local
modifications?

Maybe the solution is to get support for these languages to respect our
FLAGS regardless of whether the build system is implemented in meson. Or
I guess we could just replace our packaging system with meson so we can
consistently get debug info for nonconformant languages... since
apparently meson is so perfect we should do literally everything
directly in meson.

Or we could at least make a *proper* wrapper which can talk to makepkg
and determine if debug info is wanted.

This is dead simple, as libmakepkg allows creating bash functions that
run in makepkg itself and can talk to check_option()
It is also even more magical, because then there isn't even an obvious
executable file to look at...

Another option would be to look at CFLAGS (which are exported) and
enable debug iff "-g" is present. (Maybe meson could do this and
translate that to vala or rust or java or whatever flags, since it is
trying to provide seamless support for this everywhere...)

> We can move arch-meson's buildtype to debugoptimized as soon as we start
> building debug packages.

So then if someone checks out our PKGBUILDs and tries to build non-debug
versions, our FLAGS override and erase the buildtype resulting in a
plain old release build?

Because no, appending our FLAGS to the buildtype FLAGS is *not* the same
as overriding them. That's just adding more FLAGS and praying that every
buildtype FLAG is contra-indicated by an opposing makepkg.conf FLAG.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to