From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c0c::231; helo=mail-wr0-x231.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9D1A321E43B61 for ; Sat, 23 Sep 2017 09:55:25 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id k20so2744028wre.4 for ; Sat, 23 Sep 2017 09:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Xq589rfqqiWzymLisghYR9juGxp8hSkkNxnn4k6Mpho=; b=PhnBWLE0r+fugSv35Td5tf9Ah6LZRAPktgs9LYf9fGkqLCrisZK3UD6hwi1ZDEIFH1 0UbKyVkMJFs+83wTYaEGAgaYAJ5kZgm1HBKXv+rp0o+6GevjnV1G6IIFZ/Uo99QXMxaP IRcQUoA3PuWUK+63jiQys2NUT09hLOybKkh3k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Xq589rfqqiWzymLisghYR9juGxp8hSkkNxnn4k6Mpho=; b=HaKCVVG9UwBw6j3a6xo2mA/UpbNPo+uCteGRFX0JATBL18uz5WLpGE6WoVM5vsrC9k 8Qd3C6LV2AaQV2SZJIpagkYT3ufHDvIuPM9UBXomrDDaDHDnRDuq/p6/x+IrOg8NDWv8 xoWOXV8ystrHoLFe9lTBFlxUmYGkyHYRQqQjrcyg46TkapXbpCrs9WK3A6V+yuE/DBjb F403XbXDjNaxisdwzh5H5XKfgHhpenEj/4A/YbV/f1kAOgkPT2GiRMTJvFlzVpcyMO71 NiPQhvO9vxY9orTIY8zUimQzJVn/1Fyl6Ky0uRqA1DObZzJbDlJR3eBUpxNkl8Du+sCo UHOQ== X-Gm-Message-State: AHPjjUht9m1lo4sGHA8Vx96PA+zM3ExrpO5IfDOeEzzMaMOLGPbSuxBC PQE4SSUOEUiBEN98BCI85i2WOg== X-Google-Smtp-Source: AOwi7QBfw25xA3THLmqYa8KsvmX1odO6cEXGUZKzvwgnlpjPVzjVBfp60PQ0ID6JYpTRnfQsJkX8Rg== X-Received: by 10.223.171.206 with SMTP id s72mr2019447wrc.27.1506185912528; Sat, 23 Sep 2017 09:58:32 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id v9sm853990wre.12.2017.09.23.09.58.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 23 Sep 2017 09:58:31 -0700 (PDT) Date: Sat, 23 Sep 2017 17:58:29 +0100 From: Leif Lindholm To: Laszlo Ersek Cc: edk2-devel@lists.01.org, Michael D Kinney , Jordan Justen , Andrew Fish , Ard Biesheuvel , "Gao, Liming" , "Zhu, Yonghong" Message-ID: <20170923165829.p3a2qej2rbz2adm2@bivouac.eciton.net> References: <20170920172755.22767-1-leif.lindholm@linaro.org> <20170920210903.tdpj6prki4ikrlth@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [RFC 0/6] Create central repository for boilerplate configuration X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 16:55:26 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 22, 2017 at 01:20:57PM +0200, Laszlo Ersek wrote: > On 09/20/17 23:09, Leif Lindholm wrote: > > On Wed, Sep 20, 2017 at 08:14:59PM +0200, Laszlo Ersek wrote: > > >> (2) Replacing a build define called FOOBAR with CONFIG_FOOBAR will break > >> all downstream build scripts. Is the CONFIG_ prefix a requirement? > > > > It was explicitly intended to break compatibility, to ensure we didn't > > end up with things accidentally working until something unrelated > > changed in the future. > > Interesting idea. I guess we could try to reach out to all of the > "repeat builders" of OVMF. The proposal to drive the CONFIG options as Pcds would also be a solution to this issue. > >> (3) I think PCDs should not be included in ConfigPkg DSC include files, > >> even if several platforms set the same value. The set of libraries and > >> driver modules commonly used for a given feature is mostly constant > >> across platforms (and it is easy to extend, incrementally); but I don't > >> think the same holds for PCDs. Especially if a user wants to change a > >> PCD for one platform but not the other. Even if repeated settings for a > >> PCD worked (all on the same level of "specificity"), I'd find the result > >> confusing. > > > > Also a subject for discussion. > > My intent was that if most of the open source platforms had an > > override on the default of a particular Pcd, we could override it in > > the config fragments without changing the .dec (and affecting > > non-public ports). > > Right, that's great... > > > Individual platforms can still override (again). > > ... but this "again" part is what confuses me (assuming it would > technically work). We'd have a PCD default in the .dec, then a setting > in the central .dsc.inc that ultimately qualifies as a platform-level > setting, and finally a setting in the actual platform .dsc, which *also* > qualifies as a platform-level setting. IOW, one in the .dec, and two in > the (final) .dsc. Yes. But I cannot think of another way of handling it, that does not also mean stuffing a lot of boiler plate back into the platform-level files. > I have no clue if this works, but even if it does, the priority could > depend on the order of inclusion, which I find confusing. Oh, definitely. But also under complete control of the platform. Potentially, if this becomes some great success story, we will want to extend the build command with a separate [includes] section to give greater control over enforcing order. > Liming, Yonghong, can you guys please comment on this? Yes, please :) Regards, Leif