Re: [PATCH] x86: sort obj-<...> list of main Makefile

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.06.2026 11:10, Andrew Cooper wrote:
> On 24/06/2026 8:50 am, Jan Beulich wrote:
>> It is mostly sorted, but there are anomalies. Eliminating them gives
>> people fewer excuses to (blindly) add to the end of the list.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks.

> Do you want me to pull this into for-next?  I'll (hopefully) be queuing
> the series which caused you to notice it into for-next in due course.

Feel free if you want to, but I'll get this in soon after branching anyway.

>> ---
>> Of course sorting with underscores or dashes in filenames is always going
>> to be ambiguous: Some may prefer C locale sorting, some may prefer sorting
>> as if non-alphanumeric characters simply weren't there, and some may
>> prefer yet different criteria. But those corner cases probably aren't even
>> worth formally settling on a particular model.
> 
> That's not a relevant consideration in this patch is it?  I see no
> ambiguity.

I thought io_apic.o vs ioport_emulate.o would have been affected, but they
aren't.

> Also, if in doubt, surely always C locale?  Pretending that _- aren't
> present is definitely a bad sorting algorithm.

ls looks to be using this by default, so it can't be all that bad.

>> x86_emulate.o coming rather late in the list may want considering to make
>> an exception for: It takes comparably long to build, and hence it may be
>> best if it got scheduled as early as possible in a parallel make.
> 
> Move it to the front with a comment saying "Really a subdir, but not
> expressed in that way" or something?

We have

obj-y += x86_emulate/

there, so excusing this by what you say would feel somewhat wrong.
Mentioning in a comment that it's there for build performance would look
okay to me. I raised the question mainly to get an understanding whether
such an exception would be acceptable at all.

Jan