GitLab

I have been testing the recently modernized UseSWIG.cmake (current version in master, I believe it hasn't made it to any release yet).

From what I understand about swig, when doing e.g. swig_add_library(moduleName LANGUAGE Python SOURCES somefile.i)

At compile time, there's two things that happen in the following order:

1. swig is invoked and a .cxx file with the bindings is generated, along with the .py module.
2. The C++ compiler is invoked to compile the generated .cxx file into a library

The interface .i files can contain #include directives referencing either other .i files or C/C++ header files.

The problem I am currently having is that target_link_libraries(moduleName PRIVATE someOtherLibrary) will only transitively expose the include directories to the second step (c++ compilation) but not to the first. It does seem like the updated UseSWIG.cmake does provide more options of pointing SWIG in the right direction than the previous one did, namely:

• INCLUDE_DIRECTORIES property set on the .i files
• defining the SWIG_INCLUDE_DIRECTORIES variable
• calling include_directories()

However to cover more complex cases of relationships between libraries/modules, these seem to go against the modern use of target_link_libraries to propagate the interface include directories transitively.

For instance, I could have :

add_library(foo SHARED foo.cpp)
target_include_directories(foo
  PUBLIC
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include>
)

and somewhere else (possibly a separate file)

swig_add_library(fooPy.i
        LANGUAGE python
        SOURCES fooPy.i )

target_link_libraries(fooPy PRIVATE foo)

In this scenario I would expect fooPy to be have the interface include directories from foo, and while it does seem to be the case for the C++ compilation step, it is not for the swig step, forcing me to add a property like this:

set_source_files_properties(fooPy.i PROPERTIES 
        CPLUSPLUS ON
        INCLUDE_DIRECTORIES /path/to/wherever/foo/include/files/are/
		)

Something similar would happen if the .i file references other .i files that may be on different folders.

Would it be possible for this logic to be handled in the same way include dirs are typically propagated through target_link_libraries ?