Re: [Xen-devel] [PATCH 1/5] make: simplify setting HOST{CC/CXX}

[Jan Beulich <JBeulich@xxxxxxxx>]

On 28.06.2019 12:15, Roger Pau Monné  wrote:
> On Fri, Jun 28, 2019 at 09:29:53AM +0000, Jan Beulich wrote:
>>   >>> On 26.06.19 at 15:55, <roger.pau@xxxxxxxxxx> wrote:
>>   > --- a/Config.mk
>>   > +++ b/Config.mk
>>   > @@ -39,22 +39,12 @@ DESTDIR     ?= /
>>   >  # Allow phony attribute to be listed as dependency rather than fake
>> target
>>   >  .PHONY: .phony
>>   >
>>   > -# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
>>   > -ifeq ($(XEN_TARGET_ARCH), $(XEN_COMPILE_ARCH))
>>   > -HOSTCC ?= $(CC)
>>   > -HOSTCXX ?= $(CXX)
>>   > -endif
>>   > -
>>   >  # Use Clang/LLVM instead of GCC?
>>   >  clang ?= n
>>   >  ifeq ($(clang),n)
>>   >  gcc := y
>>   > -HOSTCC ?= gcc
>>   > -HOSTCXX ?= g++
>>   >  else
>>   >  gcc := n
>>   > -HOSTCC ?= clang
>>   > -HOSTCXX ?= clang++
>>   >  endif
>>
>> The inclusion point leading to config/StdGNU.mk sits below
>> here afaict, so I don't see how ...
>>
>>   > --- a/config/StdGNU.mk
>>   > +++ b/config/StdGNU.mk
>>   > @@ -9,6 +9,10 @@ CC        ?= $(CROSS_COMPILE)gcc
>>   >  CXX       ?= $(CROSS_COMPILE)g++
>>   >  LD_LTO    ?= $(CROSS_COMPILE)ld
>>   >  endif
>>   > +
>>   > +HOSTCC    ?= $(CC)
>>   > +HOSTCXX   ?= $(CXX)
>>
>> ... these are every going to take effect - the two variables aren't
>> unset anymore at that point.
> 
> I'm not sure I follow, after this change the only place where
> HOST{CC/CXX} are set is in StdGNU.mk, so those variables would be
> unset unless they are set in the environment.

Oh, I'm sorry - the first pair being a removal of lines I took it that
the 2nd and 3rd pairs would be additions, when clearly they're
removals too. I'm sorry for the noise here.

>> Furthermore, when CROSS_COMPILE
>> is not empty, this is certainly not what we want.
> 
> TBH I would like some guidelines about how CROSS_COMPILE is supposed
> to be used.

It never having been spelled out, I guess it's down to the various flavors
people might be using. For me personally CROSS_COMPILE isn't flexible
enough anyway, so I have to further alter it in a local patch I carry (to
accommodate for suffixes on the command names alongside prefixes).

> I agree the above is not very nice when CROSS_COMPILE is set. What
> about something like:
> 
> ifeq ($(clang),y)
> CC        ?= clang
> CXX       ?= clang++
> LD_LTO    ?= llvm-ld
> HOSTCC    ?= $(CC)
> HOSTCXX   ?= $(CXX)
> CC         = $(CROSS_COMPILE)$(CC)
> CXX        = $(CROSS_COMPILE)$(CXX)
> LD_LTO     = $(CROSS_COMPILE)$(LD_LTO)
> else
> [...]
> 
> That would keep the current behaviour of setting CC=gcc
> CROSS_COMPILE=arm-linux-gnueabi-, which my previous approach didn't.

Hmm, yes, this might work for many cases. (The CC/CXX/LD_LTO lines then
wouldn't need to be inside the ifeq() anymore, though.)

However, consider this invocation, which I use for pre-push build checks
on a 32-bit host:

make -sC build/xen/$v {XEN_TARGET_ARCH,t}=x86_64 CC=gccx LD=ldx 
OBJCOPY=objcopyx NM=nmx -j32 xen

The "t" environment variable is used by gccx (which is a shell script).
That same shell script would then get invoked for uses of $(HOSTCC),
and wrongly try to build a 64-bit object/binary. I'm afraid it is wrong
in general to derive HOSTCC from CC.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel