> > On 31 May 2017, at 18:18, Kinsella, Ray <ray.kinse...@intel.com> wrote: > > > Ok - but that doesn't get us any closer to helping newbies use the sample > plugin with 'make build' and 'make run', right? They still need to install > vpp, then the sample-plugin - lots of hoops.
make run is not built for running out-of-tree plugins but this should work: make bootstrap make pkg-deb dpkg -i build-root/*.deb cd src/examples/sample-plugin autoreconf -fis ./configure make sudo make install > > I disagree with a documentation heavy approach in principle, the wiki > suggests, that it similarly goes 'out of sync' quiet quickly. > > BTW - I wasn't advocating PLUGIN_DISABLED, I provided build-data configs in > the same way we do enabling/disabling dpdk features. ok > > The updated patch provides the separation between example/sample plugins and > plugins that was asked for. It re-uses all the same autotools configs as > src/plugins, so shouldn't go out of sync. i still disagree, sample-plugin should be stand-alone autotools project, you are removing configure.ac so for me it is no-go. > > Ray K > > > On 31/05/2017 17:05, Damjan Marion (damarion) wrote: >> >> I do not agree with that proposal, I think we need to have one sample of >> out-of-tree plugin as it is today. >> >> Still, I agree that we need to help newbies and my proposal is that we just >> document build process for out-of-tree plugins with simple README.md inside >> src/examples/sample-plugin. >> >> btw I consider use of PLUGIN_DISABLED (as default choice) as evil, as it >> mens that plugin will go out of sync sooner or later. >> >> >>> On 31 May 2017, at 17:37, Kinsella, Ray <ray.kinse...@intel.com> wrote: >>> >>> >>> Ok, typically example/sample code is intended to be used by the newest of >>> the new, newbies. So the sample plugin should work with 'make build' and >>> 'make run' with the minimum of hoops to enable. Asking these users to >>> install and configure VPP, then do the same for the sample plugin is too >>> much. I think that this thread exists, is testament that the UX could be >>> better - too many hoops. >>> >>> So here I what I suggest to fix. >>> >>> We create src/examples/plugins, put the sample plugin in here. >>> >>> The examples plugins (src/examples/plugins) are in-tree plugins and build >>> in exactly the same way as src/plugins from a build PoV (PLUGIN_ENABLED >>> etc), with the exception that the examples plugins are disabled by default. >>> They also live in the sample directory with no symlinks etc to src/plugin. >>> We then provide a way to explicitly enable them with a build-data config. >>> >>> I reworked the patch along these lines, does it make sense? >>> >>> Ray K >>> >>> On 31/05/2017 10:15, Damjan Marion (damarion) wrote: >>>> >>>> The idea of sample plugin is to show people how to build out-of-tree >>>> plugin. As that plugin was broken several times due to changes we made I >>>> created special ebuild package which builds sample plugin as part of >>>> verify job to ensure that plugin will not be broken again due to changes >>>> in vpp. >>>> >>>> Saying that, I strongly disagree that we move sample plugin into >>>> src/plugins, as that is place for in-tree plugins which actually do >>>> something useful. >>>> If people want to create additional in-tree plugin, there is many samples >>>> already in src/plugins so I don't see an need for additional one. >>>> >>>> So to continue discussion on this particular change, what do you think >>>> that it is broken? >>>> >>>> For me sequence: >>>> >>>> autoreconf -fis >>>> ./configure >>>> make >>>> make install >>>> >>>> Works perfectly fine. Off-course you need to have install vpp-dev package >>>> on your system... >>>> >>>> >>>>> On 30 May 2017, at 13:30, Kinsella, Ray <ray.kinse...@intel.com> wrote: >>>>> >>>>> The UX for the sample plugin is broken. Especially when you consider that >>>>> the people most likely to try it and use it, are those least familiar >>>>> with VPP. >>>>> >>>>> I tried the use it a few months ago in training and found the UX similar >>>>> then. So I put together a number of changes to integrate the plugin into >>>>> the VPP build system, provide a build var to enable and disable it, and >>>>> then added documentation for anyone new to VPP. >>>>> >>>>> https://gerrit.fd.io/r/#/c/6920/ >>>>> >>>>> Thanks, >>>>> >>>>> Ray K >>>>> >>>>> On 27/05/2017 18:27, Luke, Chris wrote: >>>>>> Wishes often come true when you turn them into patches. :) >>>>>> >>>>>> >>>>>> >>>>>> Chris. >>>>>> >>>>>> >>>>>> >>>>>> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] >>>>>> *On Behalf Of *Burt Silverman >>>>>> *Sent:* Saturday, May 27, 2017 10:33 >>>>>> *To:* Kinsella, Ray <ray.kinse...@intel.com> >>>>>> *Cc:* Alessio Silvestro <ale.silver...@gmail.com>; vpp-dev >>>>>> <vpp-dev@lists.fd.io> >>>>>> *Subject:* Re: [vpp-dev] VPP/How To Build The Sample Plugin >>>>>> >>>>>> >>>>>> >>>>>> Thanks, Ray, this is exactly what I needed, by coincidence. I wish your >>>>>> item 2. was placed commented out and almost word for word into the >>>>>> standard $TOPDIR/src/vpp/conf/startup.conf -- that would make things >>>>>> self documenting. >>>>>> >>>>>> Burt >>>>>> >>>>>> >>>>>> >>>>>> On Sat, May 27, 2017 at 8:30 AM, Kinsella, Ray <ray.kinse...@intel.com >>>>>> <mailto:ray.kinse...@intel.com>> wrote: >>>>>> >>>>>> So there is an easier way >>>>>> >>>>>> 1. make -C build-root PLATFORM=vpp TAG=vpp sample-plugin-install >>>>>> >>>>>> 2. adjusting the plugin path depending on where the VPP src is, add >>>>>> the following to your startup.conf >>>>>> >>>>>> plugins >>>>>> { >>>>>> path >>>>>> /root/src/vpp/build-root/install-vpp-native/sample-plugin/lib64/vpp_plugins/:/root/src/vpp/build-root/install-vpp_debug-native/vpp/lib64/vpp_plugins >>>>>> } >>>>>> >>>>>> Ray K >>>>>> >>>>>> >>>>>> On 26/05/2017 12:53, Alessio Silvestro wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I am trying to build the sample vpp-engine plug-in as explained here >>>>>> (https://wiki.fd.io/view/VPP/How_To_Build_The_Sample_Plugin >>>>>> <https://wiki.fd.noclick_io/view/VPP/How_To_Build_The_Sample_Plugin>). >>>>>> >>>>>> I already tested my vpp installation, for instance it works when I >>>>>> created a Source NAT. >>>>>> >>>>>> I downloaded the most updated version of the sample-plugin and >>>>>> run the >>>>>> following commands: >>>>>> >>>>>> sudo sh >>>>>> cd /usr/share/doc/vpp/examples >>>>>> cd /tmp/sample-plugin >>>>>> libtoolize >>>>>> aclocal >>>>>> autoconf >>>>>> autoheader >>>>>> >>>>>> ERROR 1:autoheader: error: AC_CONFIG_HEADERS not found in >>>>>> configure.ac <http://configure.noclick_ac> >>>>>> <http://configure.ac <http://configure.noclick_ac>> >>>>>> >>>>>> automake --add-missing >>>>>> chmod +x configure >>>>>> vpp_plugin_configure >>>>>> >>>>>> ERROR 2:vpp_plugin_configure: command not found >>>>>> >>>>>> >>>>>> So, first I have an error from the command autoheader. >>>>>> >>>>>> Second, I do not have the command vpp_plugin_configure. >>>>>> >>>>>> Any hints? >>>>>> >>>>>> Best regards, >>>>>> Alessio >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> vpp-dev mailing list >>>>>> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> >>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev >>>>>> <https://lists.fd.noclick_io/mailman/listinfo/vpp-dev> >>>>>> >>>>>> _______________________________________________ >>>>>> vpp-dev mailing list >>>>>> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> >>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev >>>>>> <https://lists.fd.noclick_io/mailman/listinfo/vpp-dev> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> vpp-dev mailing list >>>>> vpp-dev@lists.fd.io >>>>> https://lists.fd.io/mailman/listinfo/vpp-dev >>>> >> _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
