Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS
Kinney, Michael D [mailto:[email protected]] wrote: ]Sent: Wednesday, July 15, 2015 11:49 AM ]To: Scott Duplichan; [email protected]; Kinney, Michael D ]Subject: RE: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS ] ] ]Scott, ] ]I agree that updating tools_def.txt for this use case is difficult, and I would not recommend that either. ] ]There are other methods to customize compiler/linker. The compiler/link flags are built up from several ]sources. ]1) tools_def.txt ]2) build_rules.txt ]3) [BuildOptions] section of a DSC file. ]4) [BuildOptions] section of an INF file. ] ]For example, you can implement the same type of feature using a combination of the -D arguments to the ]build command and a [BuildOptions] section in a DSC file. ] ]DSC file ] ][BuildOptions] ] MSFT:*_*_*_CC_FLAGS = $(MSFT_EXTRA_CC_FLAGS) ] GCC:*_*_*_CC_FLAGS = $(GCC_EXTRA_CC_FLAGS) ] ]MSFT Build command example (disable all warnings) ] ]build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -D MSFT_EXTRA_CC_FLAGS=/w ] ]MSFT Build command example (disable all warnings and disable optimizations) ] ]build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -D MSFT_EXTRA_CC_FLAGS="/Od /w" ] ]GCC Build command example (msabi flag) ] ]build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -D GCC_EXTRA_CC_FLAGS="-mabi=ms" Hello Mike, This is good to know. I see that the build system will also pick up the value for $(GCC_EXTRA_CC_FLAGS) directly from the environment variable GCC_EXTRA_CC_FLAGS if it is not passed on the build command line using '-D'. While useful, I am not sure this method is ideal for a global setting. It requires appending a section to 59 DSC files. That might be easy using bash/sed, but not so easy using windows. Also, it is modifying files under source control, so a batch file command to revert the change once the build test completes would be useful. Thanks, Scott ]Best regards, ] Mike -Original Message- From: Scott Duplichan [mailto:[email protected]] Sent: Wednesday, July 15, 2015 12:03 AM To: Kinney, Michael D; [email protected] Subject: RE: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS Kinney, Michael D [mailto:[email protected]] wrote: ]Sent: Tuesday, July 14, 2015 06:29 PM ]To: Scott Duplichan; [email protected]; Kinney, Michael D ]Subject: RE: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS ] ]Scott, ] ]We try to minimize the build dependencies on environment variables. There are several mechanisms already ]available to append CC_FLAGS. Can you please provide more details on why the environment variable based ]method is better than the existing methods? ] ]Thanks, ] ]Mike Hello Mike, First of all, this patch is not an essential, must-have. I just find it useful. For example, what if you want to test the code size reduction effect of gcc option -mabi=ms ? With this patch applied, a single command does it. Without the patch, you have to carefully edit the 7,000 line tools_def.txt file. For example, it might seem that adding -mabi=ms to GCC_ALL_CC_FLAGS would be proper. But looking more closely at that definition shows that it does not affect GCC44-GCC49. If there is a need to append a new flag to the existing flags, then several changes are needed. Once the changes are made, how can they be saved for future use? I suppose a patch file would work, but the patch might not work for some future EDK2 revision. The environment variable method of modifying build flags seems to be universal for gnu projects. It is not something I invented. Imagine trying to customize gcc build flags without using environment variables. I am surprised to hear objections to the use of environment variables. Here is why. I like to download a pristine source code project into its own directory. Customizations, experimental settings, and environment specific settings are kept somewhere else. That way, I can clean, update, or replace the project's source code independently of my customizations. Environment variables seem like a perfect way to implement this. An example is environment variable GCC49_X64_PREFIX. My build wrapper batch file sets this variable to match my machine. I can download a new EDK2 and build successfully without modifying anything. But what about the hard-coded paths for Microsoft tools? If my Microsoft tools are on a D drive, then what do I do? I suppose I could write some sed commands to modify tools_def every time I build. But that is a pain. Windows has no sed for one thing. With the environment variable setup of GCC44-49, I can build a new EDK2 download without modifying a single file. So how did I solve the Microsoft hard-coded path problem? I ended up retiring my old computer and building up a new
Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS
Scott, I agree that updating tools_def.txt for this use case is difficult, and I would not recommend that either. There are other methods to customize compiler/linker. The compiler/link flags are built up from several sources. 1) tools_def.txt 2) build_rules.txt 3) [BuildOptions] section of a DSC file. 4) [BuildOptions] section of an INF file. For example, you can implement the same type of feature using a combination of the -D arguments to the build command and a [BuildOptions] section in a DSC file. DSC file [BuildOptions] MSFT:*_*_*_CC_FLAGS = $(MSFT_EXTRA_CC_FLAGS) GCC:*_*_*_CC_FLAGS = $(GCC_EXTRA_CC_FLAGS) MSFT Build command example (disable all warnings) build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -D MSFT_EXTRA_CC_FLAGS=/w MSFT Build command example (disable all warnings and disable optimizations) build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -D MSFT_EXTRA_CC_FLAGS="/Od /w" GCC Build command example (msabi flag) build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -D GCC_EXTRA_CC_FLAGS="-mabi=ms" Best regards, Mike -Original Message- From: Scott Duplichan [mailto:[email protected]] Sent: Wednesday, July 15, 2015 12:03 AM To: Kinney, Michael D; [email protected] Subject: RE: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS Kinney, Michael D [mailto:[email protected]] wrote: ]Sent: Tuesday, July 14, 2015 06:29 PM ]To: Scott Duplichan; [email protected]; Kinney, Michael D ]Subject: RE: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS ] ]Scott, ] ]We try to minimize the build dependencies on environment variables. There are several mechanisms already ]available to append CC_FLAGS. Can you please provide more details on why the environment variable based ]method is better than the existing methods? ] ]Thanks, ] ]Mike Hello Mike, First of all, this patch is not an essential, must-have. I just find it useful. For example, what if you want to test the code size reduction effect of gcc option -mabi=ms ? With this patch applied, a single command does it. Without the patch, you have to carefully edit the 7,000 line tools_def.txt file. For example, it might seem that adding -mabi=ms to GCC_ALL_CC_FLAGS would be proper. But looking more closely at that definition shows that it does not affect GCC44-GCC49. If there is a need to append a new flag to the existing flags, then several changes are needed. Once the changes are made, how can they be saved for future use? I suppose a patch file would work, but the patch might not work for some future EDK2 revision. The environment variable method of modifying build flags seems to be universal for gnu projects. It is not something I invented. Imagine trying to customize gcc build flags without using environment variables. I am surprised to hear objections to the use of environment variables. Here is why. I like to download a pristine source code project into its own directory. Customizations, experimental settings, and environment specific settings are kept somewhere else. That way, I can clean, update, or replace the project's source code independently of my customizations. Environment variables seem like a perfect way to implement this. An example is environment variable GCC49_X64_PREFIX. My build wrapper batch file sets this variable to match my machine. I can download a new EDK2 and build successfully without modifying anything. But what about the hard-coded paths for Microsoft tools? If my Microsoft tools are on a D drive, then what do I do? I suppose I could write some sed commands to modify tools_def every time I build. But that is a pain. Windows has no sed for one thing. With the environment variable setup of GCC44-49, I can build a new EDK2 download without modifying a single file. So how did I solve the Microsoft hard-coded path problem? I ended up retiring my old computer and building up a new one with a bigger C-drive hard disk. Thanks, Scott -Original Message- From: Scott Duplichan [mailto:[email protected]] Sent: Tuesday, July 14, 2015 9:47 AM To: [email protected] Subject: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS BaseTools: Add mechanism to override or add CC_FLAGS If environment variable MSFT_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for MSFT and INTEL tool chains. If environment variable GCC_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for GCC and RVCT tool chains. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan --- This patch must be applied after the gcc49lto. Setting environment variable GCC_EXTRA_CC_FLAGS=-Wno-error overrides the gcc warnings as error option so that gcc lto builds can finis
Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS
From: Andrew Fish [mailto:[email protected]] Sent: Tuesday, July 14, 2015 05:24 PM To: Scott Duplichan Cc: [email protected] Subject: Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS On Jul 14, 2015, at 9:46 AM, Scott Duplichan mailto:[email protected]> > wrote: BaseTools: Add mechanism to override or add CC_FLAGS If environment variable MSFT_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for MSFT and INTEL tool chains. If environment variable GCC_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for GCC and RVCT tool chains. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan mailto:[email protected]> > --- This patch must be applied after the gcc49lto. Setting environment variable GCC_EXTRA_CC_FLAGS=-Wno-error overrides the gcc warnings as error option so that gcc lto builds can finish and generate a complete list of warnings. A similar option is added for Microsoft tool chains. Set environment variable MSFT_EXTRA_CC_FLAGS=/WX- to override warning as error for Microsoft tool chains. These settings are also useful for overnight batch building of many EDK2 projects. By overriding warning as error, the build will continue after a warning is encountered, allowing more files to be processed. BaseTools/Conf/build_rule.template | 4 ++-- BaseTools/Conf/tools_def.template | 30 ++ 2 files changed, 20 insertions(+), 14 deletions(-) diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template index 86ea464..e9802ea 100644 --- a/BaseTools/Conf/build_rule.template +++ b/BaseTools/Conf/build_rule.template @@ -128,11 +128,11 @@ $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj -"$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src} +"$(CC)" /Fo${dst} $(CC_FLAGS) $(MSFT_EXTRA_CC_FLAGS) $(INC) ${src} # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues -"$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src} +"$(CC)" $(CC_FLAGS) $(GCC_EXTRA_CC_FLAGS) -o ${dst} $(INC) ${src} Why do you need to update the rules files? You could just do this in the tools_def file. Hello Andrew, I use a batch file to run overnight test builds using all Microsoft and GCC tool chains. I try to run it weekly to find new build failures. I also run it to check my own patches. I would like for this batch file to temporarily disable warning as error during its builds. With t environment method of this patch, two batch file lines do the job. To do it with tools_def.txt might not be easy. For Windows, I would have to use a sed port, or learn to use powershell. Then I suppose I could do a global search and replace of /WX for the Windows case. For gcc, I could do a global search and replace of -Werror. So it certainly can be done that way, but it is more complicated. Thanks, Scott PLATFORM_FLAGS is an example of how to do this? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Conf/tools_def.template *_GCC46_ARM_PLATFORM_FLAGS = -march=armv7-a DEFINE GCC46_ARM_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -O0 RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -Wno-unused-but-set-variable Thanks, Andrew Fish "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src} diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 8d1b319..fa98b66 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4692,9 +4692,9 @@ RELEASE_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s DEBUG_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS) -c RELEASE_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS) -c NOOPT_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS) -c - DEBUG_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS) -RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS) - NOOPT_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS) + DEBUG_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS) ENV(GCC_EXTRA_CC_FLAGS) +RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS) ENV(GCC_EXTRA_CC_FLAGS) + NOOPT_GCC4
Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS
Kinney, Michael D [mailto:[email protected]] wrote: ]Sent: Tuesday, July 14, 2015 06:29 PM ]To: Scott Duplichan; [email protected]; Kinney, Michael D ]Subject: RE: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS ] ]Scott, ] ]We try to minimize the build dependencies on environment variables. There are several mechanisms already ]available to append CC_FLAGS. Can you please provide more details on why the environment variable based ]method is better than the existing methods? ] ]Thanks, ] ]Mike Hello Mike, First of all, this patch is not an essential, must-have. I just find it useful. For example, what if you want to test the code size reduction effect of gcc option -mabi=ms ? With this patch applied, a single command does it. Without the patch, you have to carefully edit the 7,000 line tools_def.txt file. For example, it might seem that adding -mabi=ms to GCC_ALL_CC_FLAGS would be proper. But looking more closely at that definition shows that it does not affect GCC44-GCC49. If there is a need to append a new flag to the existing flags, then several changes are needed. Once the changes are made, how can they be saved for future use? I suppose a patch file would work, but the patch might not work for some future EDK2 revision. The environment variable method of modifying build flags seems to be universal for gnu projects. It is not something I invented. Imagine trying to customize gcc build flags without using environment variables. I am surprised to hear objections to the use of environment variables. Here is why. I like to download a pristine source code project into its own directory. Customizations, experimental settings, and environment specific settings are kept somewhere else. That way, I can clean, update, or replace the project's source code independently of my customizations. Environment variables seem like a perfect way to implement this. An example is environment variable GCC49_X64_PREFIX. My build wrapper batch file sets this variable to match my machine. I can download a new EDK2 and build successfully without modifying anything. But what about the hard-coded paths for Microsoft tools? If my Microsoft tools are on a D drive, then what do I do? I suppose I could write some sed commands to modify tools_def every time I build. But that is a pain. Windows has no sed for one thing. With the environment variable setup of GCC44-49, I can build a new EDK2 download without modifying a single file. So how did I solve the Microsoft hard-coded path problem? I ended up retiring my old computer and building up a new one with a bigger C-drive hard disk. Thanks, Scott -Original Message- From: Scott Duplichan [mailto:[email protected]] Sent: Tuesday, July 14, 2015 9:47 AM To: [email protected] Subject: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS BaseTools: Add mechanism to override or add CC_FLAGS If environment variable MSFT_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for MSFT and INTEL tool chains. If environment variable GCC_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for GCC and RVCT tool chains. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan --- This patch must be applied after the gcc49lto. Setting environment variable GCC_EXTRA_CC_FLAGS=-Wno-error overrides the gcc warnings as error option so that gcc lto builds can finish and generate a complete list of warnings. A similar option is added for Microsoft tool chains. Set environment variable MSFT_EXTRA_CC_FLAGS=/WX- to override warning as error for Microsoft tool chains. These settings are also useful for overnight batch building of many EDK2 projects. By overriding warning as error, the build will continue after a warning is encountered, allowing more files to be processed. BaseTools/Conf/build_rule.template | 4 ++-- BaseTools/Conf/tools_def.template | 30 ++ 2 files changed, 20 insertions(+), 14 deletions(-) diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template index 86ea464..e9802ea 100644 --- a/BaseTools/Conf/build_rule.template +++ b/BaseTools/Conf/build_rule.template @@ -128,11 +128,11 @@ $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj -"$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src} +"$(CC)" /Fo${dst} $(CC_FLAGS) $(MSFT_EXTRA_CC_FLAGS) $(INC) ${src} # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues -"$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src} +"$(CC)" $(CC_FLAGS) $(GCC_EXTRA_CC_FLAGS) -o ${dst} $(INC) ${src} "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src} diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 8d1b319..fa98b66 100644 --- a/BaseTools/Conf/tools_def.template +++
Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS
Scott, We try to minimize the build dependencies on environment variables. There are several mechanisms already available to append CC_FLAGS. Can you please provide more details on why the environment variable based method is better than the existing methods? Thanks, Mike -Original Message- From: Scott Duplichan [mailto:[email protected]] Sent: Tuesday, July 14, 2015 9:47 AM To: [email protected] Subject: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS BaseTools: Add mechanism to override or add CC_FLAGS If environment variable MSFT_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for MSFT and INTEL tool chains. If environment variable GCC_EXTRA_CC_FLAGS exists, its contents are appended to the C compiler flags string for GCC and RVCT tool chains. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan --- This patch must be applied after the gcc49lto. Setting environment variable GCC_EXTRA_CC_FLAGS=-Wno-error overrides the gcc warnings as error option so that gcc lto builds can finish and generate a complete list of warnings. A similar option is added for Microsoft tool chains. Set environment variable MSFT_EXTRA_CC_FLAGS=/WX- to override warning as error for Microsoft tool chains. These settings are also useful for overnight batch building of many EDK2 projects. By overriding warning as error, the build will continue after a warning is encountered, allowing more files to be processed. BaseTools/Conf/build_rule.template | 4 ++-- BaseTools/Conf/tools_def.template | 30 ++ 2 files changed, 20 insertions(+), 14 deletions(-) diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template index 86ea464..e9802ea 100644 --- a/BaseTools/Conf/build_rule.template +++ b/BaseTools/Conf/build_rule.template @@ -128,11 +128,11 @@ $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj -"$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src} +"$(CC)" /Fo${dst} $(CC_FLAGS) $(MSFT_EXTRA_CC_FLAGS) $(INC) ${src} # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues -"$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src} +"$(CC)" $(CC_FLAGS) $(GCC_EXTRA_CC_FLAGS) -o ${dst} $(INC) ${src} "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src} diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 8d1b319..fa98b66 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4692,9 +4692,9 @@ RELEASE_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s DEBUG_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS) -c RELEASE_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS) -c NOOPT_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS) -c - DEBUG_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS) -RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS) - NOOPT_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS) + DEBUG_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS) ENV(GCC_EXTRA_CC_FLAGS) +RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS) ENV(GCC_EXTRA_CC_FLAGS) + NOOPT_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS) ENV(GCC_EXTRA_CC_FLAGS) *_GCC49LTO_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS) *_GCC49LTO_IA32_OBJCOPY_FLAGS = *_GCC49LTO_IA32_NASM_FLAGS = -f elf32 @@ -4720,9 +4720,9 @@ RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49L DEBUG_GCC49LTO_X64_CC_FLAGS= DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_DEBUG_FLAGS) -c RELEASE_GCC49LTO_X64_CC_FLAGS= DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_RELEASE_FLAGS) -c NOOPT_GCC49LTO_X64_CC_FLAGS= DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_NOOPT_FLAGS) -c - DEBUG_GCC49LTO_X64_DLINK_FLAGS = DEF(GCC49LTO_X64_DLINK_FLAGS) DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_DEBUG_FLAGS) -RELEASE_GCC49LTO_X64_DLINK_FLAGS = DEF(GCC49LTO_X64_DLINK_FLAGS) DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_RELEASE_FLAGS) - NOOPT_GCC49LTO_X64_DLINK_FLAGS = DEF(GCC49LTO_X64_DLINK_FLAGS) DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_NOOPT_FLAGS) + DEBUG_GCC49LTO_X64_DLINK_FLAGS = DEF(GCC49LTO_X64_DLINK_FLAGS) DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X6
Re: [edk2] [PATCH] BaseTools: Add mechanism to override or add CC_FLAGS
> On Jul 14, 2015, at 9:46 AM, Scott Duplichan wrote:
>
> BaseTools: Add mechanism to override or add CC_FLAGS
>
> If environment variable MSFT_EXTRA_CC_FLAGS exists, its contents
> are appended to the C compiler flags string for MSFT and INTEL tool
> chains. If environment variable GCC_EXTRA_CC_FLAGS exists, its
> contents are appended to the C compiler flags string for GCC and
> RVCT tool chains.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Scott Duplichan
> ---
>
> This patch must be applied after the gcc49lto. Setting environment
> variable GCC_EXTRA_CC_FLAGS=-Wno-error overrides the gcc warnings as
> error option so that gcc lto builds can finish and generate a complete
> list of warnings. A similar option is added for Microsoft tool chains.
> Set environment variable MSFT_EXTRA_CC_FLAGS=/WX- to override warning
> as error for Microsoft tool chains. These settings are also useful for
> overnight batch building of many EDK2 projects. By overriding warning as
> error, the build will continue after a warning is encountered, allowing
> more files to be processed.
>
> BaseTools/Conf/build_rule.template | 4 ++--
> BaseTools/Conf/tools_def.template | 30 ++
> 2 files changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/BaseTools/Conf/build_rule.template
> b/BaseTools/Conf/build_rule.template
> index 86ea464..e9802ea 100644
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -128,11 +128,11 @@
> $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
>
>
> -"$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
> +"$(CC)" /Fo${dst} $(CC_FLAGS) $(MSFT_EXTRA_CC_FLAGS) $(INC) ${src}
>
>
> # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
> -"$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
> +"$(CC)" $(CC_FLAGS) $(GCC_EXTRA_CC_FLAGS) -o ${dst} $(INC) ${src}
>
Why do you need to update the rules files? You could just do this in the
tools_def file.
PLATFORM_FLAGS is an example of how to do this?
https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Conf/tools_def.template
*_GCC46_ARM_PLATFORM_FLAGS = -march=armv7-a
DEFINE GCC46_ARM_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS)
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector
DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -O0
RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
Thanks,
Andrew Fish
>
> "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 8d1b319..fa98b66 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4692,9 +4692,9 @@ RELEASE_GCC49_AARCH64_CC_FLAGS =
> DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s
> DEBUG_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS)
> DEF(GCC49LTO_IA32_DEBUG_FLAGS) -c
> RELEASE_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS)
> DEF(GCC49LTO_IA32_RELEASE_FLAGS) -c
> NOOPT_GCC49LTO_IA32_CC_FLAGS = DEF(GCC49LTO_IA32_BASE_CC_FLAGS)
> DEF(GCC49LTO_IA32_NOOPT_FLAGS) -c
> - DEBUG_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS)
> DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS)
> -RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS)
> DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS)
> - NOOPT_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS)
> DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS)
> + DEBUG_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS)
> DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_DEBUG_FLAGS)
> ENV(GCC_EXTRA_CC_FLAGS)
> +RELEASE_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS)
> DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_RELEASE_FLAGS)
> ENV(GCC_EXTRA_CC_FLAGS)
> + NOOPT_GCC49LTO_IA32_DLINK_FLAGS= DEF(GCC49LTO_IA32_DLINK_FLAGS)
> DEF(GCC49LTO_IA32_BASE_CC_FLAGS) DEF(GCC49LTO_IA32_NOOPT_FLAGS)
> ENV(GCC_EXTRA_CC_FLAGS)
> *_GCC49LTO_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
> *_GCC49LTO_IA32_OBJCOPY_FLAGS =
> *_GCC49LTO_IA32_NASM_FLAGS = -f elf32
> @@ -4720,9 +4720,9 @@ RELEASE_GCC49LTO_IA32_DLINK_FLAGS=
> DEF(GCC49LTO_IA32_DLINK_FLAGS) DEF(GCC49L
> DEBUG_GCC49LTO_X64_CC_FLAGS= DEF(GCC49LTO_X64_BASE_CC_FLAGS)
> DEF(GCC49LTO_X64_DEBUG_FLAGS) -c
> RELEASE_GCC49LTO_X64_CC_FLAGS= DEF(GCC49LTO_X64_BASE_CC_FLAGS)
> DEF(GCC49LTO_X64_RELEASE_FLAGS) -c
> NOOPT_GCC49LTO_X64_CC_FLAGS= DEF(GCC49LTO_X64_BASE_CC_FLAGS)
> DEF(GCC49LTO_X64_NOOPT_FLAGS) -c
> - DEBUG_GCC49LTO_X64_DLINK_FLAGS = DEF(GCC49LTO_X64_DLINK_FLAGS)
> DEF(GCC49LTO_X64_BASE_CC_FLAGS) DEF(GCC49LTO_X64_DEBUG_FLAGS)
> -RELEASE_GCC
