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

[Paul Szczepanek <paul.szczepanek@arm.com>]

On 06/03/2024 16:51, David Marchand wrote:
> 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].
> 
> 

I have uploaded a PATCH that follows [1]:
https://patches.dpdk.org/project/dpdk/patch/20240306221709.166722-2-paul.szczepanek@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.