Greetings, Sirs,
I would like to have "cmake" and "ctest" executables static (for usage in grid
enviroment).
I tried to compile the newest "cmake-2.8.7.tar.gz" version with
./configure --prefix=/home/ilias/bin/cmake_static LDFLAGS=--static
--disable-shared --enable-static
but still got dyna
Hi,
I'm currently using a combination of the include and file directives to
find and bind optional submodules to one of my projects, but its a bit of a
pain to do.
I was wondering if there was a more cmake-y way of doing this?
Here's what I currently do:
# Optional: build pthreads
cmake_minimum
Hi Sarnath,
Could you create an issue in the tracked where you will describe the
problem, the work around and also attach the configure.bat file ?
I am sure that will be helpful in solving the problem.
If there is already an issue .. could you mention the corresponding #
number ?
Thanks for you
Oops! Found a newer message from you regarding what I need to do on the
patch.. I'll get cracking on that!
Aaron Meadows
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
Sent: Friday, February 03, 2012 8:08 AM
To: david.c..
Catching up on old threads here..
I've gone with Approach 4 below. It was somewhat difficult to achieve, but I
have it working fairly well now. Let me share what I've done: (We are mainly
a visual studio shop, so this is geared toward a multi-config generator)
First off, I'm not using add_te
Hi David,
I know this is a fairly old bug fix by internet standards. I was
delayed from getting any further on it by my day job...
What do I still need to do to get this pushed in? Thanks!
Aaron Meadows
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org]
Hello,
I managed to find a workaround.
Instead of allowing CMAKE to work out the configuration and build of the
external CMAKE project,
I just wrote a batch file (configure.bat) which would invoke "cmake" internally
to generate the makefiles.
After that, I could use "cmake --build" command to
OK, one step forward. The following works as suggested in
http://www.cmake.org/pipermail/cmake/2009-May/029425.html
set(newPath "${Boost_LIBRARY_DIRS};$ENV{PATH}")
string(REPLACE ";" "\\;" newPath "${newPath}")
set_tests_properties(${mod_name} PROPERTIES ENVIRONMENT
"PATH=
Hi,
Does the xcode generator on cmake 2.8.3 allow specifying a different gcc
from the one installed by default?
Upgrading to a newer cmake is not a problem.
Do I set CMAKE_CXX_COMPILER to the gcc46 binary ?
I also have to add some xcode plugin for gcc46, don't I?
MM
--
Powered by www.kitware.
Thanks to everyone for the feedback!
The following does not work, afaics
add_test(NAME ${mod_name} COMMAND ${mod_name})
set_tests_properties(${mod_name} PROPERTIES ENVIRONMENT
"PATH=${Boost_LIBRARY_DIRS};$ENV{PATH}")
Am I doing something stupid?
-Original Message-
From: cmake-boun...
On 02/03/2012 12:43 AM, Andreas Pakulat wrote:
On 02.02.12 18:37:03, Alex Olivas wrote:
I don't know what the issue was, but it's fixed in a later version.
I upgraded from 2.8.2 to 2.8.7 and the problem went away.
So when you say my linker-line is wrong, you mean in the
verbose output there's n
2012/2/3 Oliver kfsone Smith :
> osmith@luciddev:~/pn/WW2/src$ cmake --version
> cmake version 2.8.2
>
> I can't see to get "make package" to generate Debian packages that install
> any place but /usr/bin. (I actually want them in /playnet/ra/bin,
> /playnet/ra/lib and so on)
>
> SET(CPACK_GENERATO
12 matches
Mail list logo
