On 09/08/2019 07:15, Nathan Chancellor wrote: > On Thu, Aug 08, 2019 at 03:42:32PM -0700, 'Nick Desaulniers' via Clang Built Linux wrote: >> On Thu, Aug 8, 2019 at 2:07 PM Guillaume Tucker >> <guillaume.tucker@xxxxxxxxxxxxx> wrote: >>> >>> Only use gcc/g++ for HOSTCC, HOSTCXX and CC by default if they are not >>> already defined in the environment. This fixes cases such as building >>> host tools with clang without having gcc installed. >>> >>> The issue was initially hit when running merge_config.sh with clang >>> only as it failed to build "HOSTCC scripts/basic/fixdep". >> >> Thanks for the patch. I don't quite follow the exact error. >> >> When building with Clang, I usually do: >> >> $ make CC=clang HOSTCC=clang ... >> >> are you trying to fix the case where you do: >> >> $ make CC=clang ... >> <no HOSTCC set> >> when GCC is not installed? Because if so, I think it would be easier >> to just specify HOSTCC=clang, but maybe I'm misunderstanding the >> issue? > > As I understand it, > > $ make CC=clang HOSTCC=clang > > works fine. What doesn't currently work is: > > $ export CC=clang > $ export HOSTCC=clang > $ make > > This is problematic because there is no way for CC, HOSTCC, and HOSTCXX > to be passed to make within scripts/kconfig/merge_config.sh. > > A quick test before and after the patch: > > $ ( export HOSTCC=clang; make -j$(nproc) O=out defconfig V=1 ) > ... > gcc -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wmissing-prototypes... > gcc -Wp,-MD,scripts/kconfig/.confdata.o.d -Wall -Wmissing-prototypes... > ... > $ ( export HOSTCC=clang; make -j$(nproc) O=out defconfig V=1 ) > ... > clang -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes... > clang -Wp,-MD,scripts/kconfig/.confdata.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes... > ... > > Reviewed-by: Nathan Chancellor <natechancellor@xxxxxxxxx> > Tested-by: Nathan Chancellor <natechancellor@xxxxxxxxx> Thanks for the review. > I wonder if all variable should be converted to that scheme or just the > ones that are needed in this instance. I also wonder if this will cause This is what Mark also asked. If we want to use ?= then I can send another patch to cover all the other variables. It also makes sense to be able to choose an alternative linker, in particular LLVM's ld.lld was brought up recently in some KernelCI discussions. > any issues with people who define these variables in their environment > already; if so, maybe merge_config.sh should be updated to support > passing CC, HOSTCC, and HOSTCXX to make. I think the reason for the RFC essentially boils down to this. On the other hand, if someone exports HOSTCC or CC to use some specific compiler, they would expect it to be used. It would seem like a bit strange to export one value for a variable and then pass another one to make (i.e. "export CC=gcc; make CC=clang"). Also, passing all the variables to make in merge_config.sh as well as any other place where this may happen is likely to be rather error-prone and hard to maintain, say if new variables get introduced in the Makefile or if some new scripts start calling make. So I'll prepare a new patch using the ?= approach. Meanwhile we'll see if someone can find a good reason why this can actually be problematic. Best wishes, Guillaume
