Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ?

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

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

Sean,

Can a GitHub release area for each dependency be used as an alternative to nuget?

Mike

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
Sent: Wednesday, May 3, 2023 12:51 PM
To: devel@edk2.groups.io; rebecca@bsdio.com; Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>; Michael Kubacki <mikuback@linux.microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>
Subject: Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ?


Rebecca,

I agree the iasl dependency for CI has not been managed consistently.   When all of the CI was setup we decided that iasl should be controlled by the platform and thus EmulatorPkg, ArmVirt, and OVMF have their own extdep.  This gives those platforms control to rev their version as necessary for their platform.   We have found it very common in platform development for platforms to have different required versions of iasl.exe.

For Core CI (meaning just package builds) we managed iasl in Basetools.  We decided that this would only need to be updated when newer features were used by core components (not very often given the very little ASL in edk2 tree).



As for the feed.  Yes they are inconsistent.   We were moving away from a global nuget.org feed as it just didn't seem necessary to push to nuget.org.  But now we are evaluating ways to move entirely away from nuget.  Nuget.exe worked pretty well for Windows development and our initial use cases but has definitely created a headache on Linux, MacOS and other.  There really isn't a generic package management solution that is supported cross platform that has free/high quality/secure hosting.  If anyone has ideas please share.



So my suggestion is to hold off for a couple of weeks (unless something is broken) and lets see if we can use web downloads from github releases.  This should still allow consistency with tools, work cross platform, and give the flexibility needed per platform.



Regarding the steps in that document.  In that example it doesn't call out all the steps needed as that would just rehash the section before.  Instead it relies on a user having followed the generic steps in the section above (How to Build With Stuart · tianocore/tianocore.github.io Wiki<https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-With-Stuart#how-to-build-in-edk2-with-stuart>).  For example the user would need to have also done:  setup python virtual env, install pypi dependencies, and clone source + submodules.



Thanks

Sean






On 5/3/2023 12:34 PM, Rebecca Cran wrote:
I noticed OvmfPkg/PlatformCI/iasl_ext_dep.yaml specifies iasl version 20190215.0.0 while BaseTools/Bin/iasl_ext_dep.yaml has the newer 20200717.0.0, and "mono .../edk2toolext/bin/NuGet.exe list -Source https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/v3/index.json" shows there's version 20210105.0.6 available.


Though OvmfPkg is using source https://api.nuget.org/v3/index.json while BaseTools uses https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/v3/index.json - I don't know why they're different.


I was wondering if iasl_ext_dep.yaml should be updated?


Also, the example in https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-With-Stuart of using stuart_build to build OVMF seems to be missing a step: running "stuart_update -c PlatformBuild.py TOOL_CHAIN_TAG=GCC5 -a X64" appears to be required otherwise stuart_build will complain that the iasl dependency hasn't been met.



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