Re: [CMake] ExternalProject + Patch command

[Johan Björk]

Thanks guys.

I ended up with a different (hack) way:

To recap, my issue was that my patch would be applied twice when
building with multi-configuration generators.

Since I am always building the external project with a release
configuration, the following worked fine to disable the
multi-configuration code for the external project.

   SET(_backup ${CMAKE_CONFIGURATION_TYPES})
   SET(CMAKE_CONFIGURATION_TYPES "" CACHE STRING "" FORCE)
   ExternalProject_Add(foo
   ….
   )
  ExternalProject_Get_Property()
SET(CMAKE_CONFIGURATION_TYPES "${_backup}" CACHE STRING "" FORCE)

/Johan

On Wed, Mar 16, 2011 at 6:26 PM, Luigi Calori  wrote:
> On 16/03/2011 17.37, David Cole wrote:
>>
>> It would be nice (as a future feature addition) to be able to support
>> sharing the download/update/patch/source_dir aspects of an
>> ExternalProject target among multiple configurations and avoid the
>> multiple runs of these things that are exactly the same independent of
>> the config.
>>
>> Until that dream becomes reality, though.
>
> I had once modified the External to include support for 
> #    [SRCSTAMP_DIR dir]          # Directory to store source step timestamps
>
> I still have the file but i unfortunated did not kept it up to date with
> recent mods
>>
>> You could run a script as the PATCH_COMMAND, and put some sort of "has
>> this patch already been applied to this source tree" logic into the
>> script, and only actually do the patch command if not already applied.
>>
>> It's a work-around, and might be ugly, but it should work.
>
> Another way is to split the project in two:
>
> one build the source and the other do the config,build,install like
>
> ExternalProject_Add(
>    ${PACKAGE}-GetSource
>    SOURCE_DIR ${Package_Source_Dir}
>    STAMP_DIR ${Package_Source_Stamp_Dir}
> <--- I set this in a place
> "near" the sources, so can remove the build without re-patch
>    SVN_REPOSITORY 
>    PATCH_COMMAND <- your patch--->
>    UPDATE_COMMAND ""
>    CONFIGURE_COMMAND ""
>    BUILD_COMMAND ""
>    INSTALL_COMMAND ""
> )
>
> if(Package_current_dependencies_effective_line)
>    set( Package_current_dependencies_effective_line
> ${Package_current_dependencies_effective_line} ${PACKAGE}-GetSource)
> else()
>    set(Package_current_dependencies_effective_line DEPENDS
> ${PACKAGE}-GetSource)
> endif()
>
>
>
> ExternalProject_Add(
>    ${PACKAGE}
>    SOURCE_DIR ${Package_Source_Dir}
>    DOWNLOAD_COMMAND "" <--this is
> important
>    BUILD_DIR ..
>   INSTALL_DIR 
>    CMAKE_COMMAND ${CMAKE_COMMAND}
>    CMAKE_ARGS
>        ${Package_std_cmake_args}
>        ${Package_additional_cmake_args}
>    BUILD_COMMAND 
>    INSTALL_COMMAND 
>    ${Package_current_dependencies_effective_line} <
> add ${PACKAGE}-GetSource to your dependencies
>    STEP_TARGETS configure build
>
> )
>
> HTH
>                Luigi
>
>
>>
>> HTH,
>> David
>>
>>
>> On Wed, Mar 16, 2011 at 11:40 AM, Johan Björk  wrote:
>>>
>>> Hi everyone,
>>>
>>>
>>> I'm using an SVN repository and a PATCH command. It seems to work
>>> fine, but when I'm selecting a different build configuration, all
>>> steps will be executed again (as expected), but it results in my patch
>>> being applied twice.
>>>
>>> Any ideas how to work around this?
>>>
>>> My externalProject command for reference:
>>>
>>>    ExternalProject_Add(Breakpad
>>>      SVN_REPOSITORY http://google-breakpad.googlecode.com/svn/trunk/
>>>      UPDATE_COMMAND ""
>>>      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
>>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=${CMAKE_OSX_DEPLOYMENT_TARGET}
>>> -DCMAKE_OSX_ARCHITECTURES:STRING=${CMAKE_OSX_ARCHITECTURES}
>>>      PATCH_COMMAND patch<
>>> ${CMAKE_CURRENT_LIST_DIR}/other/patches/breakpad.patch
>>>    )
>>>
>>> Thanks
>>> /Johan
>>> ___
>>> 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
>>
>>
>
> ___
> 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 

Re: [CMake] Platform tests counts as errors.

[Vladislav Vaintroub]

> -Original Message-
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
> Behalf Of David Cole
> Sent: Dienstag, 22. März 2011 21:09
> To: Óscar Fuentes
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Platform tests counts as errors.
> 
> We theorize that:
> Visual Studio tools detect that they are running as a sub-process in a
> Visual Studio environment and send their output to a named pipe
> instead of stdout.
> 
> If anybody has a pointer to some conclusive proof regarding this
> theory, feel free to send it along.

Back in 2006, Kevin Frei  (C/C++ compiler backend teamlead at that time)
wrote a blog describing how  VS_UNICODE_OUTPUT environment variable works:
http://blogs.msdn.com/b/freik/archive/2006/04/05/569025.aspx 
Your theory appears to be correct, according to this post.

