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.1752.1602079191654142900 for ; Wed, 07 Oct 2020 06:59:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SFc6cyVN; 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=1602079190; 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=3ek6racQFzXs/CdInMyG2arg3iwXOI7HINvrOTSjmko=; b=SFc6cyVNjCzT0XpmsdBLOUSPweA2rbZ6BJVIusLaoIHd+j9vleZrB6YZ0vc/85wpSRHUOV icGcn7syYkrrfugiRGSBHI64RfY7tlOPFA9+GsaIXXMoIFZ+pCCZ+KUwtH5oo0tEzpYnDx gr2CBLlLgWB0EY2lgVcIteE3lVbi/uE= 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-34-yE5NG68rMVejn9xwCtyYfg-1; Wed, 07 Oct 2020 09:59:46 -0400 X-MC-Unique: yE5NG68rMVejn9xwCtyYfg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 773EF1902EAE; Wed, 7 Oct 2020 13:59:12 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-94.ams2.redhat.com [10.36.113.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id 062DE19C4F; Wed, 7 Oct 2020 13:59:09 +0000 (UTC) Subject: Re: [edk2-devel] expected behaviour of WorkspaceAutoGen.py? To: devel@edk2.groups.io, leif@nuviainc.com Cc: Bob Feng , Liming Gao , Yuwei Chen References: <20201006183045.GQ5623@vanye> From: "Laszlo Ersek" Message-ID: <698bf2bd-63db-337e-5a04-3b0d8211f6ae@redhat.com> Date: Wed, 7 Oct 2020 15:59:08 +0200 MIME-Version: 1.0 In-Reply-To: <20201006183045.GQ5623@vanye> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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/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 > > > > >