eal: move compat includes to common meson file
diff mbox series

Message ID 98ec658513d481f8d22c8b438cc3fedc4a718d3f.1547054251.git.anatoly.burakov@intel.com
State Superseded, archived
Delegated to: Thomas Monjalon
Headers show
Series
  • eal: move compat includes to common meson file
Related show

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/mellanox-Performance-Testing success Performance Testing PASS
ci/intel-Performance-Testing success Performance Testing PASS

Commit Message

Burakov, Anatoly Jan. 9, 2019, 5:18 p.m. UTC
Currently, while EAL does depend on librte_compat as far as common
meson build is concerned, for some reason the headers for that
library are not added into the list of includes. This is fixed in
Linuxapp-specific meson file, but is absent from FreeBSD meson file.

This worked fine up until recently, when an rte_compat dependency
was added to rte_log, which is a common header. Fix this issue by
adding librte_compat includes to common EAL meson file.

Fixes: 844514c73569 ("eal: build with meson")
Fixes: a8499f65a1d1 ("log: add missing experimental tag")
Cc: bruce.richardson@intel.com
Cc: david.marchand@redhat.com
Cc: stable@dpdk.org

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
 lib/librte_eal/linuxapp/eal/meson.build | 2 +-
 lib/librte_eal/meson.build              | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

David Marchand Jan. 9, 2019, 5:29 p.m. UTC | #1
On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov <anatoly.burakov@intel.com>
wrote:

> Currently, while EAL does depend on librte_compat as far as common
> meson build is concerned, for some reason the headers for that
> library are not added into the list of includes. This is fixed in
> Linuxapp-specific meson file, but is absent from FreeBSD meson file.
>
> This worked fine up until recently, when an rte_compat dependency
> was added to rte_log, which is a common header. Fix this issue by
> adding librte_compat includes to common EAL meson file.
>
> Fixes: 844514c73569 ("eal: build with meson")
> Fixes: a8499f65a1d1 ("log: add missing experimental tag")
> Cc: bruce.richardson@intel.com
> Cc: david.marchand@redhat.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>

lgtm, thanks.

Reviewed-by: David Marchand <david.marchand@redhat.com>
Bruce Richardson Jan. 9, 2019, 8:51 p.m. UTC | #2
On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
>    On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
>    <[1]anatoly.burakov@intel.com> wrote:
> 
>      Currently, while EAL does depend on librte_compat as far as common
>      meson build is concerned, for some reason the headers for that
>      library are not added into the list of includes. This is fixed in
>      Linuxapp-specific meson file, but is absent from FreeBSD meson file.
>      This worked fine up until recently, when an rte_compat dependency
>      was added to rte_log, which is a common header. Fix this issue by
>      adding librte_compat includes to common EAL meson file.
>      Fixes: 844514c73569 ("eal: build with meson")
>      Fixes: a8499f65a1d1 ("log: add missing experimental tag")
>      Cc: [2]bruce.richardson@intel.com
>      Cc: [3]david.marchand@redhat.com
>      Cc: [4]stable@dpdk.org
>      Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
> 
>    lgtm, thanks.
>    Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
>    --
>    David Marchand
> 
Agreed.
One other point I'd make is that having compat as a separate library seems
a little like overkill to me - it's just one header file! Is there a reason
why we don't just move it into the EAL where everyone can use it without
having to specify another dependency?

/Bruce
Thomas Monjalon Jan. 9, 2019, 9:36 p.m. UTC | #3
09/01/2019 21:51, Bruce Richardson:
> On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
> >    On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
> >    <[1]anatoly.burakov@intel.com> wrote:
> > 
> >      Currently, while EAL does depend on librte_compat as far as common
> >      meson build is concerned, for some reason the headers for that
> >      library are not added into the list of includes. This is fixed in
> >      Linuxapp-specific meson file, but is absent from FreeBSD meson file.
> >      This worked fine up until recently, when an rte_compat dependency
> >      was added to rte_log, which is a common header. Fix this issue by
> >      adding librte_compat includes to common EAL meson file.
> >      Fixes: 844514c73569 ("eal: build with meson")
> >      Fixes: a8499f65a1d1 ("log: add missing experimental tag")
> >      Cc: [2]bruce.richardson@intel.com
> >      Cc: [3]david.marchand@redhat.com
> >      Cc: [4]stable@dpdk.org
> >      Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
> > 
> >    lgtm, thanks.
> >    Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
> >    --
> >    David Marchand
> > 
> Agreed.
> One other point I'd make is that having compat as a separate library seems
> a little like overkill to me - it's just one header file! Is there a reason
> why we don't just move it into the EAL where everyone can use it without
> having to specify another dependency?

