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.
