Re: [PATCH v2 0/6] Add a stricter headers check

[David Marchand <david.marchand@redhat.com>]

On Fri, Dec 13, 2024 at 12:27 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Fri, Dec 13, 2024 at 11:50:04AM +0100, David Marchand wrote:
> > As explained in patch 6, the current headers check can not catch
> > issues when a public header includes an internal header.
> > Fixing this from meson does not seem an easy task.
> >
> > This series approach is to reimplement the check in a Makefile invoked
> > out of DPDK (like what is done for external compilation of examples).
> > This has the advantage of being simple, and avoiding any (non intentional)
> > implicit include path coming from the meson framework.
> >
> > As there was no easy way to distinguish "indirect" headers in an
> > installed DPDK, I chose to move those headers in a new sub directory
> > (patch 5).
> >
> > Patch 1-4 fixes have not been marked as backport material as those bugs
> > seems minor/easy to fix externally (by either including missing headers,
> > or enabling enable_driver_sdk option).
> >
> > For now, I left the check_includes= option untouched, as there may be
> > users of this check and this check still catches issues without
> > requiring to install DPDK.
> >
> For patches 5 & 6, I wonder if we can find a slightly different way to do
> this. I like the idea of using make to build chkincs free from possible
> environmental contamination from meson, but I really don't like the
> complexity of the resulting makefile!

Well, I am no makefile expert, though I find this one straightforward.
Thomas could probably enhance it :-).


> Rather than having to move the indirect headers to a subdirectory, and then
> have a makefile run a scan from the headers directory, how about instead
> generating the makefile (or possibly a build.ninja file) directly from
> meson itself? This means the makefile can already have the list of headers
> and C files necessary - no need for an extra subdirectory - and no need for
> large amounts of wildcard matching and replacements.

Scanning a staging directory insulates from bugs in meson and this is
the main point of this series.
If we add a new framework in meson (a list of headers or whatever),
any driver can still add some install_headers() somewhere and we are
back with a new hole.

What will ensure that nobody introduce a bug back with some include
path to the sources, being passed into the generated Makefile?

Headers should be checked from an installed directory (like a final
user) with minimal (ideally no) knowledge of what header is safe to
include.


> The downside is that the makefile is no longer with the source, but in the
> build directory. However, since the most likely use for this makefile is
> from the test-meson-builds script and from automated CIs, I don't see this
> being a major issue.

This part is not an issue.


-- 
David Marchand