ACK: [PATCH] devicetree/dt_base: Add base device-tree validity checks

[Colin Ian King]

On 23/04/16 04:37, Jeremy Kerr wrote:
> Hi Colin,
> 
> Thanks for the Ack.
> 
>> Seeing that we are using dtc here, we need a follow up patch that will
>> add dtc into the dependencies for the Debian packaging.  Do you mind
>> adding that too as another patch?
> 
> Sure, can do, and I can look at the optional libfdt dependency at the
> same time. However, there are a few options here:
> 
> 1) Build-Depends: libfdt-dev
>    Depends: device-tree-compiler
> 
>    - Require libfdt for all builds, and dtc for all installations. This
>      would be the most intrusive option, and causes an unnecessary
>      installation of dtc & libfdt0 on x86 machines where it wouldn't be
>      used.
> 
> 2) Build-depends: libfdt-dev
>    Depends: device-tree-compiler [ppc64el,powerpc]
> 
>    - Require libfdt for build, but dtc only on platforms where we'd
>      expect to parse device trees. Would introduce a shlib-depends on
>      libfdt0 though, for all arches.
> 
> 3) Build-depends: libfdt-dev [ppc64el,powerpc]
>    Depends: device-tree-compiler [ppc64el,powerpc]
> 
>    - Require libfdt & dtc only for powerpc builds
> 
> Options (1) and (2) also give us the option of making libfdt a
> manadatory build-time dependency, which means we could remove some of
> the conditional compilation rules, to make Makefiles & tests a little
> simpler. However, I'm not sure if the maintainers would be happy to make
> configure fail if its not present.
> 
> Option (3) is the least intrusive for x86, as it doesn't introduce any
> build or runtime dependencies.
> 
> I think I'd prefer the second - it means that device tree tests can be
> run on other arches (eg ARM), without a rebuild, just by installing dtc,
> and means that we don't install dtc on x86 (but we would install
> libfdt0). Also, it means we have less build-time variation between
> platforms, so we'd catch breakages in the fdt code sooner.
> 
> Let me know what you'd prefer.

Thanks for the break down of options, I appreciate the attention to
detail. Let's go with option (2); that does seem like the most pragmatic
solution.

Colin
> 
> Cheers,
> 
> 
> Jeremy