+1 for moving compat into EAL.
Burakov, Anatoly Jan. 10, 2019, 8:45 a.m. UTC | #4
On 09-Jan-19 9:36 PM, Thomas Monjalon wrote:
> 09/01/2019 21:51, Bruce Richardson:
>> On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
>>>     On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
>>>     <[1]anatoly.burakov@intel.com> wrote:
>>>
>>>       Currently, while EAL does depend on librte_compat as far as common
>>>       meson build is concerned, for some reason the headers for that
>>>       library are not added into the list of includes. This is fixed in
>>>       Linuxapp-specific meson file, but is absent from FreeBSD meson file.
>>>       This worked fine up until recently, when an rte_compat dependency
>>>       was added to rte_log, which is a common header. Fix this issue by
>>>       adding librte_compat includes to common EAL meson file.
>>>       Fixes: 844514c73569 ("eal: build with meson")
>>>       Fixes: a8499f65a1d1 ("log: add missing experimental tag")
>>>       Cc: [2]bruce.richardson@intel.com
>>>       Cc: [3]david.marchand@redhat.com
>>>       Cc: [4]stable@dpdk.org
>>>       Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
>>>
>>>     lgtm, thanks.
>>>     Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
>>>     --
>>>     David Marchand
>>>
>> Agreed.
>> One other point I'd make is that having compat as a separate library seems
>> a little like overkill to me - it's just one header file! Is there a reason
>> why we don't just move it into the EAL where everyone can use it without
>> having to specify another dependency?
> 
> +1 for moving compat into EAL.
> 

Presumably the reason to keep it separate would be to enable depending 
on it for libraries that EAL itself depends on (i.e. kvargs).
Thomas Monjalon Jan. 10, 2019, 8:52 a.m. UTC | #5
10/01/2019 09:45, Burakov, Anatoly:
> On 09-Jan-19 9:36 PM, Thomas Monjalon wrote:
> > 09/01/2019 21:51, Bruce Richardson:
> >> On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
> >>>     On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
> >>>     <[1]anatoly.burakov@intel.com> wrote:
> >>>
> >>>       Currently, while EAL does depend on librte_compat as far as common
> >>>       meson build is concerned, for some reason the headers for that
> >>>       library are not added into the list of includes. This is fixed in
> >>>       Linuxapp-specific meson file, but is absent from FreeBSD meson file.
> >>>       This worked fine up until recently, when an rte_compat dependency
> >>>       was added to rte_log, which is a common header. Fix this issue by
> >>>       adding librte_compat includes to common EAL meson file.
> >>>       Fixes: 844514c73569 ("eal: build with meson")
> >>>       Fixes: a8499f65a1d1 ("log: add missing experimental tag")
> >>>       Cc: [2]bruce.richardson@intel.com
> >>>       Cc: [3]david.marchand@redhat.com
> >>>       Cc: [4]stable@dpdk.org
> >>>       Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
> >>>
> >>>     lgtm, thanks.
> >>>     Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
> >>>     --
> >>>     David Marchand
> >>>
> >> Agreed.
> >> One other point I'd make is that having compat as a separate library seems
> >> a little like overkill to me - it's just one header file! Is there a reason
> >> why we don't just move it into the EAL where everyone can use it without
> >> having to specify another dependency?
> > 
> > +1 for moving compat into EAL.
> > 
> 
> Presumably the reason to keep it separate would be to enable depending 
> on it for libraries that EAL itself depends on (i.e. kvargs).

