Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?

2011-03-23 Thread Michael Hertling 
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?

2011-03-23 Thread Michael Hertling 
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?

2011-03-23 Thread Chris Volpe ARA/SED 
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.com
Senior Scientist, Information Exploitation Systems Main Desk: 
919-582-3300
Applied Research Associates, Inc   
  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?

2011-03-23 Thread Chris Volpe ARA/SED 
> 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?

2011-03-22 Thread Michael Hertling 
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

Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?

2011-03-22 Thread Jean-Christophe Fillion-Robin 
Hi,

Instead of using the following structure:

   | FeatureViewer
   | TestDriver

You should use the following one:

   | FeatureViewer
 | TestDriver

The naming convention we use in our different porject is the following:

   | 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  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 
> doc<http://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 
> 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 th

Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?

2011-03-22 Thread Chris Volpe ARA/SED 
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 
doc<http://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 
mailto: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

Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?

2011-03-22 Thread Jean-Christophe Fillion-Robin 
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
doc:
"*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 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
>
> --
> Christopher R. Volpe,
> Ph.D.   Email:
> cvo...@ara.com
>
> Senior Scientist, Information Exploitation Systems Main Desk:
> 919-582-3300
>
> Applied Research Associates, Inc 
> 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

Vis

[CMake] Building a DLL and test driver EXE using CMake -- error by design?

2011-03-22 Thread Chris Volpe ARA/SED 
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   
  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