As suggested, I used the following content in the DSC file to pass all the builds:
OUTPUT_DIRECTORY = Build/UefiPayloadPkgIA32
FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf
OUTPUT_DIRECTORY = Build/UefiPayloadPkgX64
FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf
OUTPUT_DIRECTORY = Build/UefiPayloadPkgAARCH64
FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf
I have tried following build commands, they all succeed to build corresponding binaries:
- build -p UefiPayloadPkg/UefiPayloadPkg.dsc -b DEBUG -a IA32 -a X64 -a AARCH64 -t GCC5
- python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -b DEBUG --FIT
- python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -a IA32 -b DEBUG --FIT
- python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -a AARCH -b DEBUG --FIT
Now I am creating a new draft PR to fix all github CI failures which are not generated in my local.
Thanks again for your help.
I appreciate the pointer.
However, that's the .inf spec.
The same language is not in the corresponding section of
> For your awareness, Section 3.4 of the INF specification states that architectural modifiers for the [Defines] section tag are not permitted.
> So that you can Ctrl+F and to find the exact language, here is a quote:
> "architectural modifiers for the [Defines] section tag are not permitted"
> -----Original Message-----
> Sent: Tuesday, January 7, 2025 11:05 AM
> Subject: [EXTERNAL] [edk2-devel] Expansion of ARCH in .dsc files
> So... I originally tripped over my misunderstanding of <subject> when writing
> Now Ajan has run into at least an adjacent problem when trying to rework
> Now, the thing I had misunderstood before is that when build is called with multiple -a options, the ARCH variable will expand to a space-separated list of *all* the specified architectures.
> A lot of Arm/AArch64 modules assume this variable only ever contains a single architecture.
> The thing is, I don't think this is clearly documented in the .dsc specification at all. And it is frequently used as a shorthand in there in a form that would only work if build was called with a single -a.
> Now, this also means that there are nearly no correct users of ARCH in
> edk2 or edk2-platforms.
> Because "the list of all architectures being built simultaneously"
> simply isn't very useful information
> build-time. There are two correct uses in edk2, in EmulatorPkg.dsc and in UefiPayloadPkg.dsc, using '!if "IA32" in "$ARCH"', which as far as I can tell is the only possible way to use the variable correctly.
> Slightly amusingly, EmulatorPkg.dsc also contains an incorrect use.
> I guess the behaviour is a direct result of how the build command is architected.
> I guess the one question I have is - is this the intended behaviour?
> Ard: I think we need to update some of our .dsc files...
> Ajan: one somewhat hacky workaround I can think of to separate the output images is to hardcode the output image name in arch-specific Defines sections, like so:
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index 0bd8d85cab03..f07f2b91764e 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> # Defines Section - statements that will be processed to create a Makefile.
> ################################################################################
> + OUTPUT_DIRECTORY = Build/ArmVirtQemu-ARM
> + OUTPUT_DIRECTORY = Build/ArmVirtQemu-AARCH64
> PLATFORM_NAME = ArmVirtQemu
> PLATFORM_GUID = 37d7e986-f7e9-45c2-8067-e371421a626c
> DSC_SPECIFICATION = 0x00010005
> - OUTPUT_DIRECTORY = Build/ArmVirtQemu-$(ARCH)
> SUPPORTED_ARCHITECTURES = AARCH64|ARM
> BUILD_TARGETS = DEBUG|RELEASE|NOOPT
> SKUID_IDENTIFIER = DEFAULT