On Tue, Jan 17, 2017 at 3:45 PM, Alexander Popovsky (apopovsk) < apopo...@cisco.com> wrote:
> We have seen a similar issue related to the same ‘API refactoring : dpdk’ > change. > We are using an external API binding layer in C-language in our VPP based > solution. > After the change, it took some digging to add –DDPDK=1 to get things back > to working. > > Looking forward, should it be considered a standard practice in VPP for > the API (IDs) to be dependent on the features compiled (enabled) in VPP? > In such case, should we consider having a generated config.h (similar to > Linux kernel) to be included by the external C-code? > > Thanks, > -AI > Right. Except it is more insidious than that. The installed include files have an #ifdef in them that changes the message ID values. The corresponding libraries were compiled using on or the other of those choices. Which one? No way to tell. But one of them is right and the other is wrong. I think the include file should never present the ability to make the message ID values be variant. jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
