swig_add_library and include directories
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:
- swig is invoked and a
.cxx
file with the bindings is generated, along with the.py
module. - 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
?