Defining the behaviour of code formatting in openbmc-build-scripts

[Andrew Jeffery]

On Wed, 30 Mar 2022, at 01:59, Ed Tanous wrote:
> On Mon, Mar 28, 2022 at 7:08 PM Andrew Jeffery <andrew at aj.id.au> wrote:
>>
>> There are 4 possible behaviours that openbmc-build-scripts could take against
>> an application repository:
>>
>> 1. All code formatting is disabled: No further action
>
> Long term, is there a use case for this?  I realize it's required
> temporarily while we make all the repos consistent, but it seems like
> it should ideally be a temporary situation for portions of the
> codebase, and something that eventually we can just enforce globally
> in the project.

IIRC Lei added the behaviour so if you ran the docker container locally 
for testing you could disable code formatting.

>
>>
>> 2. No custom code formatting: Just do whatever the default actions are as
>>    implemented in openbmc-build-scripts
>>
>> 3. Some custom code formatting: Actions to run in addition to the default
>>    actions implemented in openbmc-build-scripts
>>
>> 4. Only custom code formatting: Actions to run in-place of the default actions
>>    implemented in openbmc-build-scripts (which must not be run)
>>
>> Currently openbmc-build-scripts only implements 1, 2 and 4, while
>> entity-manager had assumed 3 was supported.
>>
>> ## Background (AKA why don't we have support for 3?)
>>
>> Code formatting support in openbmc-build-scripts began with an implementation
>> of 1. However, along the way we introduced the phosphor-mboxd repository which
>> due to some unfortunate history has a mixed C and C++ codebase. The C code is
>> written in kernel style, while it was desired that the C++ be written in
>> OpenBMC style.
>>
>> At the time the problem arose, clang-format had two issues:
>>
>> a. It treats C and C++ as the same language, and so maintaining a code
>>    formatting split across those language boundaries requires two separate
>>    clang-format configuration files
>
> Is the core of the issue here that we have different formatting rules
> for C than C++? 

No, because we have other formatters too.

Anyway, this is just the background section that justifies how we got 
to where we are. Changing the recommendation for C code formatting 
wasn't something I was looking to debate here.

> clang-format is entirely whitespace changes, so could
> we solve this simply by just reformatting all the C code to the common
> project style, and we wouldn't need this anymore?  It seems like
> regardless of C vs C++ we should be consistent.

We could, but that's not what's currently documented:

https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#c

Andrew