arch-meson question

jvb · 2019-01-30 11:19:03

Hi, several times on AUR comments and this forum, I read, that arch-meson should not be used (ever), or that arch-meson is dumb. My question is, why? I was not able to find some meaningful explanation or a reason why this wrapper even exists. So can someone please provide simple explanation why not to use it in PKGBUILDs, and invoke meson directly. And also, why it exists and someone would use it. Thanks

WorMzy · 2019-01-30 11:34:13

Can you provide some links for context? This is the first time I've even heard of "arch-meson", a quick check shows it's part of the meson package, added by an Arch dev, and there's no bug reports complaining about it's inclusion (the only report I can find that references it is this one).

Mod note: Not an AUR issue, moving to Arch discussion.

Lone_Wolf · 2019-01-30 11:36:49

Search arch-dev-public ML archives.

As for why not to use it :

https://git.archlinux.org/svntogit/pack … ages/meson
That is what arch-meson does.

If you check the aur packages I maintain you'll see I don't use it.
The 2 options in arch-meson I disagree with the most are

  --buildtype      release \
  -D               b_lto=true \

https://mesonbuild.com/Quick-guide.html wrote:

The command line switch --buildtype=plain tells Meson not to add its own flags to the command line. This gives the packager total control on used flags.

Link Time Optimization (lto) does have advantages in many cases, but there are also cases where it introduces problems .

jvb · 2019-01-30 11:41:26

https://bbs.archlinux.org/viewtopic.php … 0#p1797098

https://aur.archlinux.org/packages/hexc … ent-674759

I am just seeking some clear explanation and best practices.

//edit: @Lone_Wolf thanks!

Last edited by jvb (2019-01-30 11:42:09)

Alad · 2019-01-30 13:16:59

https://wiki.archlinux.org/index.php/GN … with_meson

So far no-one made a case to include arch-meson in that article.

eschwartz · 2019-01-31 02:38:01

jvb wrote:

Hi, several times on AUR comments and this forum, I read, that arch-meson should not be used (ever), or that arch-meson is dumb.

Probably from me, I'm a very opinionated person.

My question is, why? I was not able to find some meaningful explanation or a reason why this wrapper even exists. So can someone please provide simple explanation why not to use it in PKGBUILDs, and invoke meson directly. And also, why it exists and someone would use it. Thanks

It exists because the maintainer of the extra/meson package decided to create it -- and apparently because no one in the discussion that did not include Trusted Users argued against it. I've been bothered by it on a personal level for a long, long time, but only recently even discovered that there was any discussion about it at all...

It bothers me on a personal level for, essentially, two reasons:

First, it is opinionated, it overrides settings that I believe are incorrect and should not be implemented, like:
- enabling pie and lto (the former is enforced via gcc, the latter is a policy change best deployed via makepkg.conf CFLAGS),
- forcing the addition of release optimizations without respecting makepkg.conf settings like custom CFLAGS that lack optimization levels or causing mysterious issues where setting options=('!buildflags') in a PKGBUILD does not have the expected effect
Second, it is flat-out wrong. It's unsuitable even for its intended purpose of setting supposed sane defaults. It passes a large number of options to configure the directory hierarchy.
- every one of which uses an absolute rather than relative path and therefore does not work with arch-meson --prefix=/usr/local,
- and even discounting that, it hardcodes options to make bindir, libdir, includedir, datadir, mandir, infodir, and localedir use the directories which are already the default (except that the default is relative to prefix, and arch-meson simply aborts with fatal errors if you override --prefix but not all the others).
- It also hardcodes localstatedir and sharedstatedir as /var and /var/lib which once again is meson's default for --prefix=/usr, in a manner which is not a fatal error in combination with --prefix=/usr/local, but could simply be said to be totally incorrect, when meson would instead default to /var/local and /var/local/lib.
- At least for libexecdir and sbindir it is factually true that any project which actually uses these directories will need to be corrected in an archlinux-specific manner. Hey, two out of thirteen isn't bad. It's a pity only the minority of projects actually use either feature, and rather a lot of them specify --libexecdir=/usr/lib/$pkgname anyway, or don't bother with the bin/sbin split at all...

