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
> -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 ju
On Wed, Feb 18, 2009 at 4:57 PM, Nicholas Yue wrote:
> 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
>>>
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 3:40 PM, Matthew Woehlke
wrote:
> 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(TA
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 do
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 CMake
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
I'm using CMake 2.4-patch 8
I have an issue with duplicate file name
If I have 2 file with the same name in different folder CMake does not process
the second one
Is someone know how I can fix tha or if this issue is fixed in 2.6 version
Thanks
___
Powe
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 varia
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
On Wed, Feb 18, 2009 at 6:52 AM, Bill Hoffman 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")
>>
>> SET(CMAKE_M
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
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
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 and
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 ab
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 tha
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 wrote:
> David Cole wrote:
> > Change this:
> > #FIND_PACKAGE(VTK REQUIRED)
> > #INCLUDE(${VTK_USE_FILE})
> >
> > to this:
>
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
Bill Hoffman wrote:
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"
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 bin
FYI -- conversation continued off list... here's the latest:
-- Forwarded message --
From: David Cole
Date: Wed, Feb 18, 2009 at 11:17 AM
Subject: Re: [CMake] cmake is reruning on rebuild
To: elizabeta petreska
Do your other projects use CMake to generate the solution files? If
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 wrote:
> Hi,
> I developed an applicatio
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, re-r
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 :
add_su
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 i
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 a
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
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 no
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 i
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 executab
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:
bi.
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
On Wed, Feb 18, 2009 at 3:01 AM, Hai Nguyen 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 .LIB files to dis
On Wed, Feb 18, 2009 at 5:31 AM, ankit jain wrote:
> 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.cp
Please review the attached patch for inclusion.
It adds support to the bundle generator to allow customisation of the volume
name and hdiutil compression type used to create the DMG.
--
Mike Arthur
Software Engineer
Mendeley Ltd.
--- Source/CPack/cmCPackBundleGenerator.cxx 22 Jan 2009 18:56:13 -
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 additi
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 addit
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 cas
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 p
40 matches
Mail list logo
