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

Patrick Williams patrick at stwcx.xyz
Wed Mar 30 03:58:48 AEDT 2022


On Tue, Mar 29, 2022 at 09:22:01PM +1030, Andrew Jeffery wrote:
> On Tue, 29 Mar 2022, at 15:56, Patrick Williams wrote:
> > There has been talk previously about making something like
> > `.openbmc/config.json` as a further configuration file where we could
> > enable / disable all these check.  I think it would be worthwhile as a
> > way to eliminate many of the "search for special file X" checks we have
> > where we simply touch an empty file, but I suspect we really shouldn't
> > be using the "touch a magic empty file" mechanism anyhow.
> 
> This is related but is starting to feel a little tangential. I think we 
> can get away without trying to switch things to a json config for now?

I wasn't sure the scope of what you wanted to tackle right now so I was
giving you the full-spectrum of my thoughts.  We could certainly make a
tactical solution that resolves the issue in EM, but I think we still
have a mess on our hands w.r.t. specifying what linters and formatters
are ran in CI.  Random dot files, deviations in formatting rules between
languages, and undocumented combinations of testing are all artifacts of
the mess, but that mess doesn't necessarily need to be cleaned up today.

(*) I'll make the argument once again that having to support autotools,
CMake, and Meson in our CI additionally makes this mess even bigger.
You'll notice there are actually deviations in what gets tested and how
between the 3.

> Thanks for the feedback. Should I push a patch to capture this as a 
> design doc?

If all we're doing is making it so that `format-code` always runs, I
don't think this warrants a design document.  If you're looking to
tackle something larger that probably does belong in a design document.
Documenting the as-is shouldn't be in a design document, in my opinion,
and trying to frame it as a design is probably going to generate a lot
more discussion on ideal vs present than is useful if we're not going to
make much investment in the implementation.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220329/6eff31fa/attachment-0001.sig>


More information about the openbmc mailing list