From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.groups.io with SMTP id smtpd.web10.5045.1570628614505221969 for ; Wed, 09 Oct 2019 06:43:34 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0BFCA550CF; Wed, 9 Oct 2019 13:43:34 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-11.rdu2.redhat.com [10.10.120.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2C6D560C05; Wed, 9 Oct 2019 13:43:32 +0000 (UTC) Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain To: Andrew Fish , devel@edk2.groups.io Cc: "Gao, Liming" References: <1569570395-11240-1-git-send-email-liming.gao@intel.com> <1569570395-11240-12-git-send-email-liming.gao@intel.com> <4c27bdc4-60b4-26bf-c416-c02b69ef8051@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E5124FA@SHSMSX104.ccr.corp.intel.com> <7fc791fe-9d08-9763-ecc9-529e88b621c6@redhat.com> <767711D5-7C33-4703-8E97-F4F5B5A6BD5F@apple.com> From: "Laszlo Ersek" Message-ID: <6f49899d-b5e4-70ad-82e5-08c5a8649ac8@redhat.com> Date: Wed, 9 Oct 2019 15:43:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <767711D5-7C33-4703-8E97-F4F5B5A6BD5F@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 09 Oct 2019 13:43:34 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/09/19 01:08, Andrew Fish wrote: > So I guess the way to describe it is XCODE inherits GCC and only needs to override when it is different. Thank you for the explanation! I've been trying to figure out why this inheritance bothers me so much. I guess the reason is the following: I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, GCC5). Assume that I realize that a gcc-specific change is needed to some part of the code. (It could be build options, or gcc specific source code, etc.) Then, I go to the gcc documentation, and verify whether the change is indeed supported by all the relevant gcc versions. If the change is possible with only some gcc versions, then I likely write the change for a specific toolchain only, such as GCC5. Fine. Now assume that my documentation review proves that *all* GCCxx toolchains, supported by edk2, should receive the update. This could be a #pragma, a command line flag, some __attribute__, etc. I'd very likely express the change for the whole GCC toolchain *family*, and not enumerate it for GCC48, GCC49, GCC5 individually. And now I learn that said approach would be wrong, because such a change would be inherited by XCODExx and CLANGxx too (via FAMILY), fully against my intent, unless XCODExx and CLANGxx overrode the particular aspect (via BUILDRULEFAMILY). This means that, after checking the gcc documentation meticulously (multiple releases), and possibly even testing multiple gcc installations, I could still regress edk2 (CLANGxx and/or XCODExx specific parts), because they could inherit my GCC-oriented changes that I never meant for CLANGxx and/or XCODExx. I don't use XCODE or CLANG, I don't test on them, and now it seems I can restrict changes to the *actual* gcc compilers only if I keep spelling out the individual toolchain names, such as GCC48, GCC49, GCC5. This makes the toolchain family concept totally useless to me (and to other users that only care about actual gcc compilers). There is no *family* facility available that allows people to restrict settings to actual gcc compilers. In other words, we can't express "all GCCxx toolchains, regardless of toolchain version, but not XCODE, and also not CLANG". Thanks Laszlo