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.