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!
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. 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. WDYT? /Bruce