Yes, forgot this one.
Bruce Richardson Jan. 10, 2019, 10:02 a.m. UTC | #6
On Thu, Jan 10, 2019 at 09:52:43AM +0100, Thomas Monjalon wrote:
> 10/01/2019 09:45, Burakov, Anatoly:
> > On 09-Jan-19 9:36 PM, Thomas Monjalon wrote:
> > > 09/01/2019 21:51, Bruce Richardson:
> > >> On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
> > >>>     On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
> > >>>     <[1]anatoly.burakov@intel.com> wrote:
> > >>>
> > >>>       Currently, while EAL does depend on librte_compat as far as common
> > >>>       meson build is concerned, for some reason the headers for that
> > >>>       library are not added into the list of includes. This is fixed in
> > >>>       Linuxapp-specific meson file, but is absent from FreeBSD meson file.
> > >>>       This worked fine up until recently, when an rte_compat dependency
> > >>>       was added to rte_log, which is a common header. Fix this issue by
> > >>>       adding librte_compat includes to common EAL meson file.
> > >>>       Fixes: 844514c73569 ("eal: build with meson")
> > >>>       Fixes: a8499f65a1d1 ("log: add missing experimental tag")
> > >>>       Cc: [2]bruce.richardson@intel.com
> > >>>       Cc: [3]david.marchand@redhat.com
> > >>>       Cc: [4]stable@dpdk.org
> > >>>       Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
> > >>>
> > >>>     lgtm, thanks.
> > >>>     Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
> > >>>     --
> > >>>     David Marchand
> > >>>
> > >> Agreed.
> > >> One other point I'd make is that having compat as a separate library seems
> > >> a little like overkill to me - it's just one header file! Is there a reason
> > >> why we don't just move it into the EAL where everyone can use it without
> > >> having to specify another dependency?
> > > 
> > > +1 for moving compat into EAL.
> > > 
> > 
> > Presumably the reason to keep it separate would be to enable depending 
> > on it for libraries that EAL itself depends on (i.e. kvargs).
> 
> Yes, forgot this one.
> 

I also forgot that. However, that does bring up the thought that for some
of our headers we may want them available for all libraries even before EAL
is compiled up. [I think this hits on the idea Thomas was discussing of
splitting EAL up into two, where we have a core part that is always
compiled first and has no dependencies followed by another which is built
later and can have dependencies.]

For this specific issue, my thought is that we should indeed move compat.h
into EAL, but also add the EAL common/include/ path to the global include
path for the project, so all EAL headers (e.g. including those with defines
for cacheline size, and other common macros) are just always available.
Libs like kvargs and others should be able to use RTE_DIM etc. for
consistency with the rest of DPDK.

/Bruce
Thomas Monjalon Jan. 10, 2019, 10:33 a.m. UTC | #7
10/01/2019 11:02, Bruce Richardson:
> On Thu, Jan 10, 2019 at 09:52:43AM +0100, Thomas Monjalon wrote:
> > 10/01/2019 09:45, Burakov, Anatoly:
> > > On 09-Jan-19 9:36 PM, Thomas Monjalon wrote:
> > > > 09/01/2019 21:51, Bruce Richardson:
> > > >> One other point I'd make is that having compat as a separate library seems
> > > >> a little like overkill to me - it's just one header file! Is there a reason
> > > >> why we don't just move it into the EAL where everyone can use it without
> > > >> having to specify another dependency?
> > > > 
> > > > +1 for moving compat into EAL.
> > > 
> > > Presumably the reason to keep it separate would be to enable depending 
> > > on it for libraries that EAL itself depends on (i.e. kvargs).
> > 
> > Yes, forgot this one.
> 
> I also forgot that. However, that does bring up the thought that for some
> of our headers we may want them available for all libraries even before EAL
> is compiled up. [I think this hits on the idea Thomas was discussing of
> splitting EAL up into two, where we have a core part that is always
> compiled first and has no dependencies followed by another which is built
> later and can have dependencies.]
> 
> For this specific issue, my thought is that we should indeed move compat.h
> into EAL, but also add the EAL common/include/ path to the global include
> path for the project, so all EAL headers (e.g. including those with defines
> for cacheline size, and other common macros) are just always available.
> Libs like kvargs and others should be able to use RTE_DIM etc. for
> consistency with the rest of DPDK.

You are describing a cheap split :)
It would bring some definitions but not some non-inline functions.

I still think we should split in 2 libraries:
	- EAL as "Environment Abstraction Layer", i.e. basic stuffs
	- Initialization + core features (bus/dev and mem)
