Re: [RFC v1 1/1] devtools: allow libraries with no global section

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

On Wed, Mar 6, 2024 at 5:40 PM Bruce Richardson
<bruce.richardson@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.szczepanek@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.szczepanek@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].


-- 
David Marchand