Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?

Haroogan wrote: > On 29-Apr-13 23:27, Alexander Neundorf wrote: > > On Monday 29 April 2013, Haroogan wrote: > >> Have a look at my post on StackOverflow > >> > >> >> so > >> urces-of-executable-targets> for details. > >> <

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

Ya; additional generators might be nice 'static runtime' or 'dynamic runtime' but that's only just the C runtime, and doesn't account for the uncounted other libraries you may also depend on. Although I suppose it would make sense that if it was 'static' that all other related things should also b

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

On Tue, Apr 30, 2013 at 1:54 AM, J Decker wrote: > lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX} > or > lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX} > > to choose lib[64]/libc.so or lib[64]/libc.a (or it would

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

hard coded names aren't so bad, since they can be composed of dynamic peices... lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX} or lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX} to choose lib[64]/libc.so or lib[64]

Re: [CMake] "Cannot restore timestamp" error on Windows

> The only race was for multiple processes simultaneously deciding they need to create the (currently missing) file and then trying to open the file for > write at the same time. To what I see on the logs, this is not what I observe: build 26-avr.-2013 13:11:12 CMake does not need to re-ru

Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?

On 29-Apr-13 23:27, Alexander Neundorf wrote: On Monday 29 April 2013, Haroogan wrote: Have a look at my post on StackOverflow for details.

Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?

On Monday 29 April 2013, Haroogan wrote: > On 29-Apr-13 23:27, Alexander Neundorf wrote: > > On Monday 29 April 2013, Haroogan wrote: > >> Have a look at my post on StackOverflow > >> >> -so urces-of-executable-targets> for

Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?

On 29-Apr-13 23:27, Alexander Neundorf wrote: On Monday 29 April 2013, Haroogan wrote: Have a look at my post on StackOverflow for details.

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

On Mon, Apr 29, 2013 at 10:40 PM, Jean-Christophe Fillion-Robin wrote: > For example: > https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 I'm not sure whether I understand this correctly, or whether it is what I want ;) You

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

On Mon, Apr 29, 2013 at 10:36 PM, Alexander Neundorf wrote: > If cmake finds the static version of the library, it should properly use that > one. I thought it would use the shared one per default? > Making cmake find the static version instead of the dynamic version is kind of > hard, AFAIK the

Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?

On Monday 29 April 2013, Haroogan wrote: > Have a look at my post on StackOverflow > urces-of-executable-targets> for details. > urces-of-execu

[CMake] 'AUTOMOC' feature skips sources of executable targets?

Have a look at my post on StackOverflow for details. -- Powered by www.kitware.com Vi

Re: [CMake] Can't get CTEST_CUSTOM_ERROR_MATCH to work with CTest launchers

For reference I have opened a new issue: http://public.kitware.com/Bug/view.php?id=14121 Nils On 04/25/2013 10:00 PM, Nils Gladitz wrote: I was able to reproduce the problem with Ninja on Ubuntu and CMake 2.8.11-rc2. I set up a test project for which I set CTEST_CUSTOM_ERROR_MATCH to "FooBar

Re: [CMake] "Cannot restore timestamp" error on Windows

On 04/29/2013 04:37 PM, Raffi Enficiaud wrote: > - process 1 is accessing generate.stamp for reading Nothing ever reads the file. Only its existence and modification time matter. > - process 2 is moving some "tmpfile" to generate.stamp -> race The only race was for multiple processes simultaneo

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

For example: https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 Hth Jc On Mon, Apr 29, 2013 at 4:36 PM, Alexander Neundorf wrote: > On Monday 29 April 2013, Philippe Cerfon wrote: > > Hi. > > > > I've always thought one o

Re: [CMake] "Cannot restore timestamp" error on Windows

Hi Brad, Thank you for your reply. As you pointed out, the problem seems to come from a race condition on the file "generate.stamp". Now the operations being atomic, the problem should be solved, in practice. However, I do not fully understand in what extent the atomicity of renaming a file woul

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

On Monday 29 April 2013, Philippe Cerfon wrote: > Hi. > > I've always thought one of the main objectives of cmake was being > portable, right? > So I was looking for a way to let the user (i.e. the person building a > project) choose how he wan't to link each external library (i.e. not > the ones

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

On Mon, Apr 29, 2013 at 8:30 PM, Ian Monroe wrote: > Static linking of external libraries is just a weird thing to do. And I thought this wasn’t lkml, where it’s perfectly fine that people, instead of answering the question (if they choose to answer at all) tell you your use case would be invalid

Re: [CMake] CMake 2.8.11-rc3 ready for testing!

On Mon, 2013-04-29 at 14:53 -0400, Robert Maynard wrote: > We found a bug in rc3 and are waiting for the fix to be finalized > before we make rc4. You can track the bug by following the "2.8.11-rc3 > generator expression error" thread. I haven't seen any action on that thread since Thursday... the

Re: [CMake] CMake 2.8.11-rc3 ready for testing!

Hi, We found a bug in rc3 and are waiting for the fix to be finalized before we make rc4. You can track the bug by following the "2.8.11-rc3 generator expression error" thread. On Mon, Apr 29, 2013 at 2:00 PM, Alexander Neundorf wrote: > Hi, > > On Friday 19 April 2013, Robert Maynard wrote: >>

Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen

On Mon, Apr 29, 2013 at 11:13 AM, Philippe Cerfon wrote: > Hi. > > I've always thought one of the main objectives of cmake was being > portable, right? > So I was looking for a way to let the user (i.e. the person building a > project) choose how he wan't to link each external library (i.e. not >

[CMake] portable way of linking (external) libs statically/dynamically/for dlopen

Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib su

Re: [CMake] CMake 2.8.11-rc3 ready for testing!

Hi, On Friday 19 April 2013, Robert Maynard wrote: > The CMake 2.8.11 release candidate continues. This is the last RC > unless a critical, must-fix issue is found. You can find the source > and binaries here: > http://www.cmake.org/files/v2.8/?C=M;O=D what is the current plan, will there be anot

Re: [CMake] "Cannot restore timestamp" error on Windows

On 04/29/2013 10:53 AM, Raffi Enficiaud wrote: > I read the content of the change in the link you provided, and I have a > newbie question: > Why not using one timestamp (different filename) per library/binary/project? The current approach evolved historically. A per-target approach would proba

Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

On Monday 29 April 2013, Glenn Coombs wrote: > I added these lines: > > set_directory_properties( > PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES > "${CMAKE_CURRENT_BINARY_DIR}/abc.txt" > ) > > # check the location where abc.txt is supposed to be deleted from > message("CURRENT_BINARY_DIR: ${CMA

Re: [CMake] FindCUDA fails to find libcuda.so

I have had no problem with Ubuntu 12.10 and Cuda 5; findCuda is able to find cuda in /usr/lib. Can you run CMake --debug-output output enable and see where findCuda is searching? On Mon, Apr 29, 2013 at 11:52 AM, Marcel Loose wrote: > Hi Robert, > > I agree that on the CentOS machine the install

Re: [CMake] FindCUDA fails to find libcuda.so

Hi Robert, I agree that on the CentOS machine the install paths are non-standard. For the Ubuntu system, on the other hand, I have to disagree with that statement. It is a *standard* Ubuntu 12.10 system, so IMHO FindCUDA.cmake should be able to locate libcuda.so on that system. Regards, Marc

Re: [CMake] FindCUDA fails to find libcuda.so

You have a nonstandard install path that will require you to use CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH. On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose wrote: > Hi, > > It fails to find CUDA 5.0. See below. > > $ env | grep CUDA > CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 > CUDA_INC_PA

Re: [CMake] "Cannot restore timestamp" error on Windows

Hi, I read the content of the change in the link you provided, and I have a newbie question: Why not using one timestamp (different filename) per library/binary/project ? Looking forward to having this issue solved in the next official release! Best, Raffi Enficiaud -- View this message in

Re: [CMake] Problem with get_filename_component() and CMAKE_CXX_COMPILER when finding Qt4

Any idea on this? Or should I file a bug report? On Mon, Apr 22, 2013 at 3:15 PM, Petr Kmoch wrote: > If you look at the trace, you'll see the following few lines before the > error: > > C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindQt4.cmake(738): > set(CMAKE_REQUIRED_INCLUDES

Re: [CMake] FindCUDA fails to find libcuda.so

Hi, It fails to find CUDA 5.0. See below. $ env | grep CUDA CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35 CUDA_CACHE_DISABLE=1 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_ROOT=/cm/lo

Re: [CMake] FindCUDA fails to find libcuda.so

Can you provide what Cuda version FindCuda is failing to find, and where Cluster Manager is installing the CUDA toolkit and library? On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose wrote: > Hi all, > > I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two > different platforms: U

[CMake] FindCUDA fails to find libcuda.so

Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it find

Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

I added these lines: set_directory_properties( PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${CMAKE_CURRENT_BINARY_DIR}/abc.txt" ) # check the location where abc.txt is supposed to be deleted from message("CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR}") to the end of my CMakeLists.txt and t

[CMake] Intel compiler with Visual Studio

Hello, we want to use the Visual Studio IDE with the Intel C++ compiler. The Intel compiler integrates neatly with the IDE, you right click on a project or solution and select "use Intel C++" or "use Visual C++" to switch between compilers. I have added the following option to our CMake file: