On 03.12.2019 12:04, Roger Pau Monné wrote:
> On Tue, Dec 03, 2019 at 11:03:31AM +0100, Jan Beulich wrote:
>> Furthermore I think this moving around of logic (which imo
>> would better remain at the bottom of the file, well out of
>> sight) is only the second best solution to the issue. The
>> reason I didn't notice the breakage was because I had noticed
>> what made me create the patch in question only while putting
>> together a change moving out the majority of the as-option-add
>> invocations, primarily with the goal of not having the
>> compiler invoked over and over just to calculate CFLAGS. I
>> didn't post this change yet simply because I wanted to give it
>> some more (local) testing.
> Looks like an improvement, but how do you plan to achieve the same?
> Are there some compiler/assembler hints available at build time about
> which features are supported?

No, I'm changing the mechanism altogether. The various HAVE_AS_*
will be put in a generated header file instead. Its generation
(obviously) happens with CFLAGS already in final shape.

>> Another reason to keep this at the bottom of the file is that
>> other CFLAGS additions wouldn't have happened yet at the
>> place the checks live now.
> Right, but it's unlikely that CFLAGS can influence whether the
> internal assembler is capable of building Xen or not, while it's IMO
> more likely that using the internal or an external assembler can lead
> to a different set of CFLAGS (as CFLAGS also include options that
> affect the assembler).

For simple checks against insns being known I agree. But already
something like

# Set up the assembler include path properly for older toolchains.
CFLAGS += -Wa,-I$(BASEDIR)/include

could make a difference, if a more complex check involved
including some other file.


Xen-devel mailing list

Reply via email to