[pacman-dev] [PATCH] makepkg: Don't double-layer distcc on ccache

Matti Niemenmaa matti.niemenmaa+pacman-dev at iki.fi
Wed Jan 8 09:06:55 UTC 2020


On Wed, Jan 08, 2020 at 02:15:45AM -0500, Eli Schwartz wrote:
> On 1/7/20 2:51 AM, Matti Niemenmaa wrote:
> > Setting buildenv twice was done on purpose in commit
> > 02a0bf550a22e199f48537b7eee87361b112e8a0, but at a glance I'm not sure
> > whether it provides any benefit. All the meaningful changes are to
> > environment variables that are exported from the parent process anyway,
> > so all the changes are either repeated or even duplicated (like in PATH,
> > or this CCACHE_PREFIX issue). Maybe it would be better to simply remove
> > the prepare_buildenv call from the INFAKEROOT case in makepkg.sh.in?
> 
> makepkg --repackage will skip the build() step, and some package()
> functions actually result in artifacts being rebuilt (not all build
> systems handle this properly).
> 
> While it's true we run prepare_buildenv() before the fakeroot either
> way, so exported variables are still exported, makepkg.conf will often
> (usually?) reset them, and we need to specially handle DEBUG_*FLAGS as
> well as -fdebug-prefix-map.
> 
> The other major problem I see is that we currently have
> buildenv/buildflags.sh.in and buildenv/makeflags.sh.in which actually
> unset variables that may be restored during fakeroot due to reparsing
> makepkg.conf
> 
> package() functions, even when --repackage is *not* used, should still
> respect MAKEFLAGS when running make install, even if you discount
> needing to have consistent CFLAGS when running a dirty package() function.

Right, so it's not as simple as I hoped. The interaction with
makepkg.conf is something I didn't realize. I hope there's still some
sort of nicer alternative to these kinds of pinpoint fixes, but I guess
it wouldn't happen in the short term anyway.


More information about the pacman-dev mailing list