DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: <dev@dpdk.org>, <thomas@monjalon.net>
Subject: Re: [PATCH v2 0/6] Add a stricter headers check
Date: Fri, 13 Dec 2024 11:27:11 +0000	[thread overview]
Message-ID: <Z1waDwHFd6EDDwVI@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20241213105010.1527683-1-david.marchand@redhat.com>

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

  parent reply	other threads:[~2024-12-13 11:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 11:26 [RFC " David Marchand
2024-11-27 11:26 ` [RFC 1/6] baseband/acc: fix exported header David Marchand
2024-11-27 11:26 ` [RFC 2/6] drivers: drop export of driver headers David Marchand
2024-11-27 11:26 ` [RFC 3/6] eventdev: do not include driver header in DMA adapter David Marchand
2024-11-27 13:49   ` [EXTERNAL] " Amit Prakash Shukla
2024-11-27 11:26 ` [RFC 4/6] drivers: fix exported headers David Marchand
2024-11-27 11:26 ` [RFC 5/6] build: install indirect headers to a dedicated directory David Marchand
2024-11-27 11:42   ` Bruce Richardson
2024-12-10 13:36     ` David Marchand
2024-11-27 11:26 ` [RFC 6/6] buildtools: externally check exported headers David Marchand
2024-12-13 10:50 ` [PATCH v2 0/6] Add a stricter headers check David Marchand
2024-12-13 10:50   ` [PATCH v2 1/6] baseband/acc: fix exported header David Marchand
2024-12-13 11:01     ` Bruce Richardson
2024-12-13 10:50   ` [PATCH v2 2/6] drivers: drop export of driver headers David Marchand
2024-12-13 11:03     ` Bruce Richardson
2024-12-16  9:13       ` Andrew Rybchenko
2024-12-13 10:50   ` [PATCH v2 3/6] eventdev: do not include driver header in DMA adapter David Marchand
2024-12-13 11:04     ` Bruce Richardson
2024-12-13 10:50   ` [PATCH v2 4/6] drivers: fix exported headers David Marchand
2024-12-13 11:14     ` Bruce Richardson
2024-12-13 13:46       ` David Marchand
2024-12-16  8:15         ` David Marchand
2024-12-13 17:10     ` Stephen Hemminger
2024-12-13 10:50   ` [PATCH v2 5/6] build: install indirect headers to a dedicated directory David Marchand
2024-12-13 10:50   ` [PATCH v2 6/6] buildtools: externally check exported headers David Marchand
2024-12-13 11:27   ` Bruce Richardson [this message]
2024-12-13 13:38     ` [PATCH v2 0/6] Add a stricter headers check David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z1waDwHFd6EDDwVI@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).