Last edited by eschwartz (2019-01-31 02:40:06)

Allan · 2019-01-31 03:36:48

eschwartz wrote:

I've been bothered by it on a personal level for a long, long time, but only recently even discovered that there was any discussion about it at all...

There was?

I am very much against it because it goes against the "vanilla" ethos of Arch Linux. I'd be OK with the script in a separate package.

eschwartz · 2019-01-31 03:47:27

Allan wrote:

eschwartz wrote:
I've been bothered by it on a personal level for a long, long time, but only recently even discovered that there was any discussion about it at all...
There was?
I am very much against it because it goes against the "vanilla" ethos of Arch Linux. I'd be OK with the script in a separate package.

I was told in IRC in the -tu channel that there "was" discussion, I assume in -dev. Never saw it, don't know what was said or who said it or how many people agreed.

I only even know that much, because I griped and moaned about it being pushed through by the package maintainer as a personal script without rationale -- and then I got scolded for it, told that yes, of course there was discussion and no, not when I was around, but I'm expected to know this anyway and be happy that there was in fact discussion and therefore it is all right.
Therefore, I am taking it on faith that there was discussion.

Possibly in concession to my comments, it has very recently been updated to include a bash comment specifying that it is in fact opinionated: https://git.archlinux.org/svntogit/pack … 960170dcad

Lone_Wolf · 2019-01-31 10:14:16

I did remember seeing something about arch-meson on arch-dev-public and found it :

http://archlinux.2023198.n4.nabble.com/ … l#a4718746

The discussion is not about arch-meson itself, but arch-meson is mentioned in it.

quequotion · 2019-03-18 14:42:49

When I checked Lone_Wolf's link, I found that heftig has updated arch-meson; removing many of the specified options, but still specifying lto and pie.

I like that arch-meson handles setting a few directories (as long as it sets them appropriately), but as eshcwartz points out, flags are especially something that should be handled by makepkg (unless a particular package needs something very specific) and not assumed applicable to packages generically (at least in theory, either option could cause build or execution failure for some programs).

It inspired me to add pic and pie macros to makepkg-optimize, allowing packagers to specify options=('lto' '!pie' 'pic') etc. (in unofficial PKGBUILDs at least). Enabling such options without makepkg-optimize throws a "command not found" warning but does not prevent a package from building.

Last edited by quequotion (2019-03-18 14:45:10)

Allan · 2019-03-18 21:38:18

quequotion wrote:

It inspired me to add pic and pie macros to makepkg-optimize, allowing packagers to specify options=('lto' '!pie' 'pic') etc. (in unofficial PKGBUILDs at least). Enabling such options without makepkg-optimize throws a "command not found" warning but does not prevent a package from building.

Not sure why they are needed. Both gcc and clang set these by default in Arch.

quequotion · 2019-03-19 00:42:07

Allan wrote:

Not sure why they are needed. Both gcc and clang set these by default in Arch.

Did not know that!

EDIT: So then, unless that is somehow broken by using {arch-,}meson, the pie option in arch-meson is not only opinionated, but redundant?

Last edited by quequotion (2019-03-19 00:53:15)

Arch Linux

#1 2019-01-30 11:19:03

arch-meson question

#2 2019-01-30 11:34:13

Re: arch-meson question

#3 2019-01-30 11:36:49

Re: arch-meson question

#4 2019-01-30 11:41:26

Re: arch-meson question

#5 2019-01-30 13:16:59

Re: arch-meson question

#6 2019-01-31 02:38:01

Re: arch-meson question

#7 2019-01-31 03:36:48

Re: arch-meson question

#8 2019-01-31 03:47:27

Re: arch-meson question

#9 2019-01-31 10:14:16

Re: arch-meson question

#10 2019-03-18 14:42:49

Re: arch-meson question

#11 2019-03-18 21:38:18

Re: arch-meson question

#12 2019-03-19 00:42:07

Re: arch-meson question

Board footer