Damjan and others,
Over the past 6 or 8 months, we have had several build failures
due to missing include files in the installation of built RPMs.
It is a really simple C test to identify the failure. Here is an
almost minimal example:
#include <stdio.h>
#include <vlibmemory/api.h>
#include <vpp/api/vpe_msg_enum.h>
#include <vlibapi/api.h>
#define vl_typedefs
#define vl_endianfun
#include <vpp/api/vpe_all_api_h.h>
#undef vl_typedefs
#undef vl_endianfun
int main(int argc, char *argv[])
{
printf("Hello, VPP World!\n");
return 0;
}
If this compiles, all of the VNET include files are present.
If one of the VNET include files (like <vnet/tcp/tcp.api.h>)
is missing, it will not compile.
Other includes would be needed for the other plugins too.
There is currently no structure in place under vpp/test
using "make test" that is able to do this sort of compile
test of C code yet.
What about adding a vpp/test/c directory and a Makefile
to drive the build and execution of a couple simple test
cases like the above sample?
The trick here would be ensuring the use of the just-built
components, and not the pieces (possibly) already installed
on the host system. That is, most of this stuff from vpp/Makefile
would have to be propagated for use as well:
make -C test \
TEST_DIR=$(WS_ROOT)/test \
VPP_TEST_BUILD_DIR=$(BR)/build-$(2)-native \
VPP_TEST_BIN=$(BR)/install-$(2)-native/vpp/bin/vpp \
VPP_TEST_PLUGIN_PATH=$(call libexpand,$(libs),$(2),vpp_plugins) \
VPP_TEST_INSTALL_PATH=$(BR)/install-$(2)-native/ \
LD_LIBRARY_PATH=$(call libexpand,$(libs),$(2),) \
EXTENDED_TESTS=$(EXTENDED_TESTS) \
PYTHON=$(PYTHON) \
$(3)
Thoughts?
jdl
_______________________________________________
vpp-dev mailing list
[email protected]
https://lists.fd.io/mailman/listinfo/vpp-dev
