Re: [PATCH] BaseTools/tools_def: use separate PP definition for DTC

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 27 February 2018 at 18:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Tue, Feb 27, 2018 at 06:36:08PM +0000, Ard Biesheuvel wrote:
>> On 27 February 2018 at 18:33, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>> > On Tue, Feb 27, 2018 at 05:51:32PM +0000, Ard Biesheuvel wrote:
>> >> Clang's preprocessor behaves differently from GCC's, and produces
>> >> intermediate device tree source that still contains #pragma pack()
>> >> and other directives that the device tree compiler chokes on.
>> >>
>> >> For assembling device tree sources, it matters very little which
>> >> preprocessor is being used, so let's just use GNU CPP explicitly.
>> >
>> > Ah, right, same fundamental issue as
>> > 5b8766bb92debfa7b2f45a4a6d683b4227360d66.
>>
>> Yes, and I fail to see why changing just those two files makes a
>> meaningful difference.
>
> Probably because Secure96Dxe.inf has a lot more [Packages] and
> [LibraryClasses] dependencies than DeveloperBox.inf.
>
> This patch would undoubtedly also have resolved that issue.
> (As would clang preprocessor not throwing out C syntax when explicitly
> asked to provide asm.)
>
>> > However, this time triggered by autogen seemingly forcing inclusion of
>> > lots of central header files that are not even used, like
>> > MdePkg/Include/IndustryStandard/Bluetooth.h
>> > MdePkg/Include/IndustryStandard/Acpi10.h
>> > and so on.
>> >
>> > Is there any way to suppress these implicit includes from .dts
>> > processing?
>>
>> There is 'Trim', which can filter #include'd content, but using that
>> also robs us of the ability to #include .dtsi files, which was kind of
>> the point of using the preprocessor in the first place.
>
> Yeah, that'd definitely be missing the point slightly.
>
> I was thinking more along the lines of either excluding the autogen
> bits from the preprocessing or using a separate .inf for the .dts.
>

We need the AutoGen.h bits for the fixed PCD values, which was the
other reason for using the preprocessor in the first place.

Separate .inf would mean registering file GUIDs in the package .DEC,
so that the driver can find the binary image at runtime, which is what
I was trying to get away from by pulling it into the driver,
especially because we are dealing with overlay DT snippets, of which
there may be many, rather than a single DT (with a well known file
GUID) for the entire platform.

> If neither of those feels practical, the proposed patch is fine.
> It just feels a little bit clunky.
>

Yeah, I don't see any unclunky solutions, unfortunately.