From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=GK8Fuhiq; spf=pass (domain: apple.com, ip: 17.151.62.66, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) by groups.io with SMTP; Wed, 08 May 2019 06:59:54 -0700 Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x48DkeQn050819; Wed, 8 May 2019 06:59:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2Tu4LKpxzRana54lfNvY7K9sQ50PmjD7YwoIyMmeMnQ=; b=GK8FuhiqvPzDSiDMGDA3jvpIXlUHaajI/HL8e0qrEPfR+r18uZk3RSeXXS3qVQTsz6qe KbJX6Ni2w03hYZyqe+Jg5QLbRqMCXhVxrg1omOD/EY7Dr/0goxqO1mhaHxhfzqsm5g6R gdCom/Da602UZlPkIY2QF4kykSOQlYod5u0SrQe2NSudKf9E5WdbpvaXkPTr/i7AlUt1 6/XLLc4bRow27c06sfp//+1m9VuTdrcRVp+xfQll6SrknXSRGHJ04SMGWEuALxsgrsEp 3TI+iitLUP+6yXScE761vTnneIZrcYnDb6kKzX/0PUPkOQ7PTuhLNFjsK2uPuPatcupn SA== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2s99p0fd8y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 08 May 2019 06:59:53 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PR600KHCUVT6T20@mr2-mtap-s03.rno.apple.com>; Wed, 08 May 2019 06:59:53 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PR600G00UGOEI00@nwk-mmpp-sz10.apple.com>; Wed, 08 May 2019 06:59:53 -0700 (PDT) X-Va-A: X-Va-T-CD: 17e290161afadc43df911743530be568 X-Va-E-CD: cc9402d0a6211c664e189619ee1fe487 X-Va-R-CD: 0dad72254792c385e1dc205ddae095c4 X-Va-CD: 0 X-Va-ID: e1cec17f-2a4a-4189-9feb-8a2dca5f87d5 X-V-A: X-V-T-CD: 17e290161afadc43df911743530be568 X-V-E-CD: cc9402d0a6211c664e189619ee1fe487 X-V-R-CD: 0dad72254792c385e1dc205ddae095c4 X-V-CD: 0 X-V-ID: d911eef9-2ad4-4606-b3f7-0af7591822e6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-05-08_08:,, signatures=0 Received: from [17.235.21.233] (unknown [17.235.21.233]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PR600APHUVRXV10@nwk-mmpp-sz10.apple.com>; Wed, 08 May 2019 06:59:53 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <6EF320BA-7D16-4370-9F37-1618CDE01CBD@apple.com> Subject: Re: [edk2-devel] [PATCH V2] BaseTools:improve code to support C files with .C suffixes Date: Wed, 08 May 2019 06:59:40 -0700 In-reply-to: <20190508120823.urob54m7tojotq7n@bivouac.eciton.net> Cc: "Fan, ZhijuX" , "Gao, Liming" , "Feng, Bob C" , Laszlo Ersek , Mike Kinney To: devel@edk2.groups.io, Leif Lindholm References: <5C1A24BA-648D-4A3F-AE88-034073AB5C13@apple.com> <20190507144002.gq3rdtappd3rupmd@bivouac.eciton.net> <55FC6AA1-43B5-4557-8A17-0E3B00E3EE9A@apple.com> <20190508090926.4r4e6jqlg45yg6yp@bivouac.eciton.net> <20190508120823.urob54m7tojotq7n@bivouac.eciton.net> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-05-08_08:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_sbG2zbDrCcomnw0yd53phg)" --Boundary_(ID_sbG2zbDrCcomnw0yd53phg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On May 8, 2019, at 5:08 AM, Leif Lindholm wrote: > > Hi Fan Zhiju, > > I understand your reasoning, but that strengthens my view that we > should leave this change out. > > Actually, could we consider *dropping* support for .C files > altogether, since we are striving to support multiple toolchains, and > the two major families of toolchains we use consider .C files to be > fundamentally different things? > > Andrew, Laszlo, Mike? > Leif, I missed that ARM had extra restrictions on file extensions. [C-Code-File] ?.c ?.C ?.cc ?.CC ?.cpp ?.Cpp ?.CPP [C-Code-File.BASE.AARCH64,C-Code-File.SEC.AARCH64,C-Code-File.PEI_CORE.AARCH64,C-Code-File.PEIM.AARCH64,C-Code-File.BASE.ARM,C-Code-File.SEC.ARM,C-Code-File.PEI_CORE.ARM,C-Code-File.PEIM.ARM] ?.c I think there are people who try to roll there own C++ support and that is why the build system will pass the C++ files to the C compiler. At this point I think we should probably act more like a compiler. First add a warning, and down the road remove the support? Thanks, Andrew Fish > Best Regards, > > Leif > > On Wed, May 08, 2019 at 10:57:09AM +0000, Fan, ZhijuX wrote: >> Hi Leif, >> >> This patch is going to fix the bug in commit 05217d210e. >> this patch and commit 05217d210e is just for MSVC. It doesn't have any effect on GCC. >> this patch does not imply to compile .C as C instead of C++. >> We just found out that they build break because the.C file was in the source file, >> But the MSVC compiler allows.C files,So I fixed this bug to Change the original logic to support.C files. >> >> >> Any question, please let me know. Thanks. >> >> Best Regards >> Fan Zhiju >> >> >> >> >>> -----Original Message----- >>> From: Leif Lindholm [mailto:leif.lindholm@linaro.org] >>> Sent: Wednesday, May 8, 2019 5:09 PM >>> To: Andrew Fish >>> Cc: devel@edk2.groups.io; Fan, ZhijuX ; Gao, Liming >>> ; Feng, Bob C >>> Subject: Re: [edk2-devel] [PATCH V2] BaseTools:improve code to support C >>> files with .C suffixes >>> >>> On Tue, May 07, 2019 at 07:01:26PM -0700, Andrew Fish wrote: >>>> >>>> >>>>> On May 7, 2019, at 7:40 AM, Leif Lindholm >>> wrote: >>>>> >>>>> Hi Fan Zhiju, >>>>> >>>>> But where does the string come from that contains a .C suffix? >>>>> Is the tool internally converting things to uppercase, or is some >>>>> source file in the build incorrectly named? >>>>> >>>> >>>> Leif, >>>> >>>> Our build system defines .C as correct! I think it has been that way a very >>> long time. >>> >>> .C is valid, but at least for GCC it is equivalent to all of the other non-.c >>> options - i.e., interpret as c++. Which is why I am wondering about the case >>> that ends up with the build system internally processing this. >>> >>> If it is changed to permitting .C files to be compiled as C instead of >>> C++ (which the patch seems to imply), that sounds incorrect to me. >>> >>> / >>> Leif >>> >>>> >>> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rul >>>> e.template#L109 >>>> >>>> [C-Code-File] >>>> >>>> ?.c >>>> ?.C >>>> ?.cc >>>> ?.CC >>>> ?.cpp >>>> ?.Cpp >>>> ?.CPP >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>> >>>>> I am asking because it is not clear to me whether the patch resolves >>>>> a problem or hides one. >>>>> >>>>> Best Regards, >>>>> >>>>> Leif >>>>> >>>>> On Tue, May 07, 2019 at 03:05:02AM +0000, Fan, ZhijuX wrote: >>>>>> This problem has nothing to do with the file system, We just use >>>>>> the filename as a string to compare with other strings Our unittest >>>>>> tested minplatform, Ovmf. This problem was found when building a >>>>>> platform inside Intel. >>>>>> We've tested it on Linux and Windows. >>>>>> >>>>>> Any question, please let me know. Thanks. >>>>>> >>>>>> Best Regards >>>>>> Fan Zhiju >>>>>> >>>>>> -----Original Message----- >>>>>> From: afish@apple.com [mailto:afish@apple.com] >>>>>> Sent: Tuesday, May 7, 2019 10:31 AM >>>>>> To: devel@edk2.groups.io; Fan, ZhijuX >>>>>> Cc: Gao, Liming ; Feng, Bob C >>>>>> >>>>>> Subject: Re: [edk2-devel] [PATCH V2] BaseTools:improve code to >>>>>> support C files with .C suffixes >>>>>> >>>>>> This brings up a question? Do we tests on a file system that is case >>> sensitive? Is this just lack of a test case? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Andrew Fish >>>>>> >>>>>>> On May 6, 2019, at 7:22 PM, Fan, ZhijuX wrote: >>>>>>> >>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1773 >>>>>>> >>>>>>> Build break if C file suffixes of named .C instead of .c Code not >>>>>>> recognize filenames with .C suffixes. >>>>>>> >>>>>>> This patch adds code to Support both .c file and .C file >>>>>>> >>>>>>> Cc: Bob Feng >>>>>>> Cc: Liming Gao >>>>>>> Signed-off-by: Zhiju.Fan >>>>>>> --- >>>>>>> BaseTools/Source/Python/AutoGen/GenMake.py | 3 ++- >>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py >>>>>>> b/BaseTools/Source/Python/AutoGen/GenMake.py >>>>>>> index 0e0f9fd9b0..858ddedf8e 100644 >>>>>>> --- a/BaseTools/Source/Python/AutoGen/GenMake.py >>>>>>> +++ b/BaseTools/Source/Python/AutoGen/GenMake.py >>>>>>> @@ -1035,7 +1035,8 @@ cleanlib: >>>>>>> CmdTargetDict[CmdSign] = "%s %s" % >>> (CmdTargetDict[CmdSign], SingleCommandList[-1]) >>>>>>> Index = CommandList.index(Item) >>>>>>> CommandList.pop(Index) >>>>>>> - if SingleCommandList[-1].endswith("%s%s.c" % (TAB_SLASH, >>> CmdSumDict[CmdSign.lstrip('/Fo').rsplit(TAB_SLASH, 1)[0]])): >>>>>>> + if SingleCommandList[-1].endswith("%s%s.c" % >>> (TAB_SLASH, CmdSumDict[T.Target.SubDir])) or \ >>>>>>> + SingleCommandList[-1].endswith("%s%s.C" % >>> (TAB_SLASH, CmdSumDict[T.Target.SubDir])): >>>>>>> Cpplist = CmdCppDict[T.Target.SubDir] >>>>>>> Cpplist.insert(0, '$(OBJLIST_%d): $(COMMON_DEPS)' % >>> list(self.ObjTargetDict.keys()).index(T.Target.SubDir)) >>>>>>> T.Commands[Index] = '%s\n\t%s' % (' >>>>>>> \\\n\t'.join(Cpplist), CmdTargetDict[CmdSign]) >>>>>>> -- >>>>>>> 2.14.1.windows.1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> > > --Boundary_(ID_sbG2zbDrCcomnw0yd53phg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On May 8,= 2019, at 5:08 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:

