Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

["Michael D Kinney" <michael.d.kinney@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 4665 bytes --]

Andrew,

Agree that we want it to be very simple and walk up and use.

There is no requirement to use Visual Studio Code.

There are multiple ways available for use by developers

  1.  Visual Studio Code plugin.
  2.  Run uncrustify tool from command line.
  3.  Implement a githook that automatically runs uncrustify as part of local commit.
  4.  If you look at bottom of this readme it describe how to integrate with Vim and IntelliJ

https://github.com/uncrustify/uncrustify

What is critical at this stage is identifying specific work items to complete the source style conversion.  Defining exactly “how we do it” is important for success.  Looks like your suggestion for the developer use case is a download page that auto picks the right installer.

Best regards,

Mike

From: Andrew Fish <afish@apple.com>
Sent: Tuesday, November 9, 2021 10:14 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>; Gerd Hoffmann <kraxel@redhat.com>; Marvin Häuser <mhaeuser@posteo.de>; Michael Kubacki <Michael.Kubacki@microsoft.com>; mikuback@linux.microsoft.com; rebecca@nuviainc.com; Bret Barkelew <Bret.Barkelew@microsoft.com>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

Mike,

My main concern is there is an easy path for the developers. I don’t want to have developers have to learn new development technologies just to run a “required” tool. I’m not as concerned on how we do it. Hosting binaries from a webpage that auto picks what to download would be fine with me.

I think the important thing is we make this walkup an use, and we write up the instructions not assuming “other knowledge”.

My use case is probably uncommon. We don’t use brew, but there is an internal brew we can use. So we generally just install build tools into our repo. We  are more flexible on personal productivity tools so I’d probably consider switching to Visual Studio Code, especially if there was an Extension in the Marketplace I could just click on to configure Code for edk2 development. On the other hand nothing inspires hate like asking people to switch their editor, so I don’t think we can depend on Code as the solution.

Thanks,

Andrew Fish


On Nov 9, 2021, at 7:08 AM, Michael D Kinney <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>> wrote:

Submodule within which repo?  What would be the proposed location?

Would a fork of uncrustify maintained as a repo under TianoCore work as well?

There are CI checks (including extensive unit tests) and release generation that are built into uncrustify repo and I do not know if those will be functional if it is maintained as a submodule.

Thanks,

Mike


-----Original Message-----
From: Leif Lindholm <leif@nuviainc.com<mailto:leif@nuviainc.com>>
Sent: Tuesday, November 9, 2021 4:37 AM
To: Gerd Hoffmann <kraxel@redhat.com<mailto:kraxel@redhat.com>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>; Marvin Häuser
<mhaeuser@posteo.de<mailto:mhaeuser@posteo.de>>; Michael Kubacki <Michael.Kubacki@microsoft.com<mailto:Michael.Kubacki@microsoft.com>>; mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>; rebecca@nuviainc.com<mailto:rebecca@nuviainc.com>;
Bret Barkelew <Bret.Barkelew@microsoft.com<mailto:Bret.Barkelew@microsoft.com>>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?

On Tue, Nov 09, 2021 at 09:40:02 +0100, Gerd Hoffmann wrote:

 Hi,


 3.  Require use of uncrustify tool before submitting patch review emails or PRs.
    *   The required version would be a formally released version  from the fork maintained by Michael Kubacki until
the changes can be upstreamed.

    *   https://dev.azure.com/projectmu/Uncrustify

Can we please *first* get the changes merged to upstream uncrustify?

That'll make the whole process much less painful because the usual
software repositories (linux distro packages, macos homebrew, ...)
can be used to install uncrustify then, and it's also less confusing if
developers don't have to juggle with different uncrustify variants
(upstream vs. edk2).

Whilst I agree in principle...

This means postponing automated coding style changes until 2023
(Debian stable), 2025 (Ubuntu LTS), ??? (RHEL10), or even later
... and I'd rather not.

I like Marvin's suggestion of a submodule. Which we could drop once
no longer needed.

/
   Leif





[-- Attachment #2: Type: text/html, Size: 53474 bytes --]