On 5/3/2023 10:56 PM, Gerd Hoffmann wrote:
Hi,
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.
Are there cases where /old/ iasl versions are required?
Yes. On the commercial PC side we see this a lot. Given how much ASL
is in modern PCs it is very common for a platform's ASL code to not
compile with the latest version. That product and by extension, the ASL
code, is often supported for 5+ years and then if you add on that the
ASL compiler was probably already a year old at initial release that
means the compiler can often be pretty old. Additionally for those
building brand new products that are using new capabilities in ACPI,
they often need the newest version and can't wait for the distro package
repository to pick up. As a outsider/consumer of Linux, we have
definitely had pain caused by the distro's default/available version.
For the Edk2 repo I can remember a lot of challenges around python 2 and
3 and versions and the various distro's package management.
Additionally, for CI we want to drive consistency between Windows and
Linux. We want visibility into versions used and reproducibility.
Depending on distro package management make this significantly harder.
EmulatorPkg, ArmVirtPkg, and OVMF could all opt into using the "scope"
(edk2/Readme.md at master · tianocore/edk2 · GitHub
<https://github.com/tianocore/edk2/blob/master/.pytool/Readme.md#pytool-scopes>)
that would leverage the Core CI's version of iasl so that they don't
need to manage this but my initial hope was to showcase this capability
and allow those "platforms" some of their own autonomy. Obviously they
haven't needed or used that yet so as we update Core CI we could also
update those platforms to follow with the same extdep and version.
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.
On linux / macos / *bsd there is usually no need to create your own
package management. Standard stuff like iasl / nasm is available as
linux distro package / bsd ports collection package.
Usually you can't pick specific versions. Usually this isn't a big
issue though, unless you are using an older distro (such as ubuntu 18.04
we used for CI before switching to containers) and need a recent version.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104084): https://edk2.groups.io/g/devel/message/104084
Mute This Topic: https://groups.io/mt/98669896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
