Re: [edk2] [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter
On 06/21/2013 02:21 PM, Olivier Martin wrote:
-----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.
I suspect this would work for everyones use cases.
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 ;-)
Allowing for user-specified output directories helps a lot of different use cases. My favourite is when debugging builds and bisecting a problem to throw each build into foo.rev so that I can if needed compare objects, etc, etc, without having to think about moving stuff around.
On Jun 21, 2013, at 2:02 PM, Tom Rini trini@ti.com wrote:
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.
I suspect this would work for everyones use cases.
This might actually be a bigger change to the tools as it impacts all the generated makefiles. But then again with all the complexity of the build.py it may be easier to hack up the makefile templates?
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 ;-)
Allowing for user-specified output directories helps a lot of different use cases. My favourite is when debugging builds and bisecting a problem to throw each build into foo.rev so that I can if needed compare objects, etc, etc, without having to think about moving stuff around.
OK now I'm sold on this concept. I could see adding a check in the platform build script and override build results directory if I'm on a git branch other than master.
Thanks,
Andrew Fish
boot-architecture@lists.linaro.org
-
Andrew Fish -
Tom Rini