Interface source paths evaluated relative to dependent library

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Interface source paths evaluated relative to dependent library

Rich T
Hi everyone, I've a question about interface sources.

If you create an interface target A, add some sources via

add_library(A INTERFACE)
target_sources(A INTERFACE some/relative/path)

then link to another library B:

add_library(B)
target_link_libraries(B PRIVATE A)

B will search for those sources relative to its own source directory, not the directory where A is defined. This means B fails to configure with a missing sources error if the targets are in different directories.

If I specify the paths absolutely, B successfully finds the sources. However, A can no longer be exported and neither can the static variant of B by association.

I tried using $<TARGET_PROPERTY:A,SOURCE_DIR> in front of the relative path, however it turns out SOURCE_DIR isn't a whitelisted property for INTERFACE libraries.

Is this behavior intentional, and if so, is there any workaround? (other than defining all targets with interface sources in the same directory as the targets that use them)

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Interface source paths evaluated relative to dependent library

Marc CHEVRIER
You can manage different paths (one for build export and one for install export) by using '$<BUILD_INTERFACE:...>' and '$<INSTALL_INTERFACE:...>'.
'$<BUILD_INTERFACE:...>' accepts absolute paths and '$<INSTALL_INTERFACE:...> expects paths relative to the install prefix (CMAKE_INSTALL_PREFIX variable).
.


Le lun. 25 juin 2018 à 16:23, Rich T <[hidden email]> a écrit :
Hi everyone, I've a question about interface sources.

If you create an interface target A, add some sources via

add_library(A INTERFACE)
target_sources(A INTERFACE some/relative/path)

then link to another library B:

add_library(B)
target_link_libraries(B PRIVATE A)

B will search for those sources relative to its own source directory, not the directory where A is defined. This means B fails to configure with a missing sources error if the targets are in different directories.

If I specify the paths absolutely, B successfully finds the sources. However, A can no longer be exported and neither can the static variant of B by association.

I tried using $<TARGET_PROPERTY:A,SOURCE_DIR> in front of the relative path, however it turns out SOURCE_DIR isn't a whitelisted property for INTERFACE libraries.

Is this behavior intentional, and if so, is there any workaround? (other than defining all targets with interface sources in the same directory as the targets that use them)
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Interface source paths evaluated relative to dependent library

Rich T
Ah, brilliant - I thought I'd tried that, but just gave it another go
following your advice and it worked a charm.
Incidentally, do you know what the rules are around the
BUILD_INTERFACE generator expression and line breaks / list items?
It seems to work fine in target_sources when enclosing multiple
lines/files, but in target_include_directories I need one
BUILD_INTERFACE expression per directory or I get an error.

Thanks again,

Rich

On Mon, Jun 25, 2018 at 3:28 PM, Marc CHEVRIER <[hidden email]> wrote:

> You can manage different paths (one for build export and one for install
> export) by using '$<BUILD_INTERFACE:...>' and '$<INSTALL_INTERFACE:...>'.
> '$<BUILD_INTERFACE:...>' accepts absolute paths and
> '$<INSTALL_INTERFACE:...> expects paths relative to the install prefix
> (CMAKE_INSTALL_PREFIX variable).
> .
>
>
> Le lun. 25 juin 2018 à 16:23, Rich T <[hidden email]> a écrit :
>>
>> Hi everyone, I've a question about interface sources.
>>
>> If you create an interface target A, add some sources via
>>
>> add_library(A INTERFACE)
>> target_sources(A INTERFACE some/relative/path)
>>
>> then link to another library B:
>>
>> add_library(B)
>> target_link_libraries(B PRIVATE A)
>>
>> B will search for those sources relative to its own source directory, not
>> the directory where A is defined. This means B fails to configure with a
>> missing sources error if the targets are in different directories.
>>
>> If I specify the paths absolutely, B successfully finds the sources.
>> However, A can no longer be exported and neither can the static variant of B
>> by association.
>>
>> I tried using $<TARGET_PROPERTY:A,SOURCE_DIR> in front of the relative
>> path, however it turns out SOURCE_DIR isn't a whitelisted property for
>> INTERFACE libraries.
>>
>> Is this behavior intentional, and if so, is there any workaround? (other
>> than defining all targets with interface sources in the same directory as
>> the targets that use them)
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Interface source paths evaluated relative to dependent library

Marc CHEVRIER
Fine.
I am surprised because both commands expects the same thing: a CMake list.
The only touchy point is to ensure that the list separator is correctly passed to the command without early evaluation. For that purpose ensure that the generator expression is passed to the command inside quotes:
target_include_directories(target INTERFACE "$<BUILD_INTERFACE:/to/path1;/to/path2>")



Le lun. 25 juin 2018 à 17:41, Rich T <[hidden email]> a écrit :
Ah, brilliant - I thought I'd tried that, but just gave it another go
following your advice and it worked a charm.
Incidentally, do you know what the rules are around the
BUILD_INTERFACE generator expression and line breaks / list items?
It seems to work fine in target_sources when enclosing multiple
lines/files, but in target_include_directories I need one
BUILD_INTERFACE expression per directory or I get an error.

Thanks again,

Rich

On Mon, Jun 25, 2018 at 3:28 PM, Marc CHEVRIER <[hidden email]> wrote:
> You can manage different paths (one for build export and one for install
> export) by using '$<BUILD_INTERFACE:...>' and '$<INSTALL_INTERFACE:...>'.
> '$<BUILD_INTERFACE:...>' accepts absolute paths and
> '$<INSTALL_INTERFACE:...> expects paths relative to the install prefix
> (CMAKE_INSTALL_PREFIX variable).
> .
>
>
> Le lun. 25 juin 2018 à 16:23, Rich T <[hidden email]> a écrit :
>>
>> Hi everyone, I've a question about interface sources.
>>
>> If you create an interface target A, add some sources via
>>
>> add_library(A INTERFACE)
>> target_sources(A INTERFACE some/relative/path)
>>
>> then link to another library B:
>>
>> add_library(B)
>> target_link_libraries(B PRIVATE A)
>>
>> B will search for those sources relative to its own source directory, not
>> the directory where A is defined. This means B fails to configure with a
>> missing sources error if the targets are in different directories.
>>
>> If I specify the paths absolutely, B successfully finds the sources.
>> However, A can no longer be exported and neither can the static variant of B
>> by association.
>>
>> I tried using $<TARGET_PROPERTY:A,SOURCE_DIR> in front of the relative
>> path, however it turns out SOURCE_DIR isn't a whitelisted property for
>> INTERFACE libraries.
>>
>> Is this behavior intentional, and if so, is there any workaround? (other
>> than defining all targets with interface sources in the same directory as
>> the targets that use them)
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake