[CMake] INTERFACE library and path to source.

[Oleksii Vilchanskyi]

> I'm not that sure that this is the "expected" behavior

Yes, now it looks like a bug to me, too. Being written as it was in the
last message,
> target_sources(lib INTERFACE lib.h)
can be treated as the equivalent of
> target_sources(main PRIVATE lib.h)
(and therefore generating an error).

However,
> target_include_directories(lib INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
on the command line resolves to
> -I/home/l2y/<...>/lib
and
> target_include_directories(lib INTERFACE ".")
resolves to
> -I/home/l2y/<...>/lib/.

Also, looking at `<build_dir>/main/CMakeFiles/main.dir/depend.internal`:

> main/CMakeFiles/main.dir/main.c.o
>  ../lib/lib.h
>  /home/l2y/<...>/main/main.c
So, all elements in `target_include_directories()` resolve to full
paths, as well as `target_sources()`, while `target_sources(INTERFACE)`
stay relative, which causes trouble.

On 11.12.2017 09:20, Eric Noulard wrote:
> 
> 
> 2017-12-09 1:37 GMT+01:00 Oleksii Vilchanskyi
> <oleksii.vilchanskyi at gmail.com <mailto:oleksii.vilchanskyi at gmail.com>>:
> 
>     Hello Eric,
> 
>     > Why should I do that?
>     > Is this the expected behavior / way to create header only library?
> 
>     Yes, this is the expected behaviour. CMake interprets a relative path to
>     the file according to the target's add_library() or add_executable()
>     call directory. I will provide a minimal, reproducible example:
> 
> 
> Hi Oleksii,
> 
> Thanks you for the minimal reproducible example.
> I'm bot that sure that this is the "expected" behavior
>  
> 
>     Listfile under `lib`:
> 
>     > add_library(lib INTERFACE)
>     > target_include_directories(lib INTERFACE
>     "${CMAKE_CURRENT_SOURCE_DIR}")
>     > target_sources(lib INTERFACE "lib.h")
> 
> 
> With the previous one would expect that any target linking to this
> interface target
> will be provided with the include directories provided in its interface.
> In your case (and in mine too) this is given with **full path**
>  
> 
> 
>     Listfile under `main`:
> 
>     > add_executable(main "main.c")
>     > target_link_libraries(main PRIVATE lib)
> 
>     Now, let's look at the diagnostics:
> 
>     > CMake Error at main/CMakeLists.txt:1 (add_executable):
>     >   Cannot find source file:
>     >
>     >     lib.h
> 
>     So, the problem occurs when CMake cannot find `lib.h` relatively to
>     `add_executable(main "main.c")` call. Whether it's the expected
>     behaviour is debatable (I personally would prefer CMake to search
>     relatively to `add_library(lib INTERFACE)`), and the documentation is
>     silent on this caveat either, so there's that.
> 
> 
> Yes precisely. This seems to work OK for imported targets but not for
> header-only in-project lib.
>  
> 
> 
>     One way to solve this is to provide a path to `lib.h` relatively to
>     `main` directory, another way is to provide a full path.
> 
> 
> We (you and me) already provide 
>  target_include_directories
> with full path.
> 
> I cannot provide the file themselves with relative path since they may
> be used
> from different place.
> 
> I guess I will open an issue unless someone explain me the rational
> behind that behavior.
> 
> 
> -- 
> Eric

-- 
Regards,
Oleksii Vilchanskyi
PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171211/40be0201/attachment.sig>