Project

General

Profile

Actions

Bug #6754

open

libsuricata: restructure directory and files to allow for include files to be name spaced

Added by Jason Ish 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Low
Assignee:
Target version:
Affected Versions:
Effort:
high
Difficulty:
Label:

Description

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:

#include "suricata/filename.h" 

which would be ideal, as currently you have to do:
#include "filename.h" 

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 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/" for the public includes


Related issues 1 (1 open0 closed)

Related to Suricata - Task #2693: tracking: libsuricataIn ProgressJason IshActions
Actions #1

Updated by Jason Ish 2 months ago

  • Related to Task #2693: tracking: libsuricata added
Actions #2

Updated by Victor Julien 2 months ago

  • Description updated (diff)
Actions

Also available in: Atom PDF