+1 :) >From the 'consumer of api' side... the 'catch all' nature of vpe.api makes VPP less usable. Proper modularity would improve that, and be a benefit beyond the ones Damjan already mentioned.
That said, ccing the some of the GoVPP folks, because there are some (hopefully quite tractable) issues to consider in downstream generated APIs. Ed On Thu, Sep 9, 2021 at 11:18 AM Damjan Marion via lists.fd.io <damarion= cisco....@lists.fd.io> wrote: > > Guys, > > Can we get a rid of vpp/api/vpe.api and vpp/api/vpe_types.api by moving > content to more > appropriate places. I.e. some basic types and control_ping may be good > candidate for vlibapi/. > > It is quite weird that we have dozens of plugins depending on header files > autogenerated from the main executable directory…. > > If we gat a rid of hardcoded dependencies like we have with APIs today, we > will be able to modularize build. I.e. Florin asking to way to just build > VCL…. > > > Any volunteers? > > Thanks, > > — > Damjan > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20111): https://lists.fd.io/g/vpp-dev/message/20111 Mute This Topic: https://lists.fd.io/mt/85488417/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
