Hi,
Is there a way I can point the LIBRARY_OUTPUT_PATH or
LIBRARY_OUTPUT_DIRECTORY using set_target_properties at a specific directory
and not have it create the CMAKE_TYPE subdirectory? I have suffixes on my
DLL and .LIB files to distinguish what they are and I would like them to
just land in a
Hi all,
I have a directory structure with follwoign cmakelist as:
myfold
Cmakelist.txt
subfolder
subfolder
Cmakelists.txt
myfile.cpp
Contents of Cmakelist of subfolder:
add_executable(myfile myfile.cpp)
target_link_libraries(myfile mylib)
add_test(t1 myfile)
t1 is the test
Hi,
I am testing different version of CMake on multiple platform to
ensure my custom modules works fine on all combination.
I find it troublesome to copy my custom module to all the different
../share/cmake-X.Y/Modules directory
Is there an alternative to telling CMake that there are
Hi,
I am testing different version of CMake on multiple platform to
ensure my custom modules works fine on all combination.
I find it troublesome to copy my custom module to all the different
../share/cmake-X.Y/Modules directory
Is there an alternative to telling CMake that there are
On Wed, Feb 18, 2009 at 3:01 AM, Hai Nguyen chaotic...@gmail.com wrote:
Hi,
Is there a way I can point the LIBRARY_OUTPUT_PATH or
LIBRARY_OUTPUT_DIRECTORY using set_target_properties at a specific directory
and not have it create the CMAKE_TYPE subdirectory? I have suffixes on my
DLL and
Hi,
I developed an application, which has many CMakeList, based on VTK. One of
CMakelist files is like the
following,
#FIND_PACKAGE(VTK REQUIRED)
#INCLUDE(${VTK_USE_FILE})
...
TARGET_LINK_LIBRARIES(TetrahedrisationNG
Basics
Graphics2DNG
Graphics3DNG
vtkIO
vtkCommon
Hi,
I have a simple CMakeLists.txt file, in a directory called 'multicast':
cmake_minimum_required(VERSION 2.6)
include_directories(../.. /usr/local/include/boost-1_38)
add_library(spreadx_multicast SHARED Message.cpp MulticastChannel.cpp)
This successfully gives me a 64 bit .so:
Hi everyone
We (http://y60.artcom.de/) have the following problem:
We would like to run our tests in MSVC with multiple build types,
meaning that the RUN_TESTS target should run the tests for the
build type currently selected in the IDE.
However, we obviously need to provide a separate
I've figured it out. I added the following lines into the root
CMakeLists.txt file:
SET(CMAKE_CXX_FLAGS -m64)
SET(CMAKE_C_FLAGS -m64)
SET(CMAKE_EXE_LINKER_FLAGS -m64)
SET(CMAKE_MODULE_LINKER_FLAGS -m64)
SET(CMAKE_SHARED_LINKER_FLAGS -m64)
Could someone point me to where this is in the
Birju Prajapati wrote:
I’ve figured it out. I added the following lines into the root
CMakeLists.txt file:
SET(CMAKE_CXX_FLAGS -m64)
SET(CMAKE_C_FLAGS -m64)
SET(CMAKE_EXE_LINKER_FLAGS -m64)
SET(CMAKE_MODULE_LINKER_FLAGS -m64)
SET(CMAKE_SHARED_LINKER_FLAGS -m64)
That is not the
John Biddiscombe wrote:
I get a lot of these warnings (example below), because in
/usr/lib64 there are symlinks to the libGL files in
/usr/X11R6/lib64
Is there a correct (but still safe) way to make these warnings go away.
There are a lot of them (a couple per plugin - so on screen we get tens
Brad
OK. I'm using 2.6.2 I'll let you know if the problem continues with
2.6.3 or later (won't try it right away because I don't want to force a
rebuild of anything just now - but soon)
Thanks
JB
What version of CMake are you using? CMake is supposed to detect when
the conflicting files
John Biddiscombe wrote:
Brad
OK. I'm using 2.6.2 I'll let you know if the problem continues with
2.6.3 or later (won't try it right away because I don't want to force a
rebuild of anything just now - but soon)
Changing from 2.6.2 to 2.6.3 should not trigger a full rebuild...
However, if
Hello
I have one project say C that is dependent on A ,and A is dependent on B.
in C.cmakelists.txt I am doing the following :
add_subdirectory(../A ${CMAKE_BINARY_DIR})
ADD_LIBRARY(C SHARED
${C_S_SRCS}
)
TARGET_LINK_LIBRARIES(C
A
)
in A cmakelists.txt I am doing the follwing :
Just use Build Solution. Rebuild Solution causes *all* build steps
everywhere to re-run, even when nothing has changed, including the ones that
re-run cmake if a CMakeLists.txt file changes.
If you want to start over entirely (effective Rebuild Solution) then wipe
your binary tree entirely,
Change this:#FIND_PACKAGE(VTK REQUIRED)
#INCLUDE(${VTK_USE_FILE})
to this:
FIND_PACKAGE(VTK REQUIRED)
INCLUDE(${VTK_USE_FILE})
(Remove the comment character # -- those lines are commented out...)
HTH,
David
On Wed, Feb 18, 2009 at 8:26 AM, Yixun Liu enjo...@cs.wm.edu wrote:
Hi,
I
FYI -- conversation continued off list... here's the latest:
-- Forwarded message --
From: David Cole david.c...@kitware.com
Date: Wed, Feb 18, 2009 at 11:17 AM
Subject: Re: [CMake] cmake is reruning on rebuild
To: elizabeta petreska elizabeta.petre...@gmail.com
Do your other
David Cole wrote:
Just use Build Solution. Rebuild Solution causes *all* build steps
everywhere to re-run, even when nothing has changed, including the ones
that re-run cmake if a CMakeLists.txt file changes.
If you want to start over entirely (effective Rebuild Solution) then
wipe your
David Cole wrote:
Change this:
#FIND_PACKAGE(VTK REQUIRED)
#INCLUDE(${VTK_USE_FILE})
to this:
FIND_PACKAGE(VTK REQUIRED)
INCLUDE(${VTK_USE_FILE})
(Remove the comment character # -- those lines are commented out...)
HTH,
David
On Wed, Feb 18, 2009 at 8:26 AM, Yixun Liu
What error do you get if you run cmake without the # on those two lines?
(Copy and paste the output of running cmake please.)
On Wed, Feb 18, 2009 at 11:54 AM, Yixun Liu enjo...@cs.wm.edu wrote:
David Cole wrote:
Change this:
#FIND_PACKAGE(VTK REQUIRED)
#INCLUDE(${VTK_USE_FILE})
to
If I have many executables in the same project (ie same CMakeLists.txt
file), it seems like I shouldn't have to do this:
set(Sources File1.cpp File1.cpp )
ADD_EXECUTABLE(Test1 Test1.cpp ${Sources})
ADD_EXECUTABLE(Test2 Test2.cpp ${Sources})
because it is compiling File1 and File2 twice when
Off the top of my head I think
TARGET_LINK_LIBRARIES(Test1 ${MyLibs})
should be
TARGET_LINK_LIBRARIES(Test1 MyLibs)
Also, I think you need to specify a static library if you want one. It seems
like a static library is what you want in this case.
I wrote this up really quick, and could be wrong
David Doria wrote:
If I have many executables in the same project (ie same CMakeLists.txt
file), it seems like I shouldn't have to do this:
set(Sources File1.cpp File1.cpp )
ADD_EXECUTABLE(Test1 Test1.cpp ${Sources})
ADD_EXECUTABLE(Test2 Test2.cpp ${Sources})
because it is compiling File1
Ah of course! I am just used to doing
ADD_EXECUTABLE(Test1 Test1.cpp ${Sources})
So I guess I wasn't thinking and assumed it would be the same for
libraries, but now MyLibs is an actual thing, not a list of files
like ${Sources} is.
Thanks guys.
David
On Wed, Feb 18, 2009 at 12:46 PM, Bill
For some reason, Visual Studio 2003 is pulling in custom-action
dependent libraries into the EXE.
Looking at the raw visual studio vcproj/sln, there are only 'project
dependency' references, not References ... even then it doesn't even
use the right path to the target.. but that could be due to
On Wed, Feb 18, 2009 at 6:52 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
Birju Prajapati wrote:
I've figured it out. I added the following lines into the root
CMakeLists.txt file:
SET(CMAKE_CXX_FLAGS -m64)
SET(CMAKE_C_FLAGS -m64)
SET(CMAKE_EXE_LINKER_FLAGS -m64)
Aaron Turner wrote:
That is not the preferable way to do this. As it hard codes flags into the
CMake file. The way I would do it is:
export CXXFLAGS=-m64
export CFLAGS=-m64
export LDFLAGS=-m64
cmake ../myproject
If those environment variables are set BEFORE you run cmake, then cmake will
Am Mittwoch 18 Februar 2009 15:52:18 schrieb Bill Hoffman:
That is not the preferable way to do this. As it hard codes flags into
the CMake file. The way I would do it is:
export CXXFLAGS=-m64
export CFLAGS=-m64
export LDFLAGS=-m64
cmake ../myproject
If those environment variables are
No, this isn't create_custom_target- this is a generic target
(non-executable) that should only be built when the user specifies it
explicitly.
Basically, I have a bunch of unit tests (which want to convert to
CTest framework). Each of these tests executes a command and compares
it's output to a
Robert Haines wrote:
Hi,
I am testing different version of CMake on multiple platform to
ensure my custom modules works fine on all combination.
I find it troublesome to copy my custom module to all the different
../share/cmake-X.Y/Modules directory
Is there an alternative to telling
Aaron Turner wrote:
Basically, I'm looking for a way to create a new make target
test_standard and associate create_custom_target()'s to it.
I assume you mean add_custom_target.
Suggestions?
Use add_custom_command(TARGET test_standard [...]) (and also
add_dependencies as needed)? What
When you have the Intel C++ compiler installed over Visual Studio, you can
choose to convert a visual studio project to Intel C++ in the menu.
But I can't figure out how to create a visual studio project which uses the
Intel Compiler/Project System automatically? The problem is that this is
On Wed, Feb 18, 2009 at 4:57 PM, Nicholas Yue yue.nicho...@gmail.comwrote:
Robert Haines wrote:
Hi,
I am testing different version of CMake on multiple platform to
ensure my custom modules works fine on all combination.
I find it troublesome to copy my custom module to all the
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Hendrik Sattler
Sent: 18 February 2009 19:18
To: cmake@cmake.org
Subject: Re: [CMake] 64bit linking on linux
architecture.
Having a 64bit system with a gcc default of -m32 is just a
Am Donnerstag 19 Februar 2009 07:07:27 schrieb Birju Prajapati:
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Hendrik Sattler
Sent: 18 February 2009 19:18
To: cmake@cmake.org
Subject: Re: [CMake] 64bit linking on linux
35 matches
Mail list logo
