On Fri, Dec 13, 2024 at 12:27 PM Bruce Richardson <bruce.richard...@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
