Re: [CMake] [Q] LINK_INTERFACE_LIBRARIES and the like
On Tue, 2009-12-22 at 16:22 +0100, Michael Wild wrote:
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
Hi all,
After reading, re-reading, and re-re-reading the manual, I still don't
really get the concept of LINK_INTERFACE_LIBRARIES,
IMPORTED_LINK_DEPENDENT_LIBRARIES, and
IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
does it also apply for Linux?
Best regards,
Marcel Loose.
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override
the set of libraries that appear in the link-interface of one of your own
libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION somewhere)
The created somewhere/${PROJECT_NAME}Dependencies.cmake file will list
bar in the LINK_INTERFACE_LIBRARIES of foo. This property is essentially
a copy of LINK_INTERFACE_LIBRARIES property of foo in the build tree (if it
is defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
implementation details.
HTH
Michael
Hi Michael,
That clarifies things a bit. Maybe I'm just not familiar enough with
import/export of libraries. Could I compare this
somewhere/${PROJECT_NAME}Dependencies.cmake file with the package.pc
file that is generated by pkg-config as a means to record compile and
link flags?
Another question: is it common good practice for a CMake-project to
export its public libraries using install(EXPORT...), or would you do
that on a case-to-case basis?
Would there be a use case for LINK_INTERFACE_LIBRARIES within one
project, to relate several libraries within that project?
Best regards,
Marcel Loose.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Q] LINK_INTERFACE_LIBRARIES and the like
On 23. Dec, 2009, at 9:52 , Marcel Loose wrote:
On Tue, 2009-12-22 at 16:22 +0100, Michael Wild wrote:
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
Hi all,
After reading, re-reading, and re-re-reading the manual, I still don't
really get the concept of LINK_INTERFACE_LIBRARIES,
IMPORTED_LINK_DEPENDENT_LIBRARIES, and
IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
does it also apply for Linux?
Best regards,
Marcel Loose.
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override
the set of libraries that appear in the link-interface of one of your own
libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION somewhere)
The created somewhere/${PROJECT_NAME}Dependencies.cmake file will list
bar in the LINK_INTERFACE_LIBRARIES of foo. This property is essentially
a copy of LINK_INTERFACE_LIBRARIES property of foo in the build tree (if
it is defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
implementation details.
HTH
Michael
Hi Michael,
That clarifies things a bit. Maybe I'm just not familiar enough with
import/export of libraries. Could I compare this
somewhere/${PROJECT_NAME}Dependencies.cmake file with the package.pc
file that is generated by pkg-config as a means to record compile and
link flags?
It is similar in that it creates IMPORTED targets and defines the dependencies
of them.
Another question: is it common good practice for a CMake-project to
export its public libraries using install(EXPORT...), or would you do
that on a case-to-case basis?
Mostly this is useful if you need people to link with their own project against
your installed libraries (think boost, VTK and similar). If you create an
application, this isn't that useful, except if that application has a
plugin-interface and you want people to be able to create plugins for the
installed application.
Would there be a use case for LINK_INTERFACE_LIBRARIES within one
project, to relate several libraries within that project?
I use it in my project to prevent static third-party libraries that I build
within my project to show up in the IMPORTED_LINK_INTERFACE_LIBRARIES of the
{PROJECT_NAME}Dependencies.cmake file. This requires however that I wrap the
TARGET_LINK_LIBRARIES command in a custom function which does all the dirty
work.
Best regards,
Marcel Loose.
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Q] LINK_INTERFACE_LIBRARIES and the like
On Wed, 2009-12-23 at 09:59 +0100, Michael Wild wrote:
On 23. Dec, 2009, at 9:52 , Marcel Loose wrote:
On Tue, 2009-12-22 at 16:22 +0100, Michael Wild wrote:
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
Hi all,
After reading, re-reading, and re-re-reading the manual, I still don't
really get the concept of LINK_INTERFACE_LIBRARIES,
IMPORTED_LINK_DEPENDENT_LIBRARIES, and
IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
does it also apply for Linux?
Best regards,
Marcel Loose.
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override
the set of libraries that appear in the link-interface of one of your own
libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION somewhere)
The created somewhere/${PROJECT_NAME}Dependencies.cmake file will list
bar in the LINK_INTERFACE_LIBRARIES of foo. This property is
essentially a copy of LINK_INTERFACE_LIBRARIES property of foo in the
build tree (if it is defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
implementation details.
HTH
Michael
Hi Michael,
That clarifies things a bit. Maybe I'm just not familiar enough with
import/export of libraries. Could I compare this
somewhere/${PROJECT_NAME}Dependencies.cmake file with the package.pc
file that is generated by pkg-config as a means to record compile and
link flags?
It is similar in that it creates IMPORTED targets and defines the
dependencies of them.
Another question: is it common good practice for a CMake-project to
export its public libraries using install(EXPORT...), or would you do
that on a case-to-case basis?
Mostly this is useful if you need people to link with their own project
against your installed libraries (think boost, VTK and similar). If you
create an application, this isn't that useful, except if that application has
a plugin-interface and you want people to be able to create plugins for the
installed application.
Would there be a use case for LINK_INTERFACE_LIBRARIES within one
project, to relate several libraries within that project?
I use it in my project to prevent static third-party libraries that I build
within my project to show up in the IMPORTED_LINK_INTERFACE_LIBRARIES of the
{PROJECT_NAME}Dependencies.cmake file. This requires however that I wrap the
TARGET_LINK_LIBRARIES command in a custom function which does all the dirty
work.
Best regards,
Marcel Loose.
Michael
OK, thanks for the explanation, Michael.
Seems I won't be needing this stuff in the near future, but I'll keep it
in the back of my head.
Best regards,
Marcel Loose.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] [Q] LINK_INTERFACE_LIBRARIES and the like
Hi all, After reading, re-reading, and re-re-reading the manual, I still don't really get the concept of LINK_INTERFACE_LIBRARIES, IMPORTED_LINK_DEPENDENT_LIBRARIES, and IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or does it also apply for Linux? Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Q] LINK_INTERFACE_LIBRARIES and the like
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
Hi all,
After reading, re-reading, and re-re-reading the manual, I still don't
really get the concept of LINK_INTERFACE_LIBRARIES,
IMPORTED_LINK_DEPENDENT_LIBRARIES, and
IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
does it also apply for Linux?
Best regards,
Marcel Loose.
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override the
set of libraries that appear in the link-interface of one of your own libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION somewhere)
The created somewhere/${PROJECT_NAME}Dependencies.cmake file will list bar
in the LINK_INTERFACE_LIBRARIES of foo. This property is essentially a copy
of LINK_INTERFACE_LIBRARIES property of foo in the build tree (if it is
defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
implementation details.
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