We could even move bus/dev and mem in separate libraries.
Burakov, Anatoly Jan. 10, 2019, 10:34 a.m. UTC | #8
On 10-Jan-19 10:02 AM, Bruce Richardson wrote:
> On Thu, Jan 10, 2019 at 09:52:43AM +0100, Thomas Monjalon wrote:
>> 10/01/2019 09:45, Burakov, Anatoly:
>>> On 09-Jan-19 9:36 PM, Thomas Monjalon wrote:
>>>> 09/01/2019 21:51, Bruce Richardson:
>>>>> On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
>>>>>>      On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
>>>>>>      <[1]anatoly.burakov@intel.com> wrote:
>>>>>>
>>>>>>        Currently, while EAL does depend on librte_compat as far as common
>>>>>>        meson build is concerned, for some reason the headers for that
>>>>>>        library are not added into the list of includes. This is fixed in
>>>>>>        Linuxapp-specific meson file, but is absent from FreeBSD meson file.
>>>>>>        This worked fine up until recently, when an rte_compat dependency
>>>>>>        was added to rte_log, which is a common header. Fix this issue by
>>>>>>        adding librte_compat includes to common EAL meson file.
>>>>>>        Fixes: 844514c73569 ("eal: build with meson")
>>>>>>        Fixes: a8499f65a1d1 ("log: add missing experimental tag")
>>>>>>        Cc: [2]bruce.richardson@intel.com
>>>>>>        Cc: [3]david.marchand@redhat.com
>>>>>>        Cc: [4]stable@dpdk.org
>>>>>>        Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
>>>>>>
>>>>>>      lgtm, thanks.
>>>>>>      Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
>>>>>>      --
>>>>>>      David Marchand
>>>>>>
>>>>> Agreed.
>>>>> One other point I'd make is that having compat as a separate library seems
>>>>> a little like overkill to me - it's just one header file! Is there a reason
>>>>> why we don't just move it into the EAL where everyone can use it without
>>>>> having to specify another dependency?
>>>>
>>>> +1 for moving compat into EAL.
>>>>
>>>
>>> Presumably the reason to keep it separate would be to enable depending
>>> on it for libraries that EAL itself depends on (i.e. kvargs).
>>
>> Yes, forgot this one.
>>
> 
> I also forgot that. However, that does bring up the thought that for some
> of our headers we may want them available for all libraries even before EAL
> is compiled up. [I think this hits on the idea Thomas was discussing of
> splitting EAL up into two, where we have a core part that is always
> compiled first and has no dependencies followed by another which is built
> later and can have dependencies.]
> 
> For this specific issue, my thought is that we should indeed move compat.h
> into EAL, but also add the EAL common/include/ path to the global include
> path for the project, so all EAL headers (e.g. including those with defines
> for cacheline size, and other common macros) are just always available.
> Libs like kvargs and others should be able to use RTE_DIM etc. for
> consistency with the rest of DPDK.
> 
> /Bruce
> 

