[CMake] INTERFACE library and path to source.

[Eric Noulard]

I did file a bug report then:

https://gitlab.kitware.com/cmake/cmake/issues/17556

2017-12-11 15:12 GMT+01:00 Oleksii Vilchanskyi <
oleksii.vilchanskyi at gmail.com>:

> > 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
>
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171212/4cf88e31/attachment-0001.html>