crypto/scheduler: fix header install with meson

  The headers variable is only used in lib/meson.build context.
For drivers, an explicit install_headers() is necessary.

Reproduced while compiling the l2fwd-crypto example out of meson
(which can be done by adding it in devtools/test-meson-builds.sh
examples build test).

Fixes: cd2b6458a1cb ("crypto/scheduler: add in meson build")
Cc: stable@dpdk.org

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 drivers/crypto/scheduler/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On Thu, Sep 17, 2020 at 05:09:17PM +0200, David Marchand wrote:
> The headers variable is only used in lib/meson.build context.
> For drivers, an explicit install_headers() is necessary.
> 
> Reproduced while compiling the l2fwd-crypto example out of meson
> (which can be done by adding it in devtools/test-meson-builds.sh
> examples build test).
> 
> Fixes: cd2b6458a1cb ("crypto/scheduler: add in meson build")
> Cc: stable@dpdk.org
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
>  drivers/crypto/scheduler/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Originally I only put the "headers" variable in the "lib" folder
meson.build because it was not expected that many drivers should have
private headers. However, perhaps it's worthwhile adding it now:
a) because private headers, while not common, are not unusual
b) for consistency and ease of use.

Thoughts?

/Bruce
  

On Thu, Sep 17, 2020 at 05:09:17PM +0200, David Marchand wrote:
> The headers variable is only used in lib/meson.build context.
> For drivers, an explicit install_headers() is necessary.
> 
> Reproduced while compiling the l2fwd-crypto example out of meson
> (which can be done by adding it in devtools/test-meson-builds.sh
> examples build test).
> 
> Fixes: cd2b6458a1cb ("crypto/scheduler: add in meson build")
> Cc: stable@dpdk.org
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---

Acked-by: Bruce Richardson <bruce.richardson@intel.com>
  

On Thu, Sep 17, 2020 at 5:29 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Thu, Sep 17, 2020 at 05:09:17PM +0200, David Marchand wrote:
> > The headers variable is only used in lib/meson.build context.
> > For drivers, an explicit install_headers() is necessary.
> >
> > Reproduced while compiling the l2fwd-crypto example out of meson
> > (which can be done by adding it in devtools/test-meson-builds.sh
> > examples build test).
> >
> > Fixes: cd2b6458a1cb ("crypto/scheduler: add in meson build")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> >  drivers/crypto/scheduler/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> Originally I only put the "headers" variable in the "lib" folder
> meson.build because it was not expected that many drivers should have
> private headers. However, perhaps it's worthwhile adding it now:
> a) because private headers, while not common, are not unusual
> b) for consistency and ease of use.
>
> Thoughts?

Yep, I can do it in a followup patch now, still looking at your RFC
series though.. :-)
  

On Thu, Sep 17, 2020 at 05:33:23PM +0200, David Marchand wrote:
> On Thu, Sep 17, 2020 at 5:29 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Thu, Sep 17, 2020 at 05:09:17PM +0200, David Marchand wrote:
> > > The headers variable is only used in lib/meson.build context.
> > > For drivers, an explicit install_headers() is necessary.
> > >
> > > Reproduced while compiling the l2fwd-crypto example out of meson
> > > (which can be done by adding it in devtools/test-meson-builds.sh
> > > examples build test).
> > >
> > > Fixes: cd2b6458a1cb ("crypto/scheduler: add in meson build")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > ---
> > >  drivers/crypto/scheduler/meson.build | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > Originally I only put the "headers" variable in the "lib" folder
> > meson.build because it was not expected that many drivers should have
> > private headers. However, perhaps it's worthwhile adding it now:
> > a) because private headers, while not common, are not unusual
> > b) for consistency and ease of use.
> >
> > Thoughts?
> 
> Yep, I can do it in a followup patch now, still looking at your RFC
> series though.. :-)
>
No rush, what we have now has worked reasonably well for the last few
years! :-)
If you don't get to it, I can always look at it post-19.11.