Patches welcome so! :)
Bruce Richardson Jan. 10, 2019, 10:41 a.m. UTC | #9
On Thu, Jan 10, 2019 at 10:34:19AM +0000, Burakov, Anatoly wrote:
> On 10-Jan-19 10:02 AM, Bruce Richardson wrote:
> > On Thu, Jan 10, 2019 at 09:52:43AM +0100, Thomas Monjalon wrote:
> > > 10/01/2019 09:45, Burakov, Anatoly:
> > > > On 09-Jan-19 9:36 PM, Thomas Monjalon wrote:
> > > > > 09/01/2019 21:51, Bruce Richardson:
> > > > > > On Wed, Jan 09, 2019 at 06:29:32PM +0100, David Marchand wrote:
> > > > > > >      On Wed, Jan 9, 2019 at 6:18 PM Anatoly Burakov
> > > > > > >      <[1]anatoly.burakov@intel.com> wrote:
> > > > > > > 
> > > > > > >        Currently, while EAL does depend on librte_compat as far as common
> > > > > > >        meson build is concerned, for some reason the headers for that
> > > > > > >        library are not added into the list of includes. This is fixed in
> > > > > > >        Linuxapp-specific meson file, but is absent from FreeBSD meson file.
> > > > > > >        This worked fine up until recently, when an rte_compat dependency
> > > > > > >        was added to rte_log, which is a common header. Fix this issue by
> > > > > > >        adding librte_compat includes to common EAL meson file.
> > > > > > >        Fixes: 844514c73569 ("eal: build with meson")
> > > > > > >        Fixes: a8499f65a1d1 ("log: add missing experimental tag")
> > > > > > >        Cc: [2]bruce.richardson@intel.com
> > > > > > >        Cc: [3]david.marchand@redhat.com
> > > > > > >        Cc: [4]stable@dpdk.org
> > > > > > >        Signed-off-by: Anatoly Burakov <[5]anatoly.burakov@intel.com>
> > > > > > > 
> > > > > > >      lgtm, thanks.
> > > > > > >      Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
> > > > > > >      --
> > > > > > >      David Marchand
> > > > > > > 
> > > > > > Agreed.
> > > > > > One other point I'd make is that having compat as a separate library seems
> > > > > > a little like overkill to me - it's just one header file! Is there a reason
> > > > > > why we don't just move it into the EAL where everyone can use it without
> > > > > > having to specify another dependency?
> > > > > 
> > > > > +1 for moving compat into EAL.
> > > > > 
> > > > 
> > > > Presumably the reason to keep it separate would be to enable depending
> > > > on it for libraries that EAL itself depends on (i.e. kvargs).
> > > 
> > > Yes, forgot this one.
> > > 
> > 
> > I also forgot that. However, that does bring up the thought that for some
> > of our headers we may want them available for all libraries even before EAL
> > is compiled up. [I think this hits on the idea Thomas was discussing of
> > splitting EAL up into two, where we have a core part that is always
> > compiled first and has no dependencies followed by another which is built
> > later and can have dependencies.]
> > 
> > For this specific issue, my thought is that we should indeed move compat.h
> > into EAL, but also add the EAL common/include/ path to the global include
> > path for the project, so all EAL headers (e.g. including those with defines
> > for cacheline size, and other common macros) are just always available.
> > Libs like kvargs and others should be able to use RTE_DIM etc. for
> > consistency with the rest of DPDK.
> > 
> > /Bruce
> > 
> 
> Patches welcome so! :)
> 
Working on it... :-)
David Marchand Jan. 10, 2019, 10:44 a.m. UTC | #10
On Thu, Jan 10, 2019 at 11:41 AM Bruce Richardson <
bruce.richardson@intel.com> wrote:

> On Thu, Jan 10, 2019 at 10:34:19AM +0000, Burakov, Anatoly wrote:
> > On 10-Jan-19 10:02 AM, Bruce Richardson wrote:
> > > I also forgot that. However, that does bring up the thought that for
> some
> > > of our headers we may want them available for all libraries even
> before EAL
> > > is compiled up. [I think this hits on the idea Thomas was discussing of
> > > splitting EAL up into two, where we have a core part that is always
> > > compiled first and has no dependencies followed by another which is
> built
> > > later and can have dependencies.]
> > >
> > > For this specific issue, my thought is that we should indeed move
> compat.h
> > > into EAL, but also add the EAL common/include/ path to the global
> include
> > > path for the project, so all EAL headers (e.g. including those with
> defines
> > > for cacheline size, and other common macros) are just always available.
> > > Libs like kvargs and others should be able to use RTE_DIM etc. for
> > > consistency with the rest of DPDK.
> > >
> > > /Bruce
> > >
> >
> > Patches welcome so! :)
> >
> Working on it... :-)
>

I don't think it is that quick to do, so, for the time being, do we go with
this patch ?
Bruce Richardson Jan. 10, 2019, 10:48 a.m. UTC | #11
On Thu, Jan 10, 2019 at 11:44:07AM +0100, David Marchand wrote:
>    On Thu, Jan 10, 2019 at 11:41 AM Bruce Richardson
>    <[1]bruce.richardson@intel.com> wrote:
> 
>      On Thu, Jan 10, 2019 at 10:34:19AM +0000, Burakov, Anatoly wrote:
>      > On 10-Jan-19 10:02 AM, Bruce Richardson wrote:
>      > > I also forgot that. However, that does bring up the thought that
>      for some
>      > > of our headers we may want them available for all libraries even
>      before EAL
>      > > is compiled up. [I think this hits on the idea Thomas was
>      discussing of
>      > > splitting EAL up into two, where we have a core part that is
>      always
>      > > compiled first and has no dependencies followed by another which
>      is built
>      > > later and can have dependencies.]
>      > >
>      > > For this specific issue, my thought is that we should indeed
>      move compat.h
>      > > into EAL, but also add the EAL common/include/ path to the
>      global include
>      > > path for the project, so all EAL headers (e.g. including those
>      with defines
>      > > for cacheline size, and other common macros) are just always
>      available.
>      > > Libs like kvargs and others should be able to use RTE_DIM etc.
>      for
>      > > consistency with the rest of DPDK.
>      > >
>      > > /Bruce
>      > >
>      >
>      > Patches welcome so! :)
>      >
>      Working on it... :-)
> 
>    I don't think it is that quick to do, so, for the time being, do we go
>    with this patch ?
>    --
>    David Marchand
> 
While I'm not splitting EAL up, I have got a working patch for merging
compat into EAL, and it seems to build ok for meson and ninja. I'll send it
out shortly once I finish my final cleanup and checks on it. Incidentally,
it doesn't appear that compat is used by kvargs, despite it being listed as
a dependency of it.

