[pacman-dev] [PATCH 2/2] Split prepare_buildenv() to libmakepkg scripts

[Que Quotion]

>> +	if check_option "debug" "y"; then
>> +		DEBUG_CFLAGS+=" -fdebug-prefix-map=$srcdir=${DBGSRCDIR:-/usr/src/debug}"
>> +		DEBUG_CXXFLAGS+=" -fdebug-prefix-map=$srcdir=${DBGSRCDIR:-/usr/src/debug}"
>> +		CFLAGS+=" $DEBUG_CFLAGS"
>> +		CXXFLAGS+=" $DEBUG_CXXFLAGS"
>> +	fi
>> +
>> +	# ensure all necessary build variables are exported
>> +	export CPPFLAGS CFLAGS CXXFLAGS LDFLAGS MAKEFLAGS CHOST
>> +}
>
>Why is this on its own, not in a dropin?

I needed feedback on this; since the debugflags don't have a corresponding build_option I wasn't sure what to do with them. Your feedback on the ccache/distcc section 
gave me an idea.

>> +build_options+=('buildflags')
>
>If you look at the way we do this in other sections, this should
>probably be namespaced as buildenv_buildflags

I've kept the name as it was in the original implementation to avoid upsetting anyone who might be using this flag in a PKGBUILD or makepkg.conf.

>> +ccache() {
>> +	if check_buildoption "ccache" "y"; then
>> +		if ! type -p ccache >/dev/null; then
>> +			error "$(gettext "Cannot find the %s binary required for compiler cache usage.")" "ccache"
>> +			return 1
>> +		fi
>> +
>> +		if [ -d /usr/lib/ccache/bin ]; then
>> +			export PATH="/usr/lib/ccache/bin:$PATH"
>> +			ccache=1
>> +		fi
>> +	fi
>> +}
>
>ccache is now both a function name and a variable name...
>
>And the variable is declared as local, but outside of a function --
>instead, it's relying on the fact that libmakepkg typically sources this
>file while inside another function. I don't know whether we should be
>doing this...
>
>I'm inclined to think that at least ccache and distcc should be in the
>same dropin file and parsed as the same buildenv function as a result.
>Maybe buildenv_compiler.

I'd rather have them separate, as they may be used separately, but then I don't know how to ensure the ccache macro would be called before the distcc macro, so I put 
them into compiler.sh.in

Attached patch is succesive, and should be applied after the previous. I can resubmit if you want a single patch.