Re: [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter
On 21 June 2013 11:15, Olivier Martin olivier.martin@arm.com wrote:
I am not convinced by this patch. The use case you gave is the automated build system. Nothing prevent you to do a move the folder around after building it.
That's not quite suitable for our CI builds, but I see your point.
Instead of changing all the DSC files of EDK2, I would prefer to see a patch that changes the 'build' command to allow to overwrite the Build directory defined in the DSC file.
That's a preferable option, although it would involve me hacking in python - shudder ;-)
I'll look into the build script if I get some time. Meanwhile, this patch can live in my tree.
-----Original Message----- From: Ryan Harkin [mailto:ryan.harkin@linaro.org] Sent: 21 June 2013 09:05 To: ryan.harkin@linaro.org; edk2-devel@lists.sourceforge.net; patches@linaro.org; boot-architecture@lists.linaro.org; Olivier Martin Subject: [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter
Add support to the build config to allow the user to specify a custom output directory to the build.
This is particularly useful for automated build systems.
Eg. build -a ARM -p ArmPlatformPkg/ArmVExpressPkg/ArmVExpress- CTA9x4.dsc -t ARMLINUXGCC \ -D EDK2_ARMVE_STANDALONE=1 \ -D EDK2_OUT_DIR=Build/vea9
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
.../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 4 ++++ .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 4 ++-- .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 4 ++++ .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 4 ++++ .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 4 ++++ 5 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc index 17aba33..c8b637a 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -21,7 +21,11 @@ PLATFORM_GUID = 0b511920-978d-4b34-acc0- 3d9f8e6f9d81 PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 +!ifdef $(EDK2_OUT_DIR)
- OUTPUT_DIRECTORY = $(EDK2_OUT_DIR)
+!else OUTPUT_DIRECTORY = Build/ArmVExpress-CTA15-A7 +!endif SUPPORTED_ARCHITECTURES = ARM BUILD_TARGETS = DEBUG|RELEASE SKUID_IDENTIFIER = DEFAULT diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc index 3f9654f..b4040c2 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc @@ -21,8 +21,8 @@ PLATFORM_GUID = eb2bd5ff-2379-4a06-9c12- db905cdee9ea PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 -!ifdef $(EDK2_ARMVE_STANDALONE)
- OUTPUT_DIRECTORY = Build/ArmVExpress-CTA9x4-Standalone
+!ifdef $(EDK2_OUT_DIR)
- OUTPUT_DIRECTORY = $(EDK2_OUT_DIR)
!else OUTPUT_DIRECTORY = Build/ArmVExpress-CTA9x4 !endif diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc index 548eee5..16271b0 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc @@ -21,7 +21,11 @@ PLATFORM_GUID = 1665b5b1-529d-4ba1-bd51- c3c9b29a2274 PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 +!ifdef $(EDK2_OUT_DIR)
- OUTPUT_DIRECTORY = $(EDK2_OUT_DIR)
+!else OUTPUT_DIRECTORY = Build/ArmVExpress-RTSM-A15 +!endif SUPPORTED_ARCHITECTURES = ARM BUILD_TARGETS = DEBUG|RELEASE SKUID_IDENTIFIER = DEFAULT diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM- A15_MPCore.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM- A15_MPCore.dsc index 0001f8a..c0940ae 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc @@ -21,7 +21,11 @@ PLATFORM_GUID = 3a91a0f8-3af4-409d-a71d- a199dc134357 PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 +!ifdef $(EDK2_OUT_DIR)
- OUTPUT_DIRECTORY = $(EDK2_OUT_DIR)
+!else OUTPUT_DIRECTORY = Build/ArmVExpress-RTSM-A15_MPCore +!endif SUPPORTED_ARCHITECTURES = ARM BUILD_TARGETS = DEBUG|RELEASE SKUID_IDENTIFIER = DEFAULT diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc index 4315179..bdc2697 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc @@ -21,7 +21,11 @@ PLATFORM_GUID = e46039e0-5bb3-11e0-a9d6- 0002a5d5c51b PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 +!ifdef $(EDK2_OUT_DIR)
- OUTPUT_DIRECTORY = $(EDK2_OUT_DIR)
+!else OUTPUT_DIRECTORY = Build/ArmVExpress-RTSM-A9x4 +!endif SUPPORTED_ARCHITECTURES = ARM BUILD_TARGETS = DEBUG|RELEASE SKUID_IDENTIFIER = DEFAULT -- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
On Jun 21, 2013, at 4:23 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 21 June 2013 11:15, Olivier Martin olivier.martin@arm.com wrote:
I am not convinced by this patch. The use case you gave is the automated build system. Nothing prevent you to do a move the folder around after building it.
That's not quite suitable for our CI builds, but I see your point.
If you build from a script you should be able to do anything you want? "You can solve every problem with another level of indirection, except for the problem of too many levels of indirection".
So you could post process with a mv or preprocess the .dsc file, and restore it from a build script wrapper.
Instead of changing all the DSC files of EDK2, I would prefer to see a patch that changes the 'build' command to allow to overwrite the Build directory defined in the DSC file.
The build command already has a lot of options. I'm not sure adding an option is the right thing to do?
(master)>build --help Usage: build.exe [options] [all|fds|genc|genmake|clean|cleanall|cleanlib|modules|libraries|run]
Copyright (c) 2007 - 2010, Intel Corporation All rights reserved.
Options: --version show program's version number and exit -h, --help show this help message and exit -a TARGETARCH, --arch=TARGETARCH ARCHS is one of list: IA32, X64, IPF, ARM or EBC, which overrides target.txt's TARGET_ARCH definition. To specify more archs, please repeat this option. -p PLATFORMFILE, --platform=PLATFORMFILE Build the platform specified by the DSC file name argument, overriding target.txt's ACTIVE_PLATFORM definition. -m MODULEFILE, --module=MODULEFILE Build the module specified by the INF file name argument. -b BUILDTARGET, --buildtarget=BUILDTARGET Using the TARGET to build the platform, overriding target.txt's TARGET definition. -t TOOLCHAIN, --tagname=TOOLCHAIN Using the Tool Chain Tagname to build the platform, overriding target.txt's TOOL_CHAIN_TAG definition. -x SKUID, --sku-id=SKUID Using this name of SKU ID to build the platform, overriding SKUID_IDENTIFIER in DSC file. -n THREADNUMBER Build the platform using multi-threaded compiler. The value overrides target.txt's MAX_CONCURRENT_THREAD_NUMBER. Less than 2 will disable multi-thread builds. -f FDFFILE, --fdf=FDFFILE The name of the FDF file to use, which overrides the setting in the DSC file. -r ROMIMAGE, --rom-image=ROMIMAGE The name of FD to be generated. The name must be from [FD] section in FDF file. -i FVIMAGE, --fv-image=FVIMAGE The name of FV to be generated. The name must be from [FV] section in FDF file. -C CAPNAME, --capsule-image=CAPNAME The name of Capsule to be generated. The name must be from [Capsule] section in FDF file. -u, --skip-autogen Skip AutoGen step. -e, --re-parse Re-parse all meta-data files. -c, --case-insensitive Don't check case of file name. -w, --warning-as-error Treat warning in tools as error. -j LOGFILE, --log=LOGFILE Put log in specified file as well as on console. -s, --silent Make use of silent mode of (n)make. -q, --quiet Disable all messages except FATAL ERRORS. -v, --verbose Turn on verbose output with informational messages printed, including library instances selected, final dependency expression, and warning messages, etc. -d DEBUG, --debug=DEBUG Enable debug messages at specified level. -D MACROS, --define=MACROS Macro: "Name [= Value]". -y REPORTFILE, --report-file=REPORTFILE Create/overwrite the report to the specified filename. -Y REPORTTYPE, --report-type=REPORTTYPE Flags that control the type of build report to generate. Must be one of: [PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS, EXECUTION_ORDER]. To specify more than one flag, repeat this option on the command line and the default flag set is [PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS] -F FLAG, --flag=FLAG Specify the specific option to parse EDK UNI file. Must be one of: [-c, -s]. -c is for EDK framework UNI file, and -s is for EDK UEFI UNI file. This option can also be specified by setting *_*_*_BUILD_FLAGS in [BuildOptions] section of platform DSC. If they are both specified, this value will override the setting in [BuildOptions] section of platform DSC. -N, --no-cache Disable build cache mechanism
Thanks,
Andrew Fish
That's a preferable option, although it would involve me hacking in python - shudder ;-)
I'll look into the build script if I get some time. Meanwhile, this patch can live in my tree.
On 21 June 2013 17:12, Andrew Fish afish@apple.com wrote:
On Jun 21, 2013, at 4:23 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 21 June 2013 11:15, Olivier Martin olivier.martin@arm.com wrote:
I am not convinced by this patch. The use case you gave is the automated build system. Nothing prevent you to do a move the folder around after building it.
That's not quite suitable for our CI builds, but I see your point.
If you build from a script you should be able to do anything you want? "You can solve every problem with another level of indirection, except for the problem of too many levels of indirection".
So you could post process with a mv or preprocess the .dsc file, and restore it from a build script wrapper.
Hacking the build system is not a solution to my problem.
Instead of changing all the DSC files of EDK2, I would prefer to see a patch that changes the 'build' command to allow to overwrite the Build directory defined in the DSC file.
The build command already has a lot of options. I'm not sure adding an option is the right thing to do?
So if hacking the DSC file in no good, hacking the build system is no good and hacking the build command is no good, is there a sane way to get the EDKII build environment to support a configurable output directory?
(master)>build --help Usage: build.exe [options] [all|fds|genc|genmake|clean|cleanall|cleanlib|modules|libraries|run]
Copyright (c) 2007 - 2010, Intel Corporation All rights reserved.
Options: --version show program's version number and exit -h, --help show this help message and exit -a TARGETARCH, --arch=TARGETARCH ARCHS is one of list: IA32, X64, IPF, ARM or EBC, which overrides target.txt's TARGET_ARCH definition. To specify more archs, please repeat this option. -p PLATFORMFILE, --platform=PLATFORMFILE Build the platform specified by the DSC file name argument, overriding target.txt's ACTIVE_PLATFORM definition. -m MODULEFILE, --module=MODULEFILE Build the module specified by the INF file name argument. -b BUILDTARGET, --buildtarget=BUILDTARGET Using the TARGET to build the platform, overriding target.txt's TARGET definition. -t TOOLCHAIN, --tagname=TOOLCHAIN Using the Tool Chain Tagname to build the platform, overriding target.txt's TOOL_CHAIN_TAG definition. -x SKUID, --sku-id=SKUID Using this name of SKU ID to build the platform, overriding SKUID_IDENTIFIER in DSC file. -n THREADNUMBER Build the platform using multi-threaded compiler. The value overrides target.txt's MAX_CONCURRENT_THREAD_NUMBER. Less than 2 will disable multi-thread builds. -f FDFFILE, --fdf=FDFFILE The name of the FDF file to use, which overrides the setting in the DSC file. -r ROMIMAGE, --rom-image=ROMIMAGE The name of FD to be generated. The name must be from [FD] section in FDF file. -i FVIMAGE, --fv-image=FVIMAGE The name of FV to be generated. The name must be from [FV] section in FDF file. -C CAPNAME, --capsule-image=CAPNAME The name of Capsule to be generated. The name must be from [Capsule] section in FDF file. -u, --skip-autogen Skip AutoGen step. -e, --re-parse Re-parse all meta-data files. -c, --case-insensitive Don't check case of file name. -w, --warning-as-error Treat warning in tools as error. -j LOGFILE, --log=LOGFILE Put log in specified file as well as on console. -s, --silent Make use of silent mode of (n)make. -q, --quiet Disable all messages except FATAL ERRORS. -v, --verbose Turn on verbose output with informational messages printed, including library instances selected, final dependency expression, and warning messages, etc. -d DEBUG, --debug=DEBUG Enable debug messages at specified level. -D MACROS, --define=MACROS Macro: "Name [= Value]". -y REPORTFILE, --report-file=REPORTFILE Create/overwrite the report to the specified filename. -Y REPORTTYPE, --report-type=REPORTTYPE Flags that control the type of build report to generate. Must be one of: [PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS, EXECUTION_ORDER]. To specify more than one flag, repeat this option on the command line and the default flag set is [PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS] -F FLAG, --flag=FLAG Specify the specific option to parse EDK UNI file. Must be one of: [-c, -s]. -c is for EDK framework UNI file, and -s is for EDK UEFI UNI file. This option can also be specified by setting *_*_*_BUILD_FLAGS in [BuildOptions] section of platform DSC. If they are both specified, this value will override the setting in [BuildOptions] section of platform DSC. -N, --no-cache Disable build cache mechanism
Thanks,
Andrew Fish
That's a preferable option, although it would involve me hacking in python - shudder ;-)
I'll look into the build script if I get some time. Meanwhile, this patch can live in my tree.
On Jun 21, 2013, at 10:36 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 21 June 2013 17:12, Andrew Fish afish@apple.com wrote:
On Jun 21, 2013, at 4:23 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 21 June 2013 11:15, Olivier Martin olivier.martin@arm.com wrote:
I am not convinced by this patch. The use case you gave is the automated build system. Nothing prevent you to do a move the folder around after building it.
That's not quite suitable for our CI builds, but I see your point.
If you build from a script you should be able to do anything you want? "You can solve every problem with another level of indirection, except for the problem of too many levels of indirection".
So you could post process with a mv or preprocess the .dsc file, and restore it from a build script wrapper.
Hacking the build system is not a solution to my problem.
I guess I'm not as opposed to this idea as a lot of platforms in the real world have pre and post build steps that are driven by a script or makefile. So if you already have a script or a makefile that you have to build from adding another step to it does not seem as bad.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/build.s...
Instead of changing all the DSC files of EDK2, I would prefer to see a patch that changes the 'build' command to allow to overwrite the Build directory defined in the DSC file.
The build command already has a lot of options. I'm not sure adding an option is the right thing to do?
So if hacking the DSC file in no good, hacking the build system is no good and hacking the build command is no good, is there a sane way to get the EDKII build environment to support a configurable output directory?
The build systems design assumes that there may need to be pre and post build phases that will done via a script or makefile. For example the FD may need to get signed and the the signing process would be a post processing step.
Given what we have today I think the simplest thing to do is make Build directory a symbolic link to the location you really want the output to go to. This works assuming your build script has permissions to write to this directory.
The more I think about it we need to change something on the edk2 side I think the best thing would be to add the argument to build like Olivier suggested.
Thanks,
Andrew Fish
-----Original Message----- From: Andrew Fish [mailto:afish@apple.com] Sent: 21 June 2013 19:01 To: ryan.harkin@linaro.org Cc: Olivier Martin; boot-architecture@lists.linaro.org; edk2- devel@lists.sourceforge.net; patches@linaro.org Subject: Re: [edk2] [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter
On Jun 21, 2013, at 10:36 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 21 June 2013 17:12, Andrew Fish afish@apple.com wrote:
On Jun 21, 2013, at 4:23 AM, Ryan Harkin ryan.harkin@linaro.org
wrote:
On 21 June 2013 11:15, Olivier Martin olivier.martin@arm.com
wrote:
I am not convinced by this patch. The use case you gave is the automated build system. Nothing
prevent you to
do a move the folder around after building it.
That's not quite suitable for our CI builds, but I see your point.
If you build from a script you should be able to do anything you
want? "You can solve every problem with another level of indirection, except for the problem of too many levels of indirection".
So you could post process with a mv or preprocess the .dsc file, and
restore it from a build script wrapper.
Hacking the build system is not a solution to my problem.
I guess I'm not as opposed to this idea as a lot of platforms in the real world have pre and post build steps that are driven by a script or makefile. So if you already have a script or a makefile that you have to build from adding another step to it does not seem as bad.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/bu ild.sh
Instead of changing all the DSC files of EDK2, I would prefer to
see a patch
that changes the 'build' command to allow to overwrite the Build
directory
defined in the DSC file.
The build command already has a lot of options. I'm not sure adding
an option is the right thing to do?
So if hacking the DSC file in no good, hacking the build system is no good and hacking the build command is no good, is there a sane way to get the EDKII build environment to support a configurable output directory?
The build systems design assumes that there may need to be pre and post build phases that will done via a script or makefile. For example the FD may need to get signed and the the signing process would be a post processing step.
Given what we have today I think the simplest thing to do is make Build directory a symbolic link to the location you really want the output to go to. This works assuming your build script has permissions to write to this directory.
The more I think about it we need to change something on the edk2 side I think the best thing would be to add the argument to build like Olivier suggested.
Thanks,
Andrew Fish
Another solution would be to introduce an environment variable (eg: EDK_BUILD_PATH) set by edksetup.(sh|bat) with a default value equal to $(WORKSPACE) that can be overwritten.
But I am not sure to fully understand the motivation behind changing the default build directory. If you cannot add pre/post action to your build system then it should not take a long time to receive a new request to change the UEFI firmware filename ;-)
boot-architecture@lists.linaro.org
-
Andrew Fish -
Olivier Martin -
Ryan Harkin