/Bruce
Bruce Richardson Jan. 10, 2019, 11:13 a.m. UTC | #12
On Thu, Jan 10, 2019 at 10:48:39AM +0000, Bruce Richardson wrote:
> On Thu, Jan 10, 2019 at 11:44:07AM +0100, David Marchand wrote:
> >    On Thu, Jan 10, 2019 at 11:41 AM Bruce Richardson
> >    <[1]bruce.richardson@intel.com> wrote:
> > 
> >      On Thu, Jan 10, 2019 at 10:34:19AM +0000, Burakov, Anatoly wrote:
> >      > On 10-Jan-19 10:02 AM, Bruce Richardson wrote:
> >      > > I also forgot that. However, that does bring up the thought that
> >      for some
> >      > > of our headers we may want them available for all libraries even
> >      before EAL
> >      > > is compiled up. [I think this hits on the idea Thomas was
> >      discussing of
> >      > > splitting EAL up into two, where we have a core part that is
> >      always
> >      > > compiled first and has no dependencies followed by another which
> >      is built
> >      > > later and can have dependencies.]
> >      > >
> >      > > For this specific issue, my thought is that we should indeed
> >      move compat.h
> >      > > into EAL, but also add the EAL common/include/ path to the
> >      global include
> >      > > path for the project, so all EAL headers (e.g. including those
> >      with defines
> >      > > for cacheline size, and other common macros) are just always
> >      available.
> >      > > Libs like kvargs and others should be able to use RTE_DIM etc.
> >      for
> >      > > consistency with the rest of DPDK.
> >      > >
> >      > > /Bruce
> >      > >
> >      >
> >      > Patches welcome so! :)
> >      >
> >      Working on it... :-)
> > 
> >    I don't think it is that quick to do, so, for the time being, do we go
> >    with this patch ?
> >    --
> >    David Marchand
> > 
> While I'm not splitting EAL up, I have got a working patch for merging
> compat into EAL, and it seems to build ok for meson and ninja. I'll send it
> out shortly once I finish my final cleanup and checks on it. Incidentally,
> it doesn't appear that compat is used by kvargs, despite it being listed as
> a dependency of it.
> 
> /Bruce

Please review/test: http://patches.dpdk.org/patch/49576/

Thanks,
/Bruce

Patch
diff mbox series

diff --git a/lib/librte_eal/linuxapp/eal/meson.build b/lib/librte_eal/linuxapp/eal/meson.build
index 6e31c2aaa..7e68b2c0d 100644
--- a/lib/librte_eal/linuxapp/eal/meson.build
+++ b/lib/librte_eal/linuxapp/eal/meson.build
@@ -1,7 +1,7 @@ 
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2017 Intel Corporation
 
-eal_inc += include_directories('include', '../../../librte_compat')
+eal_inc += include_directories('include')
 install_subdir('include/exec-env', install_dir: get_option('includedir'))
 
 env_objs = []
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index a18f3a826..67e26de8d 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -4,7 +4,7 @@ 
 # Custom EAL processing. EAL is complicated enough that it can't just
 # have a straight list of headers and source files.
 # Initially pull in common settings
-eal_inc = [global_inc]
+eal_inc = [global_inc, include_directories('../librte_compat')]
 subdir('common') # defines common_sources, common_objs, etc.
 
 # Now do OS/exec-env specific settings, including building kernel modules