expected behaviour of WorkspaceAutoGen.py?

expected behaviour of WorkspaceAutoGen.py?

[Leif Lindholm]

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?

Best Regards,

Leif

Re: [edk2-devel] expected behaviour of WorkspaceAutoGen.py?

[Laszlo Ersek]

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, <https://bugzilla.tianocore.org/show_bug.cgi?id=1264> seems
distantly related. Commit eb99b52f9888e99f449b8b984ee5a095027b5fd9
modified the neighborhood of the error message you mention.

Thanks
Laszlo

> 
> Best Regards,
> 
> Leif
> 
> 
> 
> 
> 

Re: [edk2-devel] expected behaviour of WorkspaceAutoGen.py?

[Bob Feng]

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.

Thanks,
Bob

-----Original Message-----
From: devel@edk2.groups.io <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 <bob.c.feng@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Chen, Christine <yuwei.chen@intel.com>
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, <https://bugzilla.tianocore.org/show_bug.cgi?id=1264> seems distantly related. Commit eb99b52f9888e99f449b8b984ee5a095027b5fd9
modified the neighborhood of the error message you mention.

Thanks
Laszlo

> 
> Best Regards,
> 
> Leif
> 
> 
> 
> 
> 

Re: [edk2-devel] expected behaviour of WorkspaceAutoGen.py?

[Laszlo Ersek]

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 <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 <bob.c.feng@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Chen, Christine <yuwei.chen@intel.com>
> 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, <https://bugzilla.tianocore.org/show_bug.cgi?id=1264> seems distantly related. Commit eb99b52f9888e99f449b8b984ee5a095027b5fd9
> modified the neighborhood of the error message you mention.
> 
> Thanks
> Laszlo
> 
>>
>> Best Regards,
>>
>> Leif
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
>