How to make compiler from NS-3 finds missing file(that is already included in directory)

[Eduardo Lichtenfels Riccio]

Hello NS-3 users community!

I am having a C++ basic compilation error where my scratch folder code “handovermy.cc” is not able to find the library “json.hpp”.

My question is, which NS-3 directory usually compiler that is looking at "scratch" folder look for libraries where I can add this "json.hpp" file? I have tried adding the “json.hpp” inside the root ns-3 directory and tried to add this file into “scratch” and “contrib” folder but still compiler is not able to find the “json.hpp” file and I am getting below error.

Shell Log:

“@user-VirtualBox:~/Apps/Handover-ns3/ns-3-dev-git$ ./ns3

 

[  0%] Building CXX object scratch/CMakeFiles/scratch_handovermy.dir/handovermy.cc.o

 

/home/user/Apps/Handover-ns3/ns-3-dev-git/scratch/handovermy.cc:42:10: fatal error: json.hpp: No such file or directory

 

   42 | #include <json.hpp>

 

      |          ^~~~~~~~~~

 

compilation terminated.

 

gmake[2]: *** [scratch/CMakeFiles/scratch_handovermy.dir/build.make:76: scratch/CMakeFiles/scratch_handovermy.dir/handovermy.cc.o] Error 1

 

gmake[1]: *** [CMakeFiles/Makefile2:14460: scratch/CMakeFiles/scratch_handovermy.dir/all] Error 2

 

gmake: *** [Makefile:136: all] Error 2

 

Finished executing the following commands:

 

cd cmake-cache; cmake --build . -j 1 ; cd ..”

 

Thank you in advance!

[Tommaso Pecorella]

This isn't an ns-3 issue, it's more a C++ issue.

#include <json.hpp> (Angle-bracket form) means that the compiler will search for the headers in the "system" path. On the contrary, #include "json.hpp"  (Quoted form) searches for the files also in other paths - see here for a long explanation

Shortly put:

• header should go into the scratch folder (or a sub-folder if this feature is used)
• include should use quoted form: #include "json.hpp"

[Gabriel Ferreira]

If the json.hpp is in the system include directories (e.g. /usr/include, /usr/local/include, ~/.local/include),

it should be found when using <json.hpp>.

If it is not installed in any system directory, you can add the following in the scratches CMakeLists.txt

include_directories(/path/to/the/directory/containing/json.hpp)

The other option is the one mentioned by Tommaso. 

Use quotes and the complete path to the header.

If it is in the scratch folder, just json.hpp. If on a different path, use the absolute (better) or relative path.

[Jiwoong Lee]

On Monday, May 23, 2022 at 1:16:20 AM UTC-7 tomm...@gmail.com wrote:

This isn't an ns-3 issue, it's more a C++ issue.

On its surface this is a C++ issue. On its depth, the user appears attempting to bring in yet another third party library into one's local setup, and is having a difficulty in integrating that into the ns-3 CMake recipe to make it work.

There, a notion of `system path` is equivocal. None of the C/C++ standard defines what a system path is. While ns-3 uses this notion for well-defined modules, documentation appear to lack for non-blessed, user-originating libraries.

J

[Gabriel Ferreira]

The documentation covers the three ways we use third-party libraries on ns-3. 

Here is the link: https://www.nsnam.org/docs/manual/html/working-with-cmake.html#linking-third-party-libraries

Here is how to use them:

1) Find libraries with CMake's FindPackage()

>find_package(SomeExternalLibrary QUIET) 

>if(${SomeExternalLibrary_FOUND}) 

>include_directories(${SomeExternalLibrary_INCLUDE_DIRS})

>link_libraries(${SomeExternalLibrary_LIBRARIES})

>endif()

2) Find libraries with PkgConfig

>include(FindPkgConfig)

>if(PKG_CONFIG_FOUND)

>pkg_check_modules(EXTERNAL_LIBRARY libexternallibrary)

>endif()

>

>if(PKG_CONFIG_FOUND AND EXTERNAL_LIBRARY_FOUND)

>include_directories(${EXTERNAL_LIBRARY_INCLUDE_DIRS})

>link_libraries(${EXTERNAL_LIBRARY_LIBRARIES})

>endif()

3) For libraries that do not ship CMake package information nor Pkg-config, and using SQLite3 as an example:

>find_external_library( DEPENDENCY_NAME SQLite3 

>                                      HEADER_NAME sqlite3.h 

>                                      LIBRARY_NAME sqlite3 

>                                      SEARCH_PATHS /optional/search/path/to/custom/sqlite3/library)

>if(${SQLite3_FOUND})
>include_directories(${SQLite3_INCLUDE_DIRS})

>link_libraries(${SQLite3_LIBRARIES})
>endif()

The only difference is that in the docs I explain the options with a ton of details. 

And in the code, I prefer to not to use link_libraries(), since it links the library against everything 

in the same directory and subdirectories from the CMakeLists.txt it was called.

If you search in the repository, you are much more likely to find the following 

pattern when the module has an optional feature. 

>set(sqlite_libraries) # list is empty when sqlite3 is not found

>if(${SQLite3_FOUND})
>include_directories(${SQLite3_INCLUDE_DIRS})

>set(sqlite_libraries ${SQLite3_LIBRARIES}) # list has the sqlite3 library when it is found
>endif()

>

>build_lib(

>LIBNAME stats

>...

>LIBRARIES_TO_LINK ${sqlite_libraries} # only links the sqlite3 library if it is found

>)

Which in turn means 

> target_link_libraries(${libstats} PUBLIC ${LIBRARIES_TO_LINK})