Best regards,
Marvin
09.11.2021 04:03:06 Kinney, Michael D <michael.d.kin...@intel.com>:
Andrew,
I think Michael Kubacki started with a nuget feed because that can be easily
used by EDK II CI agents.
However, that does not work as easily for all development environments using
Windows, Linux, and MacOS. Creating
releases that can be easily installed by developers is critical for success.
For MacOS, there is a homebrew recipe. You should just have to update the URL
to the uncrustify fork.
https://macappstore.org/uncrustify/
Adding the installation information to the EDK II Getting Started page would be
a good place to capture the developer
install.
Mike
*From:* Andrew Fish <af...@apple.com>
*Sent:* Monday, November 8, 2021 6:47 PM
*To:* Kinney, Michael D <michael.d.kin...@intel.com>
*Cc:* devel@edk2.groups.io; Marvin Häuser <mhaeu...@posteo.de>; Michael Kubacki
<michael.kuba...@microsoft.com>; Leif
Lindholm <l...@nuviainc.com>; mikub...@linux.microsoft.com;
rebe...@nuviainc.com; Bret Barkelew
<bret.barke...@microsoft.com>
*Subject:* Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?
On Nov 8, 2021, at 5:13 PM, Kinney, Michael D <michael.d.kin...@intel.com>
wrote:
HI Andrew,
Great feedback.
What your preferred way to install a tool like this? If we collect that data
from the community, we can make sure the
pipeline generates the right type of installers.
I could not figure out how to download an installer from the links.
If I go to http://uncrustify.sourceforge.net I see
https://sourceforge.net/projects/uncrustify/files/ and a button to
download binaries. Not ideal that it is only for Windows but at least the
workflow was obvious. Looks like I need to build
my own version for macOS, not ideal but I can at least figure that out.
Worst case we can have a Tianocore.org[http://Tianocore.org] page to describe a
simple recipe to install the tool. With
step by step instructions some one can just type in without thinking too much.
Thanks,
Andrew Fish
Thanks,
Mike
*From:* Andrew Fish <af...@apple.com>
*Sent:* Monday, November 8, 2021 5:09 PM
*To:* devel@edk2.groups.io; Kinney, Michael D <michael.d.kin...@intel.com>
*Cc:* Marvin Häuser <mhaeu...@posteo.de>; Michael Kubacki
<michael.kuba...@microsoft.com>; Leif Lindholm
<l...@nuviainc.com>; mikub...@linux.microsoft.com; rebe...@nuviainc.com; Bret
Barkelew <bret.barke...@microsoft.com>
*Subject:* Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?
MIke,
I could not figure out how to download uncrustify tool from the provided link.
99% of the people are just going to want
to install the tool, not be a developer of the fork. We should have some simple
instructions on how to download the tool.
The link points to something git web view looking Azure DevOps page and talks
about this Nuget thing I know nothing
about. I ran out of time and had to give up trying to download the tool.
Thanks,
Andrew Fish
On Nov 8, 2021, at 4:23 PM, Michael D Kinney <michael.d.kin...@intel.com> wrote:
Hello,
Good information in this thread on code style.
Some of the topics apply to uncrustify and some are out of scope for what
uncrustify can fix on its own.
I would like to focus on a date to convert all source code in edk2 repo using
the uncrustify tool and to capture the
other code style topics into their own thread andbugzillas.
I would like to propose a conversion date for uncrustify immediately after the
edk2-stable202111 release on 2021-11-26.
I have been working with Michael Kubacki on a build comparison tool that
verifies that the build generate the same
obj/lib/dll/efi/fv/fd files before and after the uncrustify changes. We would
run and publish the results from this tool
before committing the changes.
We need TianoCore community approval of the following:
1. > Approve format of C source generated by the uncrustify.
2. > Approve uncrustify changes right after edk2-stable-202111 release.
1. > Extend code freeze until these changes are committed.
3. > Require use of uncrustify tool before submitting patch review emails or
PRs.
1. > The required version would be a formally released version from the
fork maintained by Michael Kubacki until the
changes can be upstreamed.
2. > https://dev.azure.com/projectmu/Uncrustify
4. > Add EDK II CI check to verify that all PRs submitted exactly match
uncrustified version. Reject PRs that do not
match exactly.
5. > Implement a git hook available that would automatically run uncristufy
before committing changes to a local branch of
an edk2 repo.
Thanks,
Mike
*From:* Andrew Fish <af...@apple.com>
*Sent:* Thursday, October 7, 2021 2:09 PM
*To:* Marvin Häuser <mhaeu...@posteo.de>
*Cc:* edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D
<michael.d.kin...@intel.com>; Leif Lindholm
<l...@nuviainc.com>; mikub...@linux.microsoft.com; rebe...@nuviainc.com; Michael
Kubacki <michael.kuba...@microsoft.com>;
Bret Barkelew <bret.barke...@microsoft.com>
*Subject:* Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?
On Oct 7, 2021, at 1:43 PM, Marvin Häuser <mhaeu...@posteo.de> wrote:
Hey Mike,
Hey Andrew,
I'll just reply to both mails at once :)
On 07/10/2021 19:36, Andrew Fish wrote:
…
Thanks! I'd keep STATIC actually just for the sake of not doing no-op changes
that do not really do anything and for
consistency with CONST, but whatever works really.
…
Yes.
…
This issue is independent of CONST. I’m not sure a coding style tool is smart
enough to catch this generically? You need
an understanding of C types to know if the local variable assignment is going
to trigger a memcpy().
What I’ve seen in the real world is the firmware compiles with -Os or LTO to
fit int he ROM for DEBUG and RELEASE, and
the optimizer optimizes away the call to memcpy. Then if you try to build NOOPT
(or over ride the compiler flags on an
individual driver/lib) you fail to link as only the NOOPT build injects the
memcpy.
+1
Thus I think the best way to enforce this rule is to compile a project NOOPT.
I’m trying to remember are there flags to
built to tell it to compile and skip the FD construction? Maybe we should
advocate platforms add a NOOPT build target that
just compiles the code, but does not create the FD?
I know there were stability concerns with intrinsics in the past, but memcpy()
is in the standard, and the rest remained
stable to my knowledge. Maybe it's time to fix the issues at the root? Works
for us:
https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcCompilerIntrinsicsLib
Marvin,
Good point. This would make the rule moot. So maybe just removing the
requirement would be the easiest long term fix.
Other embedded projects I know of do this too, and as you point out the
compilers keep these APIs standard for folks the
provide their own runtimes.
Thanks,
Andrew Fish
Best regards,
Marvin
Thanks,
Andrew Fish
…
