Hi Ankur,
May be you're just missing -devel or -dev pacakges on your system? They
usually provide a symlink from .so to .so.X.Y to allow ld or gcc find the
correct library.
Or do you really have multiple libraries versions installed simultaneously,
each with headers?
On Thu, Mar 10, 2011 at 2:25
On Mon, Mar 7, 2011 at 8:46 PM, Alexander Neundorf
wrote:
> On Friday 04 March 2011, Campbell Barton wrote:
>> On Thu, Mar 3, 2011 at 5:10 PM, Alexander Neundorf
>>
>> wrote:
>> > On Tuesday 01 March 2011, Campbell Barton wrote:
>> >> On Tue, Mar 1, 2011 at 2:47 PM, Marcus D. Hanwell
>> >>
>> >>
Well if the build directory is *in* the source directory, then make
package_source *should* include it.
This is not a problem, but the expected behavior.
If you don't want the build tree in the source tree, then don't put it
there.
On Wed, Mar 9, 2011 at 9:11 PM, Pierre Abbat wrote:
> On Wedn
On Wednesday 09 March 2011 13:09:39 Michael Hertling wrote:
> Could you boil down your project to a minimal but complete example
> which demonstrates the issues with the header not being found and
> the files not being placed properly and post it here?
Here's an example of it compiling correctly,
On 09.03.11 21:36:25, Ankur Handa wrote:
> I'm using find_library to find a library in a given directory but it has
> many different versions of this library listed as libcxcore.so,
> libcxcore.so.2.1 and libcxcore.so.2.1.0 I wrote a very simple cmake file
>
> cmake_minimum_required(VERSION 2.8)
For reference, here's the commit that I just pushed to 'next' :
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=971a735ba2b4d9e4ac846722fdf280dbd0feb0d4
On Wed, Mar 9, 2011 at 6:01 PM, David Cole wrote:
> I'm going to commit this as a fix in CMake 'next' -- but I'm extending it
> to the VS8
I'm going to commit this as a fix in CMake 'next' -- but I'm extending it to
the VS8 and VS9 chunks as well. And I'm eliminating the duplicate use of:
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0;InstallDir]/../../VC/redist"
as one of the PATHS and just going with:
"${msvc_in
Hi everyone,
I'm using find_library to find a library in a given directory but it has
many different versions of this library listed as libcxcore.so,
libcxcore.so.2.1 and libcxcore.so.2.1.0 I wrote a very simple cmake file
cmake_minimum_required(VERSION 2.8)
find_library(OpenCV_LIBRARY_RELEASE
On Wed, Mar 9, 2011 at 11:56 AM, David Cole wrote:
> This is already at least partially fixed in CMake 2.8.4...
Ya I saw that - thought I was working against 2.8.4 until I got to the
next box... so I started checking again...
> Are there still problems building/using 64-bit CMake using the offic
Good point, Dave P...
Kent, are you changing GIT_TAG argument values when this happens? If so,
this explains it entirely, and this is the known bug that Dave P. has
pointed to.
If not, we need to figure out why the download step is re-running when it
shouldn't.
Thanks,
David C.
On Wed, Mar 9,
http://cmake.org/Bug/view.php?id=11403
On Wed, Mar 9, 2011 at 2:50 PM, kent williams wrote:
> I've been running into this every since we updated to CMake 2.8.4, but
> I don't know if it's revision specific.
>
> Sometimes if I change CMakeLists.txt in various directories so that
> make will re-run
I only know about problems with this w.r.t. Visual Studio 10, as reported
just the other day here:
http://www.cmake.org/pipermail/cmake/2011-March/043205.html
http://public.kitware.com/Bug/view.php?id=11927
Are you using VS 10? Or something else?
You can always write a custom DOWNLOAD_COMMAN
Le mercredi 09 mars 2011 à 12:57 -0500, David Cole a écrit :
> Rather than building it from source, you could simply download the
> pre-built binaries for the Mac. They work on 10.4.
Thanks for the hint; I have to make that work with the VisIt
installation process - using 2.8.3 right now.
>
> O
This is already at least partially fixed in CMake 2.8.4...
The chunk you reference:
IF(CMAKE_CL_64)
SET(CMAKE_MSVC_ARCH amd64)
ELSE(CMAKE_CL_64)
SET(CMAKE_MSVC_ARCH x86)
ENDIF(CMAKE_CL_64)
Now looks like this:
IF(CMAKE_CL_64)
IF(MSVC_VERSION GREATER 1599)
# VS 10 and later:
I compile using gcc:
<<
mac:~/temp/cmake-2.8.4 cessenat$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5363)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCH
Le mercredi 09 mars 2011 à 12:56 -0500, David Cole a écrit :
> How did you configure it? With a previous successful build of CMake or
> with ./bootstrap or ./configure?
I tried both with cmake-2.8.0. and with
./bootstrap; make
>
> On Wed, Mar 9, 2011 at 12:38 PM, Olivier Cessenat
> wrote:
>
I've been running into this every since we updated to CMake 2.8.4, but
I don't know if it's revision specific.
Sometimes if I change CMakeLists.txt in various directories so that
make will re-run cmake to pickup CMakeLists.txt changes, it triggers
re-downloading VTK & ITK from scratch.
Is using G
In InstallRequiredSystemLibraries
IF(CMAKE_CL_64)
SET(CMAKE_MSVC_ARCH amd64)
ELSE(CMAKE_CL_64)
SET(CMAKE_MSVC_ARCH x86)
ENDIF(CMAKE_CL_64)
amd64 should be x64 for vs2010
SET(CMAKE_MSVC_ARCH x64)
If cmake is built as 64bit this won't work
FIND_PATH(MS
On 03/09/2011 07:09 PM, Michael Hertling wrote:
> On 03/09/2011 05:54 PM, Pierre Abbat wrote:
>> On Wednesday 09 March 2011 10:22:50 Michael Wild wrote:
>>> Make the ~/tone12/CMakeLists.txt your main CMake file (i.e. put the
>>> project() command in there and all other commands that apply to the
>>
On Wednesday, March 09, 2011 11:16:46 am Markus Rathgeb wrote:
> Hello!
>
> I am using cmake for cross compiling of several Qt applications.
> To do this with cmake v2.8.4 I have to change the FindQt4.cmake file.
>
> The variables QT_LIBRARY_DIR, QT_HEADERS_DIR, QT_BINARY_DIR (...) will
> already
Hello!
I am using cmake for cross compiling of several Qt applications.
To do this with cmake v2.8.4 I have to change the FindQt4.cmake file.
The variables QT_LIBRARY_DIR, QT_HEADERS_DIR, QT_BINARY_DIR (...) will
already be prefixed with the CMAKE_FIND_ROOT_PATH variable value.
For cross compilin
On 03/09/2011 05:54 PM, Pierre Abbat wrote:
> On Wednesday 09 March 2011 10:22:50 Michael Wild wrote:
>> Make the ~/tone12/CMakeLists.txt your main CMake file (i.e. put the
>> project() command in there and all other commands that apply to the
>> whole project) and add a "add_subdirectory(src)" cal
Can you start with a clean build tree, and run make VERBOSE=1.
The trouble is happening here:
> Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o
> Linking CXX static library libcmsys.a
> ar: temporary file: No such file or directory
> make[2]: *** [Source/kwsys/libcmsys.a] Error 1
> make[1]
Rather than building it from source, you could simply download the pre-built
binaries for the Mac. They work on 10.4.
On Wed, Mar 9, 2011 at 12:56 PM, David Cole wrote:
> How did you configure it? With a previous successful build of CMake or with
> ./bootstrap or ./configure?
>
>
>
> On Wed, Ma
On Wed, 9 Mar 2011 18:38:52 +0100, Olivier Cessenat said:
>I downloaded cmake-2.8.4 and also cmake-2.8.3 "Unix sources" and tried
>to compile it for Mac OS-X 10.4.
What version of Xcode? Which compiler?
--
Sean McBride, B. Eng
How did you configure it? With a previous successful build of CMake or with
./bootstrap or ./configure?
On Wed, Mar 9, 2011 at 12:38 PM, Olivier Cessenat wrote:
> Hello,
>
> I downloaded cmake-2.8.4 and also cmake-2.8.3 "Unix sources" and tried
> to compile it for Mac OS-X 10.4.
>
> I get the f
Hello,
I downloaded cmake-2.8.4 and also cmake-2.8.3 "Unix sources" and tried
to compile it for Mac OS-X 10.4.
I get the following error:
<<
[ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.o
[ 3%] Building CXX object
Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o
Lin
On Wednesday 09 March 2011 10:22:50 Michael Wild wrote:
> Make the ~/tone12/CMakeLists.txt your main CMake file (i.e. put the
> project() command in there and all other commands that apply to the
> whole project) and add a "add_subdirectory(src)" call, and then call
> CMake with "cmake .." instead.
This is a question for folks at Stack Overflow. Literally. :-)
I'm assuming you mean "_add_library(${name} ${ARGN})"?
The "override and call original with a leading _" is probably not well
documented anywhere. While it's useful on occasion, we do not recommend
using it if there's an alternate tec
Are you doing the "set" call before or after the "project" command?
This long-standing feature request asks to allow customization of the
available configuration types:
http://public.kitware.com/Bug/view.php?id=5811
I am not certain that customizing the list of configuration types works as
expect
On 03/09/2011 04:14 PM, Pierre Abbat wrote:
> On Wednesday 09 March 2011 05:19:42 Johannes Zarl wrote:
>>> configure_file(src/config.h.in config.h)
>>
>> In CMake, use of relative filenames is (mostly) discouraged. A robust
>> way to do this would be to write:
>>
>> configure_file( ${CMAKE_CURRENT_
On Wednesday 09 March 2011 05:19:42 Johannes Zarl wrote:
> > configure_file(src/config.h.in config.h)
>
> In CMake, use of relative filenames is (mostly) discouraged. A robust
> way to do this would be to write:
>
> configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/src/config.h.in
> ${CMA
Hi everyone,
I just ran into an infinite loop in CMake. The cause is that I used function
overrides in two locations in my CMake tree.
Is the _function_name() syntax documented somewhere? What is the
expected behavior?
My structure is as follows:
proj1
- CMakeLists.txt
- common_core
proj2
- C
It's all working now. Thank you!
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Tue 3/8/2011 10:52 AM
To: Zou, Di (Cont, ARL/CISD)
Cc: cmake@cmake.org
Subject: Re: [CMake] Question about Project.xml file when using subprojects
You need to postpone calling ctes
No one knows?
2011/3/5 gekso :
> Hello! One more question. I use 2.8.4 and I want to create my own
> configurations for VS projects/solutions and remove defaults.
> I use SET (CMAKE_CONFIGURATION_TYPES
> "release;release_ascii;debug;debug_ascii" CACHE STRING "" FORCE), but
> any time I run cmake -
> configure_file(src/config.h.in config.h)
In CMake, use of relative filenames is (mostly) discouraged. A robust
way to do this would be to write:
configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/src/config.h.in
${CMAKE_CURRENT_BINARY_DIRECTORY}/include/config.h )
include_directorie
36 matches
Mail list logo