Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to That did it Thanks, Michael. That's exactly what I needed. It's somewhat moot now, but your second suggestion confused me, and I'd like to understand better: As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) Two questions: 1. Does a second invocation override the first invocation? 2. If I remove the VTK libs from this command, wouldn't that leave FeatureViewer with unresolved symbols? Thanks again for your help!! -Chris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Hertling Sent: Tuesday, March 22, 2011 7:30 PM To: cmake@cmake.org Subject: Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design? [my original elided for brevity --CRV] The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver will be linked against each shared library that FeatureViewer is linked against, too. You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to or, in general, to the set of libraries which are still to be linked transitively. As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) in FeatureViewer/CMakeLists.txt to explicitly specify the transitive libraries. Of course, the VTK ones should not appear in these lists. 'hope that helps. Regards, 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 ___ 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] Building a DLL and test driver EXE using CMake -- error by design?
Jc-
Thanks for the suggestions, but it's not clear if your suggestions are general
suggestions, or if they actually address the problem I'm experiencing.
Moreover, the problems that your suggestions claim to solve seem to be problems
that I am not experiencing.
For example, you write:
After being executed, this later one will allow you to include VTK header files
from files associated with FeatureViewer target and targets located in
subdirectories. For example tests.
This is precisely what I *don't* want to do. I want to hide VTK's usage
completely from clients of FeatureViewer. I do not want clients of
FeatureViewer to have to include VTK headers or link against VTK libraries. Of
course, the VTK dlls will be available at runtime for FeatureViewer to load,
but that doesn't affect the client's compilation or linking process.
Also:
Moreover, in your example, it seems the command LINK_DIRECTORIES is missing.
Indeed, you should add the following command before calling
ADD_LIBRARY(FeatureViewer ...):
LINK_DIRECTORIES(${VTK_LIBRARY_DIRS})
What problem does LINK_DIRECTORIES solve? Note that I have no problem
building FeatureViewer: It finds the VTK libraries just fine without
LINK_DIRECTORIES. Again, the TestDriver application builds and runs just fine
if I manually remove the references to vtk*.lib in its project settings.
thanks,
-Chris
Chris
--
Christopher R. Volpe, Ph.D.
Email: cvo...@ara.commailto:cvo...@ara.com
Senior Scientist, Information Exploitation Systems Main Desk:
919-582-3300
Applied Research Associates, Inchttp://www.ara.com/
Direct: 919-582-3380
8537 Six Forks Rd., Suite 6000
Fax : 919-582-3301
Raleigh, NC 27615 Web:
http://www.ara.com/offices/NC.htm
___
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] Building a DLL and test driver EXE using CMake -- error by design?
On 03/23/2011 03:21 PM, Chris Volpe ARA/SED wrote: You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to That did it Thanks, Michael. That's exactly what I needed. It's somewhat moot now, but your second suggestion confused me, and I'd like to understand better: As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) Oops: TARGET_LINK_LIBRARIES(FeatureViewer LINK_INTERFACE_LIBRARIES ...) Two questions: 1. Does a second invocation override the first invocation? 2. If I remove the VTK libs from this command, wouldn't that leave FeatureViewer with unresolved symbols? No, for both questions. Each shared library target has a set of transitive libraries, i.e. libraries other targets are additionally linked against if they are linked against the shared library target. As a default, this set consists of those libraries mentioned in the shared library target's TARGET_LINK_LIBRARIES() command invocation. Nevertheless, if the LINK_INTERFACE_LIBRARIES target property has a defined value, this is used for the set of transitive libraries. Now, TARGET_LINK_LIBRARIES() with the LINK_INTERFACE_LIBRARIES clause just adds the specified libraries to the aforementioned property without an impact on the libraries the target is actually linked against. Hence, a second invocation with LINK_INTERFACE_LIBRARIES clause would affect the TestDriver and further depending targets, but not the FeatureViewer one. Regards, Michael Thanks again for your help!! -Chris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Hertling Sent: Tuesday, March 22, 2011 7:30 PM To: cmake@cmake.org Subject: Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design? [my original elided for brevity --CRV] The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver will be linked against each shared library that FeatureViewer is linked against, too. You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to or, in general, to the set of libraries which are still to be linked transitively. As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) in FeatureViewer/CMakeLists.txt to explicitly specify the transitive libraries. Of course, the VTK ones should not appear in these lists. 'hope that helps. Regards, 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] Building a DLL and test driver EXE using CMake -- error by design?
On 03/23/2011 05:26 PM, Chris Volpe ARA/SED wrote:
Jc-
Thanks for the suggestions, but it's not clear if your suggestions are
general suggestions, or if they actually address the problem I'm
experiencing. Moreover, the problems that your suggestions claim to solve
seem to be problems that I am not experiencing.
[...]
Also:
Moreover, in your example, it seems the command LINK_DIRECTORIES is
missing. Indeed, you should add the following command before calling
ADD_LIBRARY(FeatureViewer ...):
LINK_DIRECTORIES(${VTK_LIBRARY_DIRS})
What problem does LINK_DIRECTORIES solve? Note that I have no problem
building FeatureViewer: It finds the VTK libraries just fine without
LINK_DIRECTORIES. Again, the TestDriver application builds and runs just fine
if I manually remove the references to vtk*.lib in its project settings.
LINK_DIRECTORIES() can be subtly dangerous, see [1], so it should not
be used if it's avoidable. AFAICS, VTK uses imported targets for its
libraries, i.e. with full paths in the libraries' IMPORTED_LOCATION
properties, so there shouldn't be a need to use LINK_DIRECTORIES()
w.r.t. VTK.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33519.html
___
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] Building a DLL and test driver EXE using CMake -- error by design?
Hi Chris,
Try to change the order of the ADD_DUBDIRECTORY.
add_subdirectory(FeatureViewer)
add_subdirectory(TestDriver)
instead of
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
As mentioned in the
dochttp://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_subdirectory:
*The CMakeLists.txt file in the specified source directory will be
processed immediately by CMake before processing in the current input file
continues beyond this command.*
Changing the order of subdirectory will ensure that FeatureViewer dll is
built before TestDriver ...
Jc
On Tue, Mar 22, 2011 at 10:16 AM, Chris Volpe ARA/SED cvo...@ara.comwrote:
I posted this question in the VTK Users mailing list originally, but have
since determined that it is more of a CMake issue than a VTK issue, and the
involvement of VTK is only tangential.
I am trying to set up a source tree which will allow CMake to create a
MSVC++ .sln file that contains the following two projects:
1. A DLL (called “FeatureViewer”) containing a vanilla C++ class
that links against several VTK kits (Graphics, Rendering, and Hybrid).
2. An EXE (called “TestDriver”) that links against the
aforementioned library containing the vanilla C++ class.
I want to deliver the DLL, LIB, and class header file from (1) above (as
well as the dependent VTK DLLs) to a co-worker who has his own application
and wants to use the functionality I’m encapsulating, but he doesn’t want to
“vtk-ify” his build process. The EXE in (2) above is simply my test driver
for (1).
My problem is that the EXE won’t build because the generated project is
spuriously looking for vtk libraries (e.g. vtkGraphics.lib et. al.) at link
time that it doesn’t directly reference, and it doesn’t know where to find
them. The EXE shouldn’t need to know about them because their use is
strictly within the FeatureViewer library. If I go into the EXE project
properties and manually delete the references to vtkGraphics.lib et. al.
from the linker-input-additional-dependencies list, it works.
At first, I thought I was just doing something wrong in my CMakeLists.txt
files, but page 25 of the CMake User’s Guide suggests that this behavior is
by design.
The example given is:
add_library(foo foo.cxx)
target_link_libraries(foo bar)
add_executable(foobar foobar.cxx)
target_link_libraries(foobar foo)
The text below the example states, *“This will link the libraries foo and
bar into the executable foobar even [sic], although only foo was explicitly
linked into foobar. With shared or DLL builds this linking is not always
needed, but the extra linkage is harmless.”*
It seems to me that this extra linkage is not harmless: I don’t want
clients of FeatureViewer to have to know about vtkGraphics.lib et. al., but
CMake is creating a spurious reference.
Can someone provide a work-around?
My CMakeLists.txt files look like this:
Top Level:
CMAKE_MINIMUM_REQUIRED(VERSION 2.4)
IF(COMMAND CMAKE_POLICY)
CMAKE_POLICY(SET CMP0003 NEW)
ENDIF(COMMAND CMAKE_POLICY)
PROJECT(FeatureViewer)
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
FeatureViewer:
SET (FeatureViewer_SRCS
FeatureViewer.cxx
)
IF(NOT VTK_BINARY_DIR)
FIND_PACKAGE(VTK REQUIRED)
IF(NOT VTK_USE_RENDERING)
MESSAGE(FATAL_ERROR Example ${PROJECT_NAME} requires
VTK_USE_RENDERING.)
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
ENDIF(NOT VTK_BINARY_DIR)
ADD_LIBRARY(FeatureViewer SHARED ${FeatureViewer_SRCS})
TARGET_LINK_LIBRARIES(FeatureViewer vtkGraphics vtkRendering vtkHybrid)
TestDriver:
ADD_EXECUTABLE(TestDriver TestDriver.cxx)
TARGET_LINK_LIBRARIES(TestDriver FeatureViewer)
INCLUDE_DIRECTORIES(${FeatureViewer_SOURCE_DIR}/FeatureViewer)
Thanks in advance!!
Chris
--
Christopher R. Volpe,
Ph.D. Email:
cvo...@ara.com
Senior Scientist, Information Exploitation Systems Main Desk:
919-582-3300
Applied Research Associates, Inc http://www.ara.com/
Direct: 919-582-3380
8537 Six Forks Rd., Suite
6000Fax :
919-582-3301
Raleigh, NC 27615 Web:
http://www.ara.com/offices/NC.htm
___
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
--
+1 919 869 8849
___
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:
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
Jc-
I already tried that, which is why I ended up with the ordering I did.
Originally, with FeatureViewer first, I figured CMake would know about the
dependent VTK libraries by the time it got to TestDriver, thereby enabling the
undesired behavior. I then put TestDriver first, hoping that it would generate
a project file to build against FeatureViewer without having gone into the
subdirectory to find out about FeatureViewer's VTK dependencies. But, alas,
clearly it must descend into FeatureViewer anyway before actually generating
the project file for TestDriver in order for it to know where to find the
FeatureViewer library. So, clearly, it must go through a gather all
information pass before it embarks on the generate all project files pass.
So, my options at this point appear to be:
1. Generate the project files, remove the VTK lib dependencies from
TestDriver, and divorce myself from CMake at this point, doing all further
project modifications (e.g. new classes/sources) directly within Visual Studio,
or...
2. Continue working within CMake, and continually remove the VTK lib
dependencies each time I re-run CMake (a pain).
I'm amazed that nobody has ever experienced this problem before. It seems like
a very natural thing to want to do.
Thanks for the quick response.
-Chris
From: Jean-Christophe Fillion-Robin [mailto:jchris.filli...@kitware.com]
Sent: Tuesday, March 22, 2011 2:41 PM
To: Chris Volpe ARA/SED
Cc: cmake@cmake.org
Subject: Re: [CMake] Building a DLL and test driver EXE using CMake -- error by
design?
Hi Chris,
Try to change the order of the ADD_DUBDIRECTORY.
add_subdirectory(FeatureViewer)
add_subdirectory(TestDriver)
instead of
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
As mentioned in the
dochttp://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_subdirectory:
The CMakeLists.txt file in the specified source directory will be processed
immediately by CMake before processing in the current input file continues
beyond this command.
Changing the order of subdirectory will ensure that FeatureViewer dll is built
before TestDriver ...
Jc
On Tue, Mar 22, 2011 at 10:16 AM, Chris Volpe ARA/SED
cvo...@ara.commailto:cvo...@ara.com wrote:
I posted this question in the VTK Users mailing list originally, but have since
determined that it is more of a CMake issue than a VTK issue, and the
involvement of VTK is only tangential.
I am trying to set up a source tree which will allow CMake to create a MSVC++
.sln file that contains the following two projects:
1. A DLL (called FeatureViewer) containing a vanilla C++ class that
links against several VTK kits (Graphics, Rendering, and Hybrid).
2. An EXE (called TestDriver) that links against the aforementioned
library containing the vanilla C++ class.
I want to deliver the DLL, LIB, and class header file from (1) above (as well
as the dependent VTK DLLs) to a co-worker who has his own application and wants
to use the functionality I'm encapsulating, but he doesn't want to vtk-ify
his build process. The EXE in (2) above is simply my test driver for (1).
My problem is that the EXE won't build because the generated project is
spuriously looking for vtk libraries (e.g. vtkGraphics.lib et. al.) at link
time that it doesn't directly reference, and it doesn't know where to find
them. The EXE shouldn't need to know about them because their use is strictly
within the FeatureViewer library. If I go into the EXE project properties and
manually delete the references to vtkGraphics.lib et. al. from the
linker-input-additional-dependencies list, it works.
At first, I thought I was just doing something wrong in my CMakeLists.txt
files, but page 25 of the CMake User's Guide suggests that this behavior is by
design.
The example given is:
add_library(foo foo.cxx)
target_link_libraries(foo bar)
add_executable(foobar foobar.cxx)
target_link_libraries(foobar foo)
The text below the example states, This will link the libraries foo and bar
into the executable foobar even [sic], although only foo was explicitly linked
into foobar. With shared or DLL builds this linking is not always needed, but
the extra linkage is harmless.
It seems to me that this extra linkage is not harmless: I don't want clients of
FeatureViewer to have to know about vtkGraphics.lib et. al., but CMake is
creating a spurious reference.
Can someone provide a work-around?
My CMakeLists.txt files look like this:
Top Level:
CMAKE_MINIMUM_REQUIRED(VERSION 2.4)
IF(COMMAND CMAKE_POLICY)
CMAKE_POLICY(SET CMP0003 NEW)
ENDIF(COMMAND CMAKE_POLICY)
PROJECT(FeatureViewer)
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
FeatureViewer:
SET (FeatureViewer_SRCS
FeatureViewer.cxx
)
IF(NOT VTK_BINARY_DIR)
FIND_PACKAGE(VTK REQUIRED)
IF(NOT VTK_USE_RENDERING)
MESSAGE(FATAL_ERROR Example ${PROJECT_NAME} requires VTK_USE_RENDERING.)
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
ENDIF(NOT
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
Hi,
Instead of using the following structure:
PROJECT_ROOT
| FeatureViewer
| TestDriver
You should use the following one:
PROJECT_ROOT
| FeatureViewer
| TestDriver
The naming convention we use in our different porject is the following:
PROJECT_ROOT
| FeatureViewer
| Testing
| Cpp
Often we also add the extra subdirectory named Cpp, doing so allows the
project to scale nicely in case the project deals with other language like
Python. In that case, we will add a subdirectory named Python.
What motivates the change of the structure ?
Within the directory FeatureViewer, VTK is found and the following command
is executed: INCLUDE(${VTK_USE_FILE})
The variable VTK_USE_FILE points to a file named UseVTK.cmake that will be
included. De facto all CMake command listed in that file will be executed.
Among them, let's note the use of this one:
INCLUDE_DIRECTORIES(${VTK_INCLUDE_DIRS})
After being executed, this later one will allow you to include VTK header
files from files associated with FeatureViewer target and targets located in
subdirectories. For example tests.
Moreover, in your example, it seems the command LINK_DIRECTORIES is
missing. Indeed, you should add the following command before calling
ADD_LIBRARY(FeatureViewer
...):
LINK_DIRECTORIES(${VTK_LIBRARY_DIRS})
To summarize:
Changing the layout associated with the use of LINK_DIRECTORIES will:
- allow unit test to include featureViewer headers that internally
include VTK headers.
- allow the linking of the test with FeatureViewer to work properly since
the corresponding target will be defined in the current scope.
HTH
Jc
On Tue, Mar 22, 2011 at 6:33 PM, Chris Volpe ARA/SED cvo...@ara.com wrote:
Jc-
I already tried that, which is why I ended up with the ordering I did.
Originally, with FeatureViewer first, I figured CMake would “know about” the
dependent VTK libraries by the time it got to TestDriver, thereby enabling
the undesired behavior. I then put TestDriver first, hoping that it would
generate a project file to build against FeatureViewer without having gone
into the subdirectory to find out about FeatureViewer’s VTK dependencies.
But, alas, clearly it must descend into FeatureViewer anyway before actually
generating the project file for TestDriver in order for it to know where to
find the FeatureViewer library. So, clearly, it must go through a “gather
all information” pass before it embarks on the “generate all project files”
pass.
So, my options at this point appear to be:
1. Generate the project files, remove the VTK lib dependencies from
TestDriver, and divorce myself from CMake at this point, doing all further
project modifications (e.g. new classes/sources) directly within Visual
Studio, or…
2. Continue working within CMake, and continually remove the VTK lib
dependencies each time I re-run CMake (a pain).
I’m amazed that nobody has ever experienced this problem before. It seems
like a very natural thing to want to do.
Thanks for the quick response.
-Chris
*From:* Jean-Christophe Fillion-Robin [mailto:jchris.filli...@kitware.com]
*Sent:* Tuesday, March 22, 2011 2:41 PM
*To:* Chris Volpe ARA/SED
*Cc:* cmake@cmake.org
*Subject:* Re: [CMake] Building a DLL and test driver EXE using CMake --
error by design?
Hi Chris,
Try to change the order of the ADD_DUBDIRECTORY.
add_subdirectory(FeatureViewer)
add_subdirectory(TestDriver)
instead of
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
As mentioned in the
dochttp://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_subdirectory:
*The CMakeLists.txt file in the specified source directory will be
processed immediately by CMake before processing in the current input file
continues beyond this command.*
Changing the order of subdirectory will ensure that FeatureViewer dll is
built before TestDriver ...
Jc
On Tue, Mar 22, 2011 at 10:16 AM, Chris Volpe ARA/SED cvo...@ara.com
wrote:
I posted this question in the VTK Users mailing list originally, but have
since determined that it is more of a CMake issue than a VTK issue, and the
involvement of VTK is only tangential.
I am trying to set up a source tree which will allow CMake to create a
MSVC++ .sln file that contains the following two projects:
1. A DLL (called “FeatureViewer”) containing a vanilla C++ class
that links against several VTK kits (Graphics, Rendering, and Hybrid).
2. An EXE (called “TestDriver”) that links against the
aforementioned library containing the vanilla C++ class.
I want to deliver the DLL, LIB, and class header file from (1) above (as
well as the dependent VTK DLLs) to a co-worker who has his own application
and wants to use the functionality I’m encapsulating, but he doesn’t want to
“vtk-ify” his build process. The EXE in (2) above is simply my test driver
for (1).
My
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
On 03/22/2011 03:16 PM, Chris Volpe ARA/SED wrote:
I posted this question in the VTK Users mailing list originally, but have
since determined that it is more of a CMake issue than a VTK issue, and the
involvement of VTK is only tangential.
I am trying to set up a source tree which will allow CMake to create a MSVC++
.sln file that contains the following two projects:
1. A DLL (called FeatureViewer) containing a vanilla C++ class that
links against several VTK kits (Graphics, Rendering, and Hybrid).
2. An EXE (called TestDriver) that links against the aforementioned
library containing the vanilla C++ class.
I want to deliver the DLL, LIB, and class header file from (1) above (as well
as the dependent VTK DLLs) to a co-worker who has his own application and
wants to use the functionality I'm encapsulating, but he doesn't want to
vtk-ify his build process. The EXE in (2) above is simply my test driver
for (1).
My problem is that the EXE won't build because the generated project is
spuriously looking for vtk libraries (e.g. vtkGraphics.lib et. al.) at link
time that it doesn't directly reference, and it doesn't know where to find
them. The EXE shouldn't need to know about them because their use is strictly
within the FeatureViewer library. If I go into the EXE project properties and
manually delete the references to vtkGraphics.lib et. al. from the
linker-input-additional-dependencies list, it works.
At first, I thought I was just doing something wrong in my CMakeLists.txt
files, but page 25 of the CMake User's Guide suggests that this behavior is
by design.
The example given is:
add_library(foo foo.cxx)
target_link_libraries(foo bar)
add_executable(foobar foobar.cxx)
target_link_libraries(foobar foo)
The text below the example states, This will link the libraries foo and bar
into the executable foobar even [sic], although only foo was explicitly
linked into foobar. With shared or DLL builds this linking is not always
needed, but the extra linkage is harmless.
It seems to me that this extra linkage is not harmless: I don't want clients
of FeatureViewer to have to know about vtkGraphics.lib et. al., but CMake is
creating a spurious reference.
Can someone provide a work-around?
My CMakeLists.txt files look like this:
Top Level:
CMAKE_MINIMUM_REQUIRED(VERSION 2.4)
IF(COMMAND CMAKE_POLICY)
CMAKE_POLICY(SET CMP0003 NEW)
ENDIF(COMMAND CMAKE_POLICY)
PROJECT(FeatureViewer)
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
FeatureViewer:
SET (FeatureViewer_SRCS
FeatureViewer.cxx
)
IF(NOT VTK_BINARY_DIR)
FIND_PACKAGE(VTK REQUIRED)
IF(NOT VTK_USE_RENDERING)
MESSAGE(FATAL_ERROR Example ${PROJECT_NAME} requires VTK_USE_RENDERING.)
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
ENDIF(NOT VTK_BINARY_DIR)
ADD_LIBRARY(FeatureViewer SHARED ${FeatureViewer_SRCS})
TARGET_LINK_LIBRARIES(FeatureViewer vtkGraphics vtkRendering vtkHybrid)
TestDriver:
ADD_EXECUTABLE(TestDriver TestDriver.cxx)
TARGET_LINK_LIBRARIES(TestDriver FeatureViewer)
INCLUDE_DIRECTORIES(${FeatureViewer_SOURCE_DIR}/FeatureViewer)
Thanks in advance!!
Chris
The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver
will be linked against each shared library that FeatureViewer is linked
against, too. You might break this transitivity by explicitly setting
the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to
or, in general, to the set of libraries which are still to be linked
transitively. As an alternative, you might use a second invocation
TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...)
in FeatureViewer/CMakeLists.txt to explicitly specify the transitive
libraries. Of course, the VTK ones should not appear in these lists.
'hope that helps.
Regards,
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
