On 06/03/2024 16:51, David Marchand wrote:
On Wed, Mar 6, 2024 at 5:40 PM Bruce Richardson
<bruce.richard...@intel.com> wrote:

On Wed, Mar 06, 2024 at 05:14:15PM +0100, David Marchand wrote:
On Wed, Mar 6, 2024 at 3:36 PM Paul Szczepanek <paul.szczepa...@arm.com> wrote:

If a library has no global section in the version.map
allow it not to have symbols and not report it as an error.
This happens if a library doesn't export any functions
if they're all inline.

Signed-off-by: Paul Szczepanek <paul.szczepa...@arm.com>

Added Bruce.

Having a library without any actual code compiled is (I think) new in DPDK.

On the other hand, for headers only, there should be no need for a
version.map file at all.

The current meson code expects that every library provides some files
to compile via the sources variable and it expects a version.map file
too.
I wonder if we could skip the whole library generation at the
lib/meson.build level.
Something like:

diff --git a/lib/meson.build b/lib/meson.build
index 179a272932..f0bbab6658 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -222,6 +222,10 @@ foreach l:libraries
      includes += include_directories(l)
      dpdk_includes += include_directories(l)

+    if sources.length() == 0
+        continue
+    endif
+
      if developer_mode and is_windows and use_function_versioning
          message('@0@: Function versioning is not supported by
Windows.'.format(name))
      endif

No version.map, no check to update :-)

Two thoughts/suggestions here:

* in original meson port we did have support for header only libraries - I
   think for rte_compat.h, but that was done away with when the header was
   just merged into EAL. See [1]
* for a header only lib - if we are prepared to forego being able to
   disable it - the easiest enablement path may be to not add the directory
   to the list of libraries, and just add the header file path to the global
   include path, or perhaps some other library include path. How to make it
   work best may depend on what the library does and what other DPDK libs, if
   any, it depends upon.

If the goal is to provide those headers as public API, you still need
to call install_headers() somewhere.
And I don't like losing control over disabling about what is shipped.

I prefer [1].



I have uploaded a PATCH that follows [1]:
https://patches.dpdk.org/project/dpdk/patch/20240306221709.166722-2-paul.szczepa...@arm.com/
It might be easier to review by applying first as most of the diff is just tab indentation change caused by the if.
I have tested it with my header only library and it works.

Reply via email to