Arch Linux

sudo does not listen to MAKEFLAGS unless you say that's okay. Makechrootpkg internally calls sudo --preserve-env with a list of whitelisted environment variables including MAKEFLAGS. See https://git.archlinux.org/devtools.git/tree/makechrootpkg.in#n297

So I have no idea how this could be broken in your environment.

My login shell is zsh. I will switched to bash to rule that out and got the same result.

I also made a fresh user and got the same result (ignoring the exported variable). Can you try on your machine? The fast test is to just have the PKGBUILD echo $MAKEFLAGS and then exit:

$ export MAKEFLAGS=-j40
$ echo $MAKEFLAGS
-j40
$ makechrootpkg -u -c -r /scratch/.chroot64
==> Synchronizing chroot copy [/scratch/.chroot64/root] -> [facade]...done
...
==> Starting build()...
-j9

Yes it works for me, no zsh vs. bash *cannot* have any effect on this since makechrootpkg doesn't use your login shell as its execution environment.

You could add debug prints to the /usr/bin/makechrootpkg script if you like, to figure out where it is being dropped.

Not sure what debug prints means, but I did edit /usr/bin/makechrootpkg adding a 'set -x' and got this output:
https://gist.github.com/graysky2/a5ea7fb7266419524a15d5f584322d29

Line 391 reads /etc/makepkg.conf which seems to overwrite the value I exported?

Ah, if you have it in makepkg.conf it won't be preserved, which is actually the same behavior as /usr/bin/makepkg

If I comment out MAKEFLAGS in /etc/makepkg.conf, makechrootpkg behaves as it should; the value for MAKEFLAGS I define on the shell is honored:

1) MAKEFLAGS=-j40 makechrootpkg -u -c -r /scratch/.chroot64
or
2) export MAKEFLAGS=-j40 && makechrootpkg -u -c -r /scratch/.chroot64

The update from 20191016 --> 20191212 changed this behavior. With the older version, I could have the value in /etc/makepkg.conf defined AND was able to override via prefixing the call the makechrootpkg (case 1 above). Thanks for your help, eschwartz.

I am finding inconsistent behavior regarding how makechrootpkg handles a few of the variables the -h switch reads. I only tested it with MAKEFLAGS and PACKAGER.

From makechrootpkg -h:
"This script reads {SRC,SRCPKG,PKG,LOG}DEST, MAKEFLAGS and PACKAGER from makepkg.conf(5), if those variables are not part of the environment."

For example, if I define MAKEFLAGS=-j10 and PACKAGER="system <system@level.conf.com>" in /etc/makepkg.conf and then try to build a PKGBUILD that simply echos these values, I get the expected result:

% makechrootpkg -u -c -r /scratch/.chroot64
...
-j10
system <system@level.conf.com>

However, if I prefix the call the makechrootpkg (or if I export these variables) only the PACKAGER value is overridden, the value for MAKEFLAGS is still read in from /etc/makepkg.conf

% MAKEFLAGS=-j40 PACKAGER="override <over@ride.com>" makechrootpkg -u -c -r /scratch/.chroot64
...
-j10
override <over@ride.com>

Is this the expected behavior or a bug?

"which is actually the same behavior as /usr/bin/makepkg"

Guess whether this is an intended change in devtools...

This is due to 751093eff2cbd0df422b69810787b4fcf3d33208 use libmakepkg to find and use variables in makepkg.conf
The load_vars that check for a var being already declared or not was replaced by load_makepkg_config which comes from pacman.

I think its a good idea to behave similar here as makepkg itself behaves, so if we want to change this behavior we should change it in pacman's makepkg.
But I believe its not a bad idea to respect certain env vars over config settings, they should have precedence.

Thanks for the comments, eschwartz and anthraxx. For now, I left the variable undefined in /etc/makepkg.conf (commented out, if it is defined and set to a null value, the null is passed which is not what you want). I export it in my ~/.zshrc which I can override by prefixing the call to makechrootpkg if I want a different value. Consistent behavior would be nice though.