Hi Fan Zhiju,

I understand your reasoning, but that strengthens my view that we
should leave this change = out.

Actually, could we consider *dropping* support for .C = files
altogether, since= we are striving to support multiple toolchains, and
the two major families of toolchains we use c= onsider .C files to be
= fundamentally different things?

Andrew, Laszlo, Mike?


Leif,
I missed that ARM had extra restrictions on file ex= tensions. 

[C-Code-File]
    <InputFile>
       = ?.c
        ?.C
    &nbs= p;   ?.cc
        ?.CC
  =       ?.cpp
        ?.Cpp
        ?.CPP

[C-Code-File.BASE.AARCH64,C-Code-File.SEC.AARCH64,C-Code-File.PEI_CORE.AAR= CH64,C-Code-File.PEIM.AARCH64,C-Code-File.BASE.ARM,C-Code-File.SEC.ARM,C-Co= de-File.PEI_CORE.ARM,C-Code-File.PEIM.ARM]
    <Inpu= tFile>
        ?.c

I think there are peopl= e who try to roll there own C++ support  and that is why the build sys= tem will pass the C++ files to the C compiler. 

At this point I think we should probably act more like a comp= iler. First add a warning, and down the road remove the support?
=
Thanks,

Andre= w Fish

Best Regards,
Leif