Vladislav 

___
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] Adding directories to XCode Resources

[Darrell Blake]

Currently, I'm adding files to my XCode resources similar to this:

file(GLOB_RECURSE resFiles
  ${CMAKE_SOURCE_DIR}/Res/Images/*
  ${CMAKE_SOURCE_DIR}/Res/Music/*
)

set_source_files_properties(
  ${resFiles}
  PROPERTIES
  MACOSX_PACKAGE_LOCATION Resources
)

add_executable(Project, MACOSX_BUNDLE ${sourceFiles} ${resFiles})

The problem with the above is that it adds any files into the root of
the Resources in XCode. What I'm wanting to do is keep the directory
structure so that in my Resources directory I have directories such as
Images and Music with respective files stored in the correct
directories. I'm sure there'll be an easy way to do this but I'm
having trouble finding out what it is.

Cheers,

Darrell
___
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?

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

[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:
> "*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)

Re: [CMake] how to place all executables in /build/bin directory

[Michael Hertling]

On 03/22/2011 11:33 PM, Jean-Christophe Fillion-Robin wrote:
> Hi Arvind,
> 
> As documented 
> here,
> set the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
> 
> Usually I set this one just after I invoke PROJECT() command.

In fact, these variables have the usual directory scope, so they don't
affect directories entered by ADD_SUBDIRECTORY() before they've been
set. Hence, set CMAKE_RUNTIME_OUTPUT_DIRECTORY before calling the
ADD_SUBDIRECTORY(Exec) command.

Regards,

Michael

> Indeed, as specified
> here,
> EXECUTABLE_OUTPUT_PATH has been deprecated since cmake 2.6.
> 
> Jc
> 
> On Tue, Mar 22, 2011 at 6:12 PM, Arvind Rao  wrote:
> 
>> Hi All,
>>
>> I have what should be a simple issue. I have successfully built a project
>> using CMAKE(out of source build). The executables are all placed in the
>> Project/build/Exec. But I want them placed in Project/build/bin/ instead.
>> Toward this end, I set the EXECUTABLE_OUTPUT_PATH, in the top-level
>> CMakeList file, like so:
>>
>> cmake_minimum_required(VERSION 2.6)
>> project(EXAMPLE)
>>
>> set(CMAKE_CXX_FLAGS "-Wall")
>> add_subdirectory(Exec)
>>
>> set( EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin )
>>
>> The result is that the executables are all placed in /Project/build/Exec,
>> whether Project/build/bin exists or not. Does anyone have ideas?
>>
>> Best wishes,
>> Arvind
___
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] New book shipment / bug tracker

[Lisa Avila]

Kitware is pleased to announce that the VTK Textbook is once again in stock!
You may order it directly through our online store or through
amazon.com(and soon through
amazon.co.uk.) Full details on all our titles can be found here:
http://www.kitware.com/products/books.html.

We are also happy to announce that we've set up a bug tracker for each book
allowing you to submit your feedback to help us improve future editions. You
can access the bug tracker here:
http://public.kitware.com/Bug/my_view_page.php. To submit your issue you'll
need to create an account if you don't already have one (note this is the
same bug tracker used for many of our projects including VTK, ITK, CMake,
and ParaView). When creating a new issue, please select the project "Books"
and use the category to select a specific book. Of course, we are happy to
enter the issue for you if that's easier - just send your feedback to
edi...@kitware.com. You can always find the link to the bug tracker and the
contact email address on the "Feedback" tab for each title on our web site.
___
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?

[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:
 "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 VTK_USE_RENDERING)
  MESSAGE(FATAL_ERROR "Example ${PROJECT_NAME} requires VTK_USE_RENDERING.")
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
ENDIF

Re: [CMake] how to place all executables in /build/bin directory

[Jean-Christophe Fillion-Robin]

Hi Arvind,

As documented 
here,
set the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.

Usually I set this one just after I invoke PROJECT() command.

Indeed, as specified
here,
EXECUTABLE_OUTPUT_PATH has been deprecated since cmake 2.6.

Jc

On Tue, Mar 22, 2011 at 6:12 PM, Arvind Rao  wrote:

> Hi All,
>
> I have what should be a simple issue. I have successfully built a project
> using CMAKE(out of source build). The executables are all placed in the
> Project/build/Exec. But I want them placed in Project/build/bin/ instead.
> Toward this end, I set the EXECUTABLE_OUTPUT_PATH, in the top-level
> CMakeList file, like so:
>
> cmake_minimum_required(VERSION 2.6)
> project(EXAMPLE)
>
> set(CMAKE_CXX_FLAGS "-Wall")
> add_subdirectory(Exec)
>
> set( EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin )
>
> The result is that the executables are all placed in /Project/build/Exec,
> whether Project/build/bin exists or not. Does anyone have ideas?
>
> Best wishes,
> Arvind
>
> ___
> 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: 
http://www.cmake.org/Wiki/CMake_FAQ

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

[CMake] how to place all executables in /build/bin directory

[Arvind Rao]

Hi All,

I have what should be a simple issue. I have successfully built a project
using CMAKE(out of source build). The executables are all placed in the
Project/build/Exec. But I want them placed in Project/build/bin/ instead.
Toward this end, I set the EXECUTABLE_OUTPUT_PATH, in the top-level
CMakeList file, like so:

cmake_minimum_required(VERSION 2.6)
project(EXAMPLE)

set(CMAKE_CXX_FLAGS "-Wall")
add_subdirectory(Exec)

set( EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin )

The result is that the executables are all placed in /Project/build/Exec,
whether Project/build/bin exists or not. Does anyone have ideas?

Best wishes,
Arvind
___
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] cmake cannot find headers and libraries

[bob]

I am using cmake to build stage.  But
cmake is not able to find some dependencies. I have compile *libpng* myself,
so I dont have the pkg-config files. The *pkg_search_module* function is
being used to search that library. Isnt there any option to explicitly
define the library, and include directory path for libpng? Also, it is not
able to find the *playercore *library. It has the pkg-config files in some
location, whose path I have added to the PKG_CONFIG_PATH variable. Does it
have anything to do with pkg-config executable? ( I am using pykg-config
dont know why)


Stage version 4.0.1

Operating system is Windows

Installing Libraries to C:/Program Files (x86)/Stage/lib

Installing Plugins to C:/Program Files (x86)/Stage/lib/Stage-4.0

Build type RELEASE

Checking for libtool

Checking for required libraries...

checking for one of the modules 'libpng'

CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindPkgConfig.cmake:351 (message):

  None of the required 'libpng' found

Call Stack (most recent call first):

  CMakeLists.txt:84 (pkg_search_module)

  * Libpng not detected

Linking to FLTK statically.

  * FLTK version  detected via C:/Users/b0b/Programs/fltk-1.3/
configh.cmake.in

FLTK_CFLAGS =

FLTK_LDFLAGS =

FLTK_LIBS =

Checking for optional libraries...

checking for one of the modules 'playercore>=2.1.0'

  * Player not detected. If Player is installed but not detected, check your
PKG_CONFIG_PATH.

Installation path CMAKE_INSTALL_PREFIX=C:/Program Files (x86)/Stage

Configuring libstage

Looking for Avon

checking for one of the modules 'avon'

checking at 'AVON'

  * Avon not detected. If Avon is installed but not detected, check your
PKG_CONFIG_PATH.
cmake_minimum_required(VERSION 2.4.4)
set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)

if(UNIX AND NOT DEFINED CMAKE_BUILD_TYPE)
  if(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION EQUAL 4)
# workaround CMake 2.4.x bug
set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING
"Choose the type of build, options are:
   None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used)
   Debug
   Release
   RelWithDebInfo
   MinSizeRel.")
  else()
set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING
"Choose the type of build, options are:
   None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used)
   Debug
   Release
   RelWithDebInfo
   MinSizeRel.")
  endif()
endif()

project(libpng C)
enable_testing()

# Copyright (C) 2007-2011 Glenn Randers-Pehrson

# This code is released under the libpng license.
# For conditions of distribution and use, see the disclaimer
# and license in png.h

set(PNGLIB_MAJOR 1)
set(PNGLIB_MINOR 5)
set(PNGLIB_RELEASE 1)
set(PNGLIB_NAME libpng${PNGLIB_MAJOR}${PNGLIB_MINOR})
set(PNGLIB_VERSION ${PNGLIB_MAJOR}.${PNGLIB_MINOR}.${PNGLIB_RELEASE})

# needed packages
find_package(ZLIB REQUIRED)
include_directories(${ZLIB_INCLUDE_DIR})

if(NOT WIN32)
  find_library(M_LIBRARY
NAMES m
PATHS /usr/lib /usr/local/lib
  )
  if(NOT M_LIBRARY)
message(STATUS
  "math library 'libm' not found - floating point support disabled")
  endif()
else()
  # not needed on windows
  set(M_LIBRARY "")
endif()

# COMMAND LINE OPTIONS
if(DEFINED PNG_SHARED)
  option(PNG_SHARED "Build shared lib" ${PNG_SHARED})
else()
  option(PNG_SHARED "Build shared lib" ON)
endif()
if(DEFINED PNG_STATIC)
  option(PNG_STATIC "Build static lib" ${PNG_STATIC})
else()
  option(PNG_STATIC "Build static lib" ON)
endif()

if(MINGW)
  option(PNG_TESTS  "Build pngtest" NO)
else()
  option(PNG_TESTS  "Build pngtest" YES)
endif()

option(PNG_NO_CONSOLE_IO "FIXME" YES)
option(PNG_NO_STDIO  "FIXME" YES)
option(PNG_DEBUG "Build with debug output" NO)
option(PNGARG"FIXME" YES)
#TODO:
# PNG_CONSOLE_IO_SUPPORTED

# maybe needs improving, but currently I don't know when we can enable what :)
set(png_asm_tmp "OFF")
if(NOT WIN32)
  find_program(uname_executable NAMES uname PATHS /bin /usr/bin /usr/local/bin)
  if(uname_executable)
exec_program(${uname_executable}
 ARGS --machine OUTPUT_VARIABLE uname_output)
if("uname_output" MATCHES "^.*i[1-9]86.*$")
  set(png_asm_tmp "ON")
else("uname_output" MATCHES "^.*i[1-9]86.*$")
  set(png_asm_tmp "OFF")
endif("uname_output" MATCHES "^.*i[1-9]86.*$")
  endif(uname_executable)
else()
  # this env var is normally only set on win64
  set(TEXT "ProgramFiles(x86)")
  if("$ENV{${TEXT}}" STREQUAL "")
set(png_asm_tmp "ON")
  endif("$ENV{${TEXT}}" STREQUAL "")
endif()

# SET LIBNAME
set(PNG_LIB_NAME png${PNGLIB_MAJOR}${PNGLIB_MINOR})

# to distinguish between debug and release lib
set(CMAKE_DEBUG_POSTFIX "d")

# Use the prebuilt pnglibconf.h file from the scripts folder
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt
   ${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h)
include_directories(${CMAKE_CURRENT_BINARY_

[CMake] cannot find libraries and headers

[bob]

I have compiled libpng and have the headers and the libraries (both static
and dynamic) in some location. I dont know how to exactly specify the path
where cmake would be able to find them. It uses the pkg_search_module()
function to find libpng. As I have compiled libpng myself, I dont have the
pkg-config files that myay be required. Isnt there anyway to just override
and specify the include and lib dirs expicitly in cmake? Also, for the
playercore I have the pkg-config files but still cmake isnt able to find
cmake. Have added the path to PKG_CONFIG_PATH, and I still get the same
error.

Stage version 4.0.1

Operating system is Windows

Installing Libraries to C:/Program Files (x86)/Stage/lib

Installing Plugins to C:/Program Files (x86)/Stage/lib/Stage-4.0

Build type RELEASE

Checking for libtool

Checking for required libraries...

checking for one of the modules 'libpng'

CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindPkgConfig.cmake:351 (message):

  None of the required 'libpng' found

Call Stack (most recent call first):

  CMakeLists.txt:84 (pkg_search_module)

 * Libpng not detected

Linking to FLTK statically.

  * FLTK version  detected via C:/Users/b0b/Programs/fltk-1.3/
configh.cmake.in

FLTK_CFLAGS =

FLTK_LDFLAGS =

FLTK_LIBS =

Checking for optional libraries...

checking for one of the modules 'playercore>=2.1.0'

  * Player not detected. If Player is installed but not detected, check your
PKG_CONFIG_PATH.

Installation path CMAKE_INSTALL_PREFIX=C:/Program Files (x86)/Stage

Configuring libstage

Looking for Avon

checking for one of the modules 'avon'

checking at 'AVON'

  * Avon not detected. If Avon is installed but not detected, check your
PKG_CONFIG_PATH
PROJECT(Stage)

SET( V_MAJOR 4 )
SET( V_MINOR 0 )
SET( V_BUGFIX 1 )

SET( VERSION ${V_MAJOR}.${V_MINOR}.${V_BUGFIX} )
SET( APIVERSION ${V_MAJOR}.${V_MINOR} )

# minimum version of Player to build the plugin
SET( MIN_PLAYER 2.1.0 )

OPTION (BUILD_PLAYER_PLUGIN "Build Player plugin" ON)
OPTION (BUILD_LSPTEST "Build Player plugin tests" OFF)
OPTION (CPACK_CFG "[release building] generate CPack configuration files" ON)

# todo - this doesn't work yet. Run Stage headless with -g.
# OPTION (BUILD_GUI "Build FLTK-based GUI. If OFF, build a gui-less Stage 
useful e.g. for headless compute clusters." ON ) 

cmake_minimum_required( VERSION 2.4 FATAL_ERROR )

IF (CMAKE_MAJOR_VERSION EQUAL 2 AND NOT CMAKE_MINOR_VERSION LESS 6)
cmake_policy( SET CMP0003 NEW )
cmake_policy( SET CMP0005 OLD )
ENDIF (CMAKE_MAJOR_VERSION EQUAL 2 AND NOT CMAKE_MINOR_VERSION LESS 6)

MESSAGE (STATUS "${PROJECT_NAME} version ${VERSION}")

# Set where to find our internal CMake scripts
SET (PROJECT_CMAKE_DIR ${PROJECT_SOURCE_DIR}/cmake CACHE PATH "Location of 
CMake scripts")
# Determine the operating system in detail
INCLUDE (${PROJECT_CMAKE_DIR}/internal/FindOS.cmake)
INCLUDE (${PROJECT_CMAKE_DIR}/internal/UninstallTarget.cmake)

# Enable -Wall by default unless on Win or Solaris
IF (NOT PROJECT_OS_WIN AND NOT PROJECT_OS_SOLARIS)
# Using -Wall on Windows causes MSVC to produce thousands of warnings in its
# own standard headers, dramatically slowing down the build.
SET (WALL "-Wall " )
ENDIF (NOT PROJECT_OS_WIN AND NOT PROJECT_OS_SOLARIS)

#
# Build type cflags
SET (OPTIMIZE "-O2")
SET (CMAKE_CXX_FLAGS_RELEASE " ${OPTIMIZE} -DNDEBUG ${WALL} " CACHE INTERNAL "C 
Flags for release" FORCE)
SET (CMAKE_CXX_FLAGS_DEBUG "-ggdb  ${WALL} " CACHE INTERNAL "C Flags for debug" 
FORCE)
SET (CMAKE_CXX_FLAGS_PROFILE "  -ggdb -pg ${WALL} " CACHE INTERNAL "C Flags for 
profile" FORCE)

#
# Set the default build type
IF (NOT CMAKE_BUILD_TYPE)
  SET (CMAKE_BUILD_TYPE "release" CACHE STRING 
"Choose the type of build, options are: release (default) debug profile" 
FORCE)
ENDIF (NOT CMAKE_BUILD_TYPE)
STRING(TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)

MESSAGE( STATUS "Build type ${CMAKE_BUILD_TYPE}" )

ENABLE_TESTING()

SET(RGBFILE ${CMAKE_INSTALL_PREFIX}/share/stage/rgb.txt )

# Create the config.h file
# config.h belongs with the source (and not in CMAKE_CURRENT_BINARY_DIR as in 
Brian's original version)
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in 
${CMAKE_CURRENT_SOURCE_DIR}/config.h 
@ONLY)

message( STATUS "Checking for libtool" )
find_path( LTDL_INCLUDE_DIR ltdl.h DOC "Libtool include dir" )
find_library( LTDL_LIB ltdl DOC "Libtool lib" )

include_directories( 
${OPENGL_INCLUDE_DIR}
${LTDL_INCLUDE_DIR}
)

# find the easy modules
include(FindPkgConfig)

MESSAGE( STATUS "Checking for required libraries..." )

SET( INDENT "  * " )

pkg_search_module( LIBPNG REQUIRED libpng )
IF( LIBPNG_FOUND )
#  MESSAGE( STATUS ${INDENT} "Libpng version ${LIBPNG_VERSION} detected at 
${LIBPNG_PREFIX}" )
#  MESSAGE( STATUS "LIBPNG_CFLAGS = ${LIBPNG_CFLAGS}" )
#  MESSAGE( STATUS "LIBP

Re: [CMake] Platform tests counts as errors.

[David Cole]

We theorize that:
Visual Studio tools detect that they are running as a sub-process in a
Visual Studio environment and send their output to a named pipe
instead of stdout.

If anybody has a pointer to some conclusive proof regarding this
theory, feel free to send it along.


On Tue, Mar 22, 2011 at 3:45 PM, Óscar Fuentes  wrote:
> Hello David.
>
> David Cole  writes:
>
>> Oh, one more thing... in order to activate that suppress output in VS
>> chunk of code, you have to turn on the logging feature of
>> ExternalProject.
>>
>> include(ExternalProject)
>> ExternalProject_Add(CxNativeTg
>>  SOURCE_DIR "${FOO_SOURCE_DIR}"
>>  CMAKE_ARGS
>>    -DCMAKE_BUILD_TYPE=Release
>>   LOG_CONFIGURE 1
>> )
>
> (The last line ought to be "LOG_CONFIGURE 0")
>
> Sadly, that macro does too much. I want to build a specific executable
> contained on a big project on a well-known place and be able to run it
> from the main build. ExternalProject wants to build and install the
> whole project. I tried to workaround that by setting BINARY_DIR,
> BUILD_COMMAND and INSTALL_COMMAND, but the macro ignored BINARY_DIR.
>
> The macro silences the errors coming from platform tests using
> execute_process and setting ERROR_VARIABLE. It is not possible to do
> that with custom_command, unless the command is a script that in turn
> uses execute_process.
>
> So why cmake with the VS IDE generator outputs the errors coming from
> platform tests when executed from a custom_command but not when executed
> from the console?
>
> Thanks.
>
___
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?

[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

Re: [CMake] Platform tests counts as errors.

[David Cole]

Oh, one more thing... in order to activate that suppress output in VS
chunk of code, you have to turn on the logging feature of
ExternalProject.

include(ExternalProject)
ExternalProject_Add(CxNativeTg
 SOURCE_DIR "${FOO_SOURCE_DIR}"
 CMAKE_ARGS
   -DCMAKE_BUILD_TYPE=Release
  LOG_CONFIGURE 1
)



On Tue, Mar 22, 2011 at 12:07 PM, David Cole  wrote:
> Have you considered using the ExternalProject module for custom
> commands like this?
>
> It already takes care of some tricky things like this.
>
> In CMake 2.8.4, you'll see occurrences of this in ExternalProject.cmake:
> set(ENV{VS_UNICODE_OUTPUT} \"\")
> (which gets generated inside of scripts run at build time... you
> cannot simply add something like this to your CMakeLists...)
>
> That effectively tells Visual Studio not to display that sort of
> compiler output from sub-processes. It's a completely non-obvious
> solution that might take days or weeks of research to re-discover on
> your own. And it's already accounted for in the custom commands
> generated when using ExternalProject.
>
> Give it a whirl.
>
> Something like this, in your case:
>
> include(ExternalProject)
> ExternalProject_Add(CxNativeTg
>  SOURCE_DIR "${FOO_SOURCE_DIR}"
>  CMAKE_ARGS
>    -DCMAKE_BUILD_TYPE=Release
> )
>
> (That will configure and build as an external project using all custom
> commands. If you don't also want the build step, you can use
> BUILD_COMMAND "" to avoid it...)
>
>
> HTH,
> David
>
>
> On Mon, Mar 21, 2011 at 10:17 PM, Óscar Fuentes  wrote:
>> Consider this custom_command:
>>
>>  add_custom_command(OUTPUT ${CX_NATIVE_TG_DIR}/CMakeCache.txt
>>    COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${FOO_SOURCE_DIR}
>>    WORKING_DIRECTORY ${CX_NATIVE_TG_DIR})
>>
>> When it is executed from a Makefile-based generator, no
>> problem. However, when it is executed from the VS 2008 IDE, failed
>> platform tests are signaled as errors:
>>
>> 2>-- Looking for sys/dir.h
>> 2>CheckIncludeFile.c
>> 2>CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file: 
>> 'sys/dir.h': No such file or directory
>> 2>-- Looking for sys/dir.h - not found
>>
>> At the end, the custom_command is signaled as failed by the IDE because
>> of those "errors".
>>
>> First of all, why
>>
>> 2>CheckIncludeFile.c
>> 2>CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file: 
>> 'sys/dir.h': No such file or directory
>>
>> is shown in the middle of the usual
>>
>> 2>-- Looking for sys/dir.h
>> 2>-- Looking for sys/dir.h - not found
>>
>> ?
>>
>> Second, what can I do so the IDE does not interpret failed platform
>> tests as errors?
>>
>> ___
>> 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] Platform tests counts as errors.

[David Cole]

Have you considered using the ExternalProject module for custom
commands like this?

It already takes care of some tricky things like this.

In CMake 2.8.4, you'll see occurrences of this in ExternalProject.cmake:
set(ENV{VS_UNICODE_OUTPUT} \"\")
(which gets generated inside of scripts run at build time... you
cannot simply add something like this to your CMakeLists...)

That effectively tells Visual Studio not to display that sort of
compiler output from sub-processes. It's a completely non-obvious
solution that might take days or weeks of research to re-discover on
your own. And it's already accounted for in the custom commands
generated when using ExternalProject.

Give it a whirl.

Something like this, in your case:

include(ExternalProject)
ExternalProject_Add(CxNativeTg
  SOURCE_DIR "${FOO_SOURCE_DIR}"
  CMAKE_ARGS
-DCMAKE_BUILD_TYPE=Release
)

(That will configure and build as an external project using all custom
commands. If you don't also want the build step, you can use
BUILD_COMMAND "" to avoid it...)


HTH,
David


On Mon, Mar 21, 2011 at 10:17 PM, Óscar Fuentes  wrote:
> Consider this custom_command:
>
>  add_custom_command(OUTPUT ${CX_NATIVE_TG_DIR}/CMakeCache.txt
>    COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${FOO_SOURCE_DIR}
>    WORKING_DIRECTORY ${CX_NATIVE_TG_DIR})
>
> When it is executed from a Makefile-based generator, no
> problem. However, when it is executed from the VS 2008 IDE, failed
> platform tests are signaled as errors:
>
> 2>-- Looking for sys/dir.h
> 2>CheckIncludeFile.c
> 2>CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file: 
> 'sys/dir.h': No such file or directory
> 2>-- Looking for sys/dir.h - not found
>
> At the end, the custom_command is signaled as failed by the IDE because
> of those "errors".
>
> First of all, why
>
> 2>CheckIncludeFile.c
> 2>CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file: 
> 'sys/dir.h': No such file or directory
>
> is shown in the middle of the usual
>
> 2>-- Looking for sys/dir.h
> 2>-- Looking for sys/dir.h - not found
>
> ?
>
> Second, what can I do so the IDE does not interpret failed platform
> tests as errors?
>
> ___
> 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

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

[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

Re: [CMake] To avoid target_link_libraries magic

[Brad King]

On 03/22/2011 05:27 AM, Valeriy Bykov wrote:
> I want to build all the project statically using certain version of glibc,
> gcc and all other libs I need. They are situated in the folder "builddeps"
> which I can simply checkout on any host and pass it's path to CMake.

The easiest way to ensure a static link is to use a recent CMake nightly build:

  http://www.cmake.org/files/dev/?C=M;O=D

and set this on your targets:

  set_property(TARGET myexe PROPERTY LINK_SEARCH_START_STATIC 1)

Then no -Bdynamic or -Bstatic options will show if you don't give any shared
libraries to target_link_libraries.  This feature will be included in the next
release of CMake.

> SET (CMAKE_EXE_LINKER_FLAGS ...)
> 
> The second is CMake inserts these system libraries in the front of
> libraries therefore link fails.

The CMAKE_EXE_LINKER_FLAGS is not the place to put libraries for the end
of the link line.  It is meant for the beginning to have things like -m64.

> So it's not obvious in which cases transforming will be applied.

When CMake first runs the ABI check it detects which library search directories
appear in the default link line.  Look at CMakeFiles/CMakeCCompiler.cmake to
see them (CMAKE_C_IMPLICIT_LINK_DIRECTORIES).  Libraries in these directories
will not be passed by full path unless you use an imported target.  When you
put -B/some/path in CMAKE_C_FLAGS then this ends up in the detected implicit
list because the front-end converts it to -L/some/path when invoking the linker.

-Brad
___
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] To avoid target_link_libraries magic

[Hendrik Sattler]

Zitat von Valeriy Bykov :

So I'll try to describe all my problems:
I want to build all the project statically using certain version of glibc,
gcc and all other libs I need. They are situated in the folder "builddeps"
which I can simply checkout on any host and pass it's path to CMake.

I set compile option -nostdinc and specify all system and user include
directories explicitly in toolchain file. By this I can be sure that
only headers are used which I want, and no one from host system where
may be its own gcc and glibc too.


You want the --sysroot gcc option.

HS


___
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] To avoid target_link_libraries magic

[Valeriy Bykov]

For now I have fixed build on different hosts by forcing ithe compiler.
But I don't understand why does it work and why lib is passed by full path
now.

On Tue, Mar 22, 2011 at 12:27:10PM +0300, Valeriy Bykov wrote:
> Thanks for explanations.
>
> It is possible to use imported targets for all libraries or
> target properties but it is not convinient because I have
> a lot of targets in my project.
>
> So I'll try to describe all my problems:
> I want to build all the project statically using certain version of glibc,
> gcc and all other libs I need. They are situated in the folder "builddeps"
> which I can simply checkout on any host and pass it's path to CMake.
>
> I set compile option -nostdinc and specify all system and user include
> directories explicitly in toolchain file. By this I can be sure that
> only headers are used which I want, and no one from host system where
> may be its own gcc and glibc too.
>
> I set link option -static. It is enough to build all statically but in
> command line of collect2 I've found the next (paths are shortened for
> convinience):
> .../builddeps/.../collect2 -m elf_x86_64 -static -o 
> ../../../../test_atomic_lock ...builddeps/.../lib64/crt1.o 
> .../builddeps/.../lib64/crti.o 
> .../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o 
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2 
> -L.../builddeps/.../lib/gcc 
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64 
> -L/lib/../lib64 -L/usr/lib/../lib64 
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. 
> CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o 
> .../builddeps/glibc/lib/libpthread.a --start-group -lgcc -lgcc_eh -lc 
> --end-group .../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o 
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o
>
> We can see that startup object files are used from my own gcc, but ld
> itself adds -L options to search libraries paths and then uses -lgcc,
> -lgcc_eh and -lc, so I am afraid that I can link with host system libraries.
>
> Then I try to specify libraries explicitly in toolchain file:
> SET (GCC_DEFAULT_LIBS "-nodefaultlibs ${BUILDDEPS}/gcc45/lib64/libstdc++.a 
> ${BUILDDEPS}/glibc/lib/libm.a --start-group 
> ${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a 
> ${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a 
> ${BUILDDEPS}/glibc/lib/libc.a --end-group 
> ${BUILDDEPS}/glibc/lib/libpthread.a" CACHE STRING "GCC default libs" FORCE)"
> SET (CMAKE_EXE_LINKER_FLAGS "-static ${GCC_DEFAULT_LIBS}" CACHE STRING "Flags 
> used by the linker." FORCE)
>
> But there is two problems as we can see from collect2 options:
> .../builddeps/.../collect2 -m elf_x86_64 -static -o 
> ../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o 
> .../builddeps/.../lib64/crti.o 
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o 
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2 
> -L.../builddeps/.../lib/gcc 
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64 
> -L/lib/../lib64 -L/usr/lib/../lib64 
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. 
> .../builddeps/gcc45/lib64/libstdc++.a .../builddeps/glibc/lib/libm.a 
> .../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a 
> .../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a 
> .../builddeps/glibc/lib/libc.a .../builddeps/glibc/lib/libpthread.a 
> CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o 
> .../builddeps/glibc/lib/libpthread.a 
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o 
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o
>
> The first is that CMake eats "--start-group" and "--end-group".
> The second is CMake inserts these system libraries in the front of
> libraries therefore link fails.
>
> So I avoid this way and simply specify my own LINK_DIRECTORIES to
> ${BUILDDEPS}/glibc/lib, ${BUILDDEPS}/gcc45/lib64 and
> ${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2 in toolchain
> file. Then this -L entries appear in front of those which are added by
> ld and I hope I really uses libraries I need.
>
> But then I have problem with -lpthread, which in ${BUILDDEPS}/glibc/lib
> too... But! By some strange reason ${BUILDDEPS}/glibc/lib/libpthread.a
> turns into -lpthread only when I specify -B${BUILDDEPS}/glibc/lib in
> CMAKE_C_FLAGS. If I don't do it then CMake compiler tests fails on hosts
> without installed system gcc and glibc. But on host with it all works
> file:
> .../builddeps/.../collect2 -m elf_x86_64 -static -o 
> ../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o 
> .../builddeps/.../lib64/crti.o 
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o 
> -L.../builddeps/glibc/lib -L.../builddeps/glibc 
> -L.../builddeps/gcc

Re: [CMake] To avoid target_link_libraries magic

[Valeriy Bykov]

Thanks for explanations.

It is possible to use imported targets for all libraries or
target properties but it is not convinient because I have
a lot of targets in my project.

So I'll try to describe all my problems:
I want to build all the project statically using certain version of glibc,
gcc and all other libs I need. They are situated in the folder "builddeps"
which I can simply checkout on any host and pass it's path to CMake.

I set compile option -nostdinc and specify all system and user include
directories explicitly in toolchain file. By this I can be sure that
only headers are used which I want, and no one from host system where
may be its own gcc and glibc too.

I set link option -static. It is enough to build all statically but in
command line of collect2 I've found the next (paths are shortened for
convinience):
.../builddeps/.../collect2 -m elf_x86_64 -static -o 
../../../../test_atomic_lock ...builddeps/.../lib64/crt1.o 
.../builddeps/.../lib64/crti.o 
.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o 
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2 
-L.../builddeps/.../lib/gcc 
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64 
-L/lib/../lib64 -L/usr/lib/../lib64 
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. 
CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o 
.../builddeps/glibc/lib/libpthread.a --start-group -lgcc -lgcc_eh -lc 
--end-group .../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o 
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o

We can see that startup object files are used from my own gcc, but ld
itself adds -L options to search libraries paths and then uses -lgcc,
-lgcc_eh and -lc, so I am afraid that I can link with host system libraries.

Then I try to specify libraries explicitly in toolchain file:
SET (GCC_DEFAULT_LIBS "-nodefaultlibs ${BUILDDEPS}/gcc45/lib64/libstdc++.a 
${BUILDDEPS}/glibc/lib/libm.a --start-group 
${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a 
${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a 
${BUILDDEPS}/glibc/lib/libc.a --end-group ${BUILDDEPS}/glibc/lib/libpthread.a" 
CACHE STRING "GCC default libs" FORCE)"
SET (CMAKE_EXE_LINKER_FLAGS "-static ${GCC_DEFAULT_LIBS}" CACHE STRING "Flags 
used by the linker." FORCE)

But there is two problems as we can see from collect2 options:
.../builddeps/.../collect2 -m elf_x86_64 -static -o 
../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o 
.../builddeps/.../lib64/crti.o 
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o 
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2 
-L.../builddeps/.../lib/gcc 
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64 
-L/lib/../lib64 -L/usr/lib/../lib64 
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. 
.../builddeps/gcc45/lib64/libstdc++.a .../builddeps/glibc/lib/libm.a 
.../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a 
.../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a 
.../builddeps/glibc/lib/libc.a .../builddeps/glibc/lib/libpthread.a 
CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o 
.../builddeps/glibc/lib/libpthread.a 
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o 
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o

The first is that CMake eats "--start-group" and "--end-group".
The second is CMake inserts these system libraries in the front of
libraries therefore link fails.

So I avoid this way and simply specify my own LINK_DIRECTORIES to
${BUILDDEPS}/glibc/lib, ${BUILDDEPS}/gcc45/lib64 and
${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2 in toolchain
file. Then this -L entries appear in front of those which are added by
ld and I hope I really uses libraries I need.

But then I have problem with -lpthread, which in ${BUILDDEPS}/glibc/lib
too... But! By some strange reason ${BUILDDEPS}/glibc/lib/libpthread.a
turns into -lpthread only when I specify -B${BUILDDEPS}/glibc/lib in
CMAKE_C_FLAGS. If I don't do it then CMake compiler tests fails on hosts
without installed system gcc and glibc. But on host with it all works
file:
.../builddeps/.../collect2 -m elf_x86_64 -static -o 
../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o 
.../builddeps/.../lib64/crti.o 
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o 
-L.../builddeps/glibc/lib -L.../builddeps/glibc 
-L.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2 
-L.../builddeps/gcc45/bin/../lib/gcc 
-L.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64
 -L/lib/../lib64 -L/usr/lib/../lib64 
-L.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. 
CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o 
.../builddeps/glibc/lib/libpthread.a -

Re: [CMake] set_target_properties to target openmp flag on an executable

[Caner Candan]

Perfect as ever. I just replaced the code by:

--
PROJECT(test CXX)
ADD_EXECUTABLE(test test.cpp)
SET_TARGET_PROPERTIES(test PROPERTIES COMPILE_FLAGS "-fopenmp"
LINK_FLAGS "-fopenmp")
--

and it works perfectly.

Thank you guys,
Caner Candan

On Fri, Mar 18, 2011 at 3:20 PM, Eric Noulard  wrote:
> 2011/3/18 Caner Candan :
>> Hi all,
>>
>> Since I have several targets to compile, I was looking for a way to
>> set some specific flags to one target among all others. In my example
>> I would like to set the openmp flag to the target test and I got an
>> error with the code below:
>>
>> --
>> PROJECT(test CXX)
>> ADD_EXECUTABLE(test test.cpp)
>> SET_TARGET_PROPERTIES(test PROPERTIES COMPILE_FLAGS "-fopenmp")
>> --
>>
>> Error:
>> --
>> [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o
>> Linking CXX executable test
>> CMakeFiles/test.dir/test.cpp.o: In function `main':
>> test.cpp:(.text+0x29): undefined reference to `GOMP_parallel_start'
>> test.cpp:(.text+0x3a): undefined reference to `GOMP_parallel_end'
>> collect2: ld returned 1 exit status
>> make[2]: *** [test] Error 1
>> make[1]: *** [CMakeFiles/test.dir/all] Error 2
>
> Don't you need the same flags for linking?
> see the "LINK_FLAGS" property.
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
___
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