Hi Damian. Why do you care? I just looked in the flowprobe folder, for example, and there is a flowprobe_test.c. We have tests in the src tree. I'm not trying to argue for or against this, I'm trying to understand why.
We can make out of tree tests work without moving the files. The test runner has a custom discovery method. We just need to agree on how we want it to behave. What is the process used for out of tree plugins? What has worked for me is to create a new repository and add the repo as a git submodule under plugins. I'm glad Dave provided some background. From my vantage point, Andrew said on the list a while back that the maintainers owned the tests and shortly thereafter, the tests started to be rearranged under their modules. I do however want to raise the scapy licensing issue. If I recall correctly, there was some talk from the tsc about tagging the test folder to indicate that the use of scapy required different licensing, so a new plan would need to be devised. I was doing some research on this, and the FRR folks seem to have addressed the licensing issue around the scapy code, by not importing it but rather by moving it to a single file that they fork to run. See: https://github.com/FRRouting/frr/blob/master/tests/topotests/lib/send_bsr_packet.py Paul On Thu, Mar 25, 2021 at 4:13 PM Dave Wallace <dwallac...@gmail.com> wrote: > Hi Damjan, > > This initiative originated with the wider adoption of plugin development > at the request of Dave Barach to allow the development of plugins outside > the VPP repo. After completing the job for plugins, there were several > requests to extend that to all of the features. Presumably this was > coupled with the desire to migrate feature source code from vnet into the > plugin arena, but I don't recall all of the details of the discussion. > > Unfortunately, this effort stalled across several releases due to lack of > cycles and I'm just now in the process of completing the job. > > I'm perfectly ok accepting a -2 for test code that maintainers prefer to > leave in .../vpp/test, but I don't see the original requirement to > co-locate plugin source & test code going away. So the majority of the > feature source & test code will remain structured that way and the end > result will be inconsistent at best. > > Personally, I think that it makes sense to continue to move features > source, test code, and documentation to be co-located in a modular and > consistent sub-tree structure. I also see value in migrating features out > of vnet into the plugin sub-tree. > > For what its worth, the changes to test/Makefile gather all of the source > as soft links into the build tree (.../vpp/build-root/build-test/src), but > I understand that is not the same your original plan. > > Thanks, > -daw- > > On 3/25/2021 3:16 PM, Damjan Marion via lists.fd.io wrote: > > Hi, > > It may be that it is not discussed or i was just ignorant, but I noticed that > there is ongoing activity to scatter tests all across the src/. > When I started "make test" long long time ago i intentionally put it to > separate tree following the pattern from other projects and to be honest > it makes me more sense that all tests are contained in the separate tree. > > Are we sure that this test file scatter activity is right thing to do? > Anyone aware of any other project doing the same? > > — > Damjan > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19029): https://lists.fd.io/g/vpp-dev/message/19029 Mute This Topic: https://lists.fd.io/mt/81611239/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