On Wed, Ma= y 08, 2019 at 10:57:09AM +0000, Fan, ZhijuX wrote:
Hi Leif,

This patch is going to fix the bug in commit 05217d210e.
this patch and commit 05217d210e is just for MSVC. It doesn't have any e= ffect on GCC.
this patch does not imply to compile .C as C in= stead of C++.
We just found out that they build break because= the.C file was in the source file,
But the MSVC compiler all= ows.C files,So I fixed this bug to Change the original logic to support.C f= iles.


Any question, please let = me know. Thanks.

Best Regards
Fa= n Zhiju




-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Wednesd= ay, May 8, 2019 5:09 PM
To: Andrew Fish <afish@apple.com>
Cc: devel@edk2.groups.io; Fa= n, ZhijuX <zhijux.fan= @intel.com>; Gao, Liming
<liming.gao@intel.com>; Feng, Bob C <bob.c.feng@intel.com>= ;
Subject: Re: [edk2-devel] [PATCH V2] BaseTools:improve code= to support C
files with .C suffixes

On Tue, May 07, 2019 at 07:01:26PM -0700, Andrew Fish wrote:


<= blockquote type=3D"cite" class=3D"">On May 7, 2019, at 7:40 AM, Leif Lindho= lm <leif.lindholm= @linaro.org>
wrote:

Hi Fan Zhiju,

But where = does the string come from that contains a .C suffix?
Is the t= ool internally converting things to uppercase, or is some
sou= rce file in the build incorrectly named?


