Bug #6754
Updated by Victor Julien 3 months ago
With modern C libraries with multiple header files it is common to put them in a directory such as @/usr/include/suricata@ and in fact we already do that. But are not setup for allowing includes like: <pre> #include "suricata/filename.h" </pre> which would be ideal, as currently you have to do: <pre> #include "filename.h" </pre> with a "-I/usr/include/suricata", and this leaves us open bring in the wrong include file, as these filenames can be rather generic. While I have updated our @libsuricata-config --cflags@ to allow for @#include <suricata/filename.h>@, this does mean that Suricata now has to be **installed** before a plugin can be built. And most systems like this generally allow for plugins to be built by pointing to the source directory. The fix would be to move the source, or at least the header files form @./src@ to @./suricata@. It is pretty common for autoconf library projects to use the library name as the source directory instead of a generic @src@ "src@ for precisely this reason. Examples: - libhtp: places all source and includes in "htp" - curl: public includes in "include/curl", lib in "lib/" and binary in "src/" (a little harder for us with trying to retrofit a library interface) - Modern CMake guide, very much like curl (https://gitlab.com/CLIUtils/modern-cmake): "./apps/suricata.c" as the program, "./src" as the library sources and "./include/APP_NAME/" "./included/APP_NAME/" for the public includes