Its conservative - makes fewer changes and preserves the separate
packaging for the sample plugin, so its a good approach.
My only piece of feedback on it, is that we are starting to end up with
build 'config' divided across 'build-data' and environment variables,
which is something we may need to make consistent over time.
I don't know if the sample plugin is important enough to pollute the
'make help' with detail of how to build it. I thought the 'build-data'
config and markdown document describing the plugin and how to build it
was a better approach.
In anycase (env var or build-data config), I am happy to excise from my
original patch, the markdown doc, update it with the new build details
and doxygen comments etc and submit those seperately. Once this patch
goes through.
Ray K
On 31/05/2017 18:28, Damjan Marion (damarion) wrote:
Something like:
https://gerrit.fd.io/r/#/c/6962/
On 31 May 2017, at 18:50, Damjan Marion (damarion) <damar...@cisco.com> wrote:
What about:
export VPP_WITH_SAMPLE_PLUGIN=yes
make build
make run
Does this work for you?
On 31 May 2017, at 18:45, Kinsella, Ray <ray.kinse...@intel.com> wrote:
I think the idea that a user needs to go all the effort to install VPP and then
Sample plugin, in order to run trivial sample code as way too much work.
This is something we expect, they are going to copy and base a new plugin off.
So why we would bother making them go to all the effort to install it on their
system just to play with it.
Either way, I don't see this being reconciled, so I consigned the patch to
/dev/null.
Ray K
On 31/05/2017 17:31, Damjan Marion (damarion) wrote:
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
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