Leif,

Our build system = defines .C as correct! I think it has been that way a very
long time.

.C is valid, but at leas= t for GCC it is equivalent to all of the other non-.c
options= - i.e., interpret as c++. Which is why I am wondering about the case
that ends up with the build system internally processing this.

If it is changed to permitting .C files to be com= piled as C instead of
C++ (which the patch seems to imply), t= hat sounds incorrect to me.

/
&n= bsp;  Leif


https://github.c= om/tianocore/edk2/blob/master/BaseTools/Conf/build_rul
e.template#L109

[C-Code-File]
   <InputFile>
       ?.c
 = ;      ?.C
   &n= bsp;   ?.cc
     &nbs= p; ?.CC
       ?.cpp<= br class=3D"">       ?.Cpp
       ?.CPP

Thanks,

Andrew Fish


I am asking beca= use it is not clear to me whether the patch resolves
a proble= m or hides one.

Best Regards,
Leif

On Tue, May 07, 2019 at 03:0= 5:02AM +0000, Fan, ZhijuX wrote:
This problem has nothing to do with the file system, We just usethe filename as a string to compare with other strings Our uni= ttest
tested minplatform, Ovmf. This problem was found when b= uilding a
platform inside Intel.
We've tested i= t on Linux and Windows.

Any question, please l= et me know. Thanks.

Best Regards
Fan Zhiju

-----Original Message-----
From: afish@apple.com [mailto:afish@apple.com]
Sent: T= uesday, May 7, 2019 10:31 AM
To: devel@edk2.groups.io; Fan, Z= hijuX <zhijux.fan@intel.com>
Cc: Gao, Liming <liming= .gao@intel.com>; Feng, Bob C
<bob.c.feng@intel.com><= br class=3D"">Subject: Re: [edk2-devel] [PATCH V2] BaseTools:improve code t= o
support C files with .C suffixes

This brings up a question? Do we tests on a file system that is case
sensitive? Is this just l= ack of a test case?

Thanks,

Andrew Fish
On May 6, 2019, at 7:22 P= M, Fan, ZhijuX <zhijux.fan@intel.com> wrote:

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1773

Build break if C file suffixes of named .C instead of= .c Code not
recognize filenames with .C suffixes.

This patch adds code to Support both .c file and .C f= ile

Cc: Bob Feng <bob.c.feng@intel.com><= br class=3D"">Cc: Liming Gao <liming.gao@intel.com>
Sig= ned-off-by: Zhiju.Fan <zhijux.fan@intel.com>
---
BaseTools/Source/Python/AutoGen/GenMake.py | 3 ++-
1 = file changed, 2 insertions(+), 1 deletion(-)

d= iff --git a/BaseTools/Source/Python/AutoGen/GenMake.py
b/Base= Tools/Source/Python/AutoGen/GenMake.py
index 0e0f9fd9b0..858d= dedf8e 100644
--- a/BaseTools/Source/Python/AutoGen/GenMake.p= y
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -1035,7 +1035,8 @@ cleanlib:
   &nbs= p;            &= nbsp;     CmdTargetDict[CmdSign] =3D "%s %s" %
(CmdTargetDi= ct[CmdSign], SingleCommandList[-1])
    &nb= sp;            =  Index =3D CommandList.index(Item)
   &nb= sp;            =   CommandList.pop(Index)
-     =             &nb= sp;  if SingleCommandList[-1].endswith("%s%s.c" % (TAB_SLASH,
CmdSumDict[C= mdSign.lstrip('/Fo').rsplit(TAB_SLASH, 1)[0]])):
+   =             &nb= sp;    if SingleCommandList[-1].endswith("%s%s.c" %
(TAB_SLASH, = CmdSumDict[T.Target.SubDir])) or \
+     &n= bsp;            = ;          SingleCommandL= ist[-1].endswith("%s%s.C" %
(TAB_SLASH, CmdSumDict[T.Target.SubDir])):
=
&= nbsp;           &nbs= p;         Cpplist =3D CmdCppD= ict[T.Target.SubDir]
      &nbs= p;            &= nbsp;  Cpplist.insert(0, '$(OBJLIST_%d): $(COMMON_DEPS)' %
list(self.ObjTa= rgetDict.keys()).index(T.Target.SubDir))
   &nbs= p;            &= nbsp;     T.Commands[Index] =3D '%s\n\t%s' % ('\\\n\t'.join(Cpplist), CmdTargetDict[CmdSign])
--=
2.14.1.windows.1




<winmail.dat>









--Boundary_(ID_sbG2zbDrCcomnw0yd53phg)--