Hi Jan,
>> + {
>> + "rel_path": "arch/x86/include/asm/bug.h",
>> + "comment": "Includes mostly assembly macro"
>> + },
>
> Mind me asking why assembly macros wouldn't want maintaining in proper
> style?
From what I know (experts on CF correct me if I am wrong) clang-format is meant
to format only some languages
(C/C++/...) and assembly is not one of them, so what is happening is that most
of the time clang-format breaks
it, in fact we are formatting only .c and .h, but since we have some headers
with assembly macros, I’ve seen some issues
that ranges from really ugly formatting to build break.
One thing we could do, is to export the headers that contain only assembly
stuffs in dedicate headers (<header>_asm.h ?)
so that we could easily use a name regex to exclude "*_asm.h” from
clang-format? And also these headers could #error if
included when __ASSEMBLY__ is not defined?
But this requires some agreement on what is the best way I guess, you can know
better if it’s feasible or not.
>>
>> + {
>> + "rel_path": "include/public/**/**/*.h",
>> + "comment": "Public headers are quite sensitive to format tools"
>> + },
>> + {
>> + "rel_path": "include/public/**/*.h",
>> + "comment": "Public headers are quite sensitive to format tools"
>> + },
>
> The common meaning of ** that I know is "any level directories", but
> since you use **/**/ above that can't be it here. Could you clarify
> what the difference of */ and **/ is here (or maybe in JSON in general)?
Yes I’ve found that python glob, that we use to solve the wildcard, solves the
** only for one level,
maybe we could do something better to solve that, but for now I left it as it
is to focus on the
clang-format configuration side.
Cheers,
Luca
>
> Jan
