siplasplas icon indicating copy to clipboard operation
siplasplas copied to clipboard

Include paths confusion

Open sztomi opened this issue 8 years ago • 3 comments

So I finally managed to integrate siplasplas into a build. I have a source tree that looks like this:

build/
include/
    |--- myenum.hpp
src/
    |--- main.cpp

I'm a bit confused about whether I need to add extra include paths after running siplasplas. When my build invokes siplasplas, it generates the output code into the above structure like this:

build/
    |--- output/
             |--- reflection/
                       |--- include/
                                 |--- myenum.hpp
include/
    |--- myenum.hpp
src/
    |--- main.cpp

So when I run my build it won't compile #include "reflection/myenum.hpp". If I include reflection/include/myenum.hpp it does work. Is this how it's supposed to work or am I doing something wrong? I feel that stripping the first component of the include dir in the generated tree is more intuitive.


I used this release: https://github.com/Manu343726/siplasplas/releases/tag/0.0.2-1 and boostrap.cmake.

main.cpp looks like this:

#include "myenum.hpp"
#include "reflection/myenum.hpp"

int main() {
    myenum e;
}

CMakeLists.txt:

project(ucg)
cmake_minimum_required(VERSION 3.0.0)

set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake")

set(SIPLASPLAS_PACKAGE_URL https://github.com/Manu343726/siplasplas/releases/download/0.0.2-1/siplasplas-master-GNU-6_2_1-Debug-dynamic.tar.gz)
set(SIPLASPLAS_INSTALL_DRLPARSER_DEPENDENCIES ON) # Download DRLparser deps with pip
set(SIPLASPLAS_LIBCLANG_VERSION 3.8.0) # libclang version
set(SIPLASPLAS_DOWNLOAD_LIBCLANG ON) # Download and configure libclang automatically
include(cmake/bootstrap.cmake)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

set(UCG_SRCS src/main.cpp include/myenum.hpp)

add_executable(ucg ${UCG_SRCS})

target_include_directories(ucg PUBLIC include/)
configure_siplasplas_reflection(ucg)

target_link_libraries(ucg ${CONAN_LIBS})

sztomi avatar Dec 16 '16 15:12 sztomi

Hi,

The configure_siplasplas_reflection() function reads the properties of your target to invoke DRLParser with the right arguments (sourcetree root, include dirs, search dirs, blacklist, etc). The behavior is as follows:

  • search dirs: List of directories where DRLParser will search for headers. The CMake script passes the target include dirs here by default, and then DRLParser script discards some paths/files using some criteria (See options below)
  • sourcedir: Full path to the root of your project sourcetree. This is used to ignore any search dir that does not belong to your project (Else you end up parsing the whole stdlibc++, boost, etc). The reflection output is organized as a tree with the same structure of the scanned files in your sourcetree. So, if your project foo is in /home/manu/foo and your headers are in an include/ directory in the sourcetree (/home/manu/foo/include) with a header foo.h, your reflection output tree will have <reflection output root>/<reflection output prefix>/include/foo.h (With your include directives being #include <[reflection output prefix]/include/foo.h>). Note how the reflection output root + the custom prefix replace the sourcetree root. The reflection output root dir is configurable through the SIPLASPLAS_REFLECTION_OUTPUT_DIR cmake variable and the prefix through SIPLASPLAS_REFLECTION_OUTPUT_INCLUDE_PREFIX. The cmake script also manipulates your target so you don't have to add the include path to the reflection output manually. All this paths are available as macros in your C++ code (See here).
  • include dirs: Set of include dirs passed to the libclang compiler invocation. The cmake script passes the above include dirs and the reflection output root path by default.
  • blacklist: Set of potential search dirs that should be ignored. For example, anything from your build/ dir.
  • exclude: Glob pattern to ignore input files.
  • files: Files that must be explicitly processed. For example, a generated header in your buildtree, which may be ignored by previous rules. (See the protobuf serialization example).

There are more options, but I will end up writing a doc page for this :)

Your problem may be fixed by setting your include/ dir as DRLParser sourcedir, but there's currently no option to do that in the cmake function (You can always edit your drlparser.cmake file and change the value passed to the -s option to see what happens). Maybe the right solution is to change the semantics and set an includetree instead of a sourcetree.

If you experiment more problems like this in the future, consider enabling verbose DRLParser processing (SIPLASPLAS_VERBOSE_DRLPARSER cmake variable) to see what's exactly going on.

Manu343726 avatar Dec 18 '16 14:12 Manu343726

Hi again,

I forgot to say that I'm not going to close this until this sourcedir -> includedir semantics are fixed, regardless of your specific issue which I think can be solved with a workaround ;)

Thanks a lot for pointing out this issue.

Manu343726 avatar Dec 19 '16 13:12 Manu343726

Thanks for the very detailed response. I'm going to take a look and see if I can solve my specific problem based on this.

sztomi avatar Dec 19 '16 13:12 sztomi