From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web10.11477.1602242731995998709 for ; Fri, 09 Oct 2020 04:25:32 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PRLKLKka; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602242731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fuNeL0aazBs61dkAG0QKtPAaulCl2Wlvzm0ZnIvxtRw=; b=PRLKLKkakPH36HXRwREUhYlVY2Vtpow3WOcakfwTp429gTZbEIhEP61Qkl9w44ILBGD3O8 yJKGTQvtP866rZk7uxXKiTpa5aG1l0gwL9ul1q0Gyt7R4iTiKiRVJ/2arc0opJjOPLvVf3 Coa5BQ4QQxX+2Jynia+BU/Uvmp5Gos0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-190-lDe8UDseMXqDhOgoh0NI7A-1; Fri, 09 Oct 2020 07:25:27 -0400 X-MC-Unique: lDe8UDseMXqDhOgoh0NI7A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0833B87505F; Fri, 9 Oct 2020 11:25:26 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-57.ams2.redhat.com [10.36.113.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id 789CA7664E; Fri, 9 Oct 2020 11:25:24 +0000 (UTC) Subject: Re: [edk2-devel] expected behaviour of WorkspaceAutoGen.py? To: "Feng, Bob C" , "devel@edk2.groups.io" , "leif@nuviainc.com" Cc: Liming Gao , "Chen, Christine" References: <20201006183045.GQ5623@vanye> <698bf2bd-63db-337e-5a04-3b0d8211f6ae@redhat.com> From: "Laszlo Ersek" Message-ID: <4ee7e296-9f7c-de5b-c842-0871f2b6887f@redhat.com> Date: Fri, 9 Oct 2020 13:25:23 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/09/20 05:42, Feng, Bob C wrote: > This error will happen when a PCD is used in FDF but it is not declared in any DEC files, which are listed in all INF and DSC [Packages] section. But the PCD is declared in a DEC file; namely, in the DEC file that is referenced by the library instance's [Packages] section. Leif, I suggest reporting a BZ, with a minimal reproducer attached. Thanks Laszlo > > Thanks, > Bob > > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Laszlo Ersek > Sent: Wednesday, October 7, 2020 9:59 PM > To: devel@edk2.groups.io; leif@nuviainc.com > Cc: Feng, Bob C ; Liming Gao ; Chen, Christine > Subject: Re: [edk2-devel] expected behaviour of WorkspaceAutoGen.py? > > On 10/06/20 20:30, Leif Lindholm wrote: >> Hi BaseTools maintainers, >> >> Posting mostly for this to be available in the list archive, but I'm >> also curious as to whether this is expected behaviour, and would like >> confirmation of my understanding on the behaviour. >> >> We started very lazily creating a new platform port based on >> edk2-platforms Platform/Qemu/SbsaQemu/, by creating just my own >> .dsc/.fdf and .dec files. Then we created a single library to override >> one in SbsaQemu, which used a Pcd from our new .dec - initialized in >> the .fdf. >> >> Now, that library was the only thing with a dependency on our new >> .dec, and (since it's a library), it is not directly listed in the >> .fdf. >> >> When I run try to build the platform, this triggers the >> "PCD (%s.%s) used in FDF is not declared in DEC files." >> error in BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py. >> >> Adding a dummy dependency on the .dec to one of the .inf files listed >> in the .fdf resolved this issue. >> >> So, two questions: >> 1) Have I correctly described the behaviour? >> 2) Is this intended behaviour? > > IMO you should not get a build error, as long as the new library instance INF correctly specifies the dependency on both DEC files in its [Packages] section -- old DEC for lib class, new DEC for PCD declaration --, *and* the new library instance INF file lists the PCD, *and* the new library instance is used for resolving the lib class in question, in the new DSC file. > > What access methods are permitted for the PCD in question, in the new DEC file? I vaguely recall problems when trying to set dynamic PCDs in FDF files, using the SET statement. > > Also, seems distantly related. Commit eb99b52f9888e99f449b8b984ee5a095027b5fd9 > modified the neighborhood of the error message you mention. > > Thanks > Laszlo > >> >> Best Regards, >> >> Leif >> >> >> >> >> > > > > > >