date:20130205

[cmake-developers] [CMake 0013893]: CMAKE_OSX_SYSROOT overwritten to /

2013-02-05 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13893 
== 
Reported By:gnzlbg
Assigned To:
== 
Project:CMake
Issue ID:   13893
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   urgent
Status: new
== 
Date Submitted: 2013-02-05 05:59 EST
Last Modified:  2013-02-05 05:59 EST
== 
Summary:CMAKE_OSX_SYSROOT overwritten to /
Description: 
CMAKE_OSX_SYSROOT is overwritten to / at some point.

Steps to Reproduce: 
When trying to configure Paraview 3.98.0 in Mac OS X 10.8.2 cmake fails. The
following minimal example shows the issue. 

Step 1) Execute:

cmake -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 
-DCMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk

cmake complains instantaneously that the deployment target 10.7 and the SDK
Version 10.8 do not match. Everything fine. 

Step 2) Now execute: 

cmake -DCMAKE_OSX_DEPLOYMENT_TARGET=10.8 
-DCMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk

Configure starts and at some point:

- Checking support for C++ explicit template instantiation
CMake Error at
/usr/local/Cellar/cmake/2.8.10.1/share/cmake/Modules/Platform/Darwin.cmake:190
(message):
  CMAKE_OSX_DEPLOYMENT_TARGET is '10.8' but CMAKE_OSX_SYSROOT:

   /

  is not set to a MacOSX SDK with a recognized version.  Either set
  CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
  empty.
Call Stack (most recent call first):
 
/usr/local/Cellar/cmake/2.8.10.1/share/cmake/Modules/CMakeSystemSpecificInformation.cmake:36
(include)
  CMakeLists.txt:2 (PROJECT)


CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Configuring incomplete, errors occurred!

Somehow CMAKE_OSX_SYSROOT has been overwritten.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-05 05:59 gnzlbg New Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013894]: Ninja generator uses relative paths for source files

2013-02-05 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13894 
== 
Reported By:Mika Fischer
Assigned To:
== 
Project:CMake
Issue ID:   13894
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-05 16:37 EST
Last Modified:  2013-02-05 16:37 EST
== 
Summary:Ninja generator uses relative paths for source files
Description: 
This makes it unnecessarily difficult for tools parsing the generated errors to
find the referenced file. In particular, jumping to error locations in vim only
works when the current directory is the root of the build directory, otherwise
the relative paths in the error messages point to the wrong location.

The Unix Makefile generator uses absolute filenames for source files and thus
does not suffer from this.

If there's not a strong reason for the current behavior, I would suggest to also
use absolute filenames (at least) for source files in the Ninja generator.

A patch that fixes this for me is attached.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-05 16:37 Mika Fischer   New Issue
2013-02-05 16:37 Mika Fischer   File Added: cmake-ninja-absolute-filenames.patch
   
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[CMake] CMake won't find OpenCV properly

2013-02-05 Thread dustXman

Hey there,

I am working on a project with CMake and OpenCV (CUDA and QT too, but that
is another story).
I am trying to get the FIND_PACKAGE (OpenCV REQUIRED) line working, but
unfortunately this line is not exactly working.
Although I pointed  OpenCV_DIR to H:/opencv/build/x86/vc10/lib
(manually) which includes my desired opencv-libs and get a OpenCV_FOUND
the OpenCV_LIBS will point to some files like
H:/opencv/build/lib/opencv_XXX243d.lib. In this folder are not the desired
libs!
I found that this variable is set in OpenCVConfig.cmake and almost copied
from OpenCV_LIBS_DBG and OpenCV_LIBS_OPT where the file path is already
wrong.

But I can't find the point where those variables are set or find the reason
why they are like that!
Some ideas?

dustXman



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/CMake-won-t-find-OpenCV-properly-tp7583103.html
Sent from the CMake mailing list archive at Nabble.com.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Is INSTALL_RPATH Meant to be Relative to CMAKE_INSTALL_PREFIX?

2013-02-05 Thread David Narvaez

Hi all,

I found code that sets LIB_INSTALL_DIR to a relative path (lib or
lib64), then later calls FindKDE4Internal.cmake where
CMAKE_INSTALL_RPATH is set to LIB_INSTALL_DIR and ultimatelysets the
rpath of a library to something containing the relative path lib.
Was that relative path meant to be relative to CMAKE_INSTALL_PREFIX?
It does look like the software in question and FindKDE4Internal.cmake
expect it to be relative to the prefix. I'm attaching a patch that
takes the prefix into account when creating the rpath and solved my
issue of having a relative rpath component.

Thanks in advance for your clarification.

David E. Narváez


_cmake-install_rpath.patch
Description: Binary data
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Compatibility between cmake-based directives and autoconf-based directives

2013-02-05 Thread DRypl

Is there a way how to avoid problems with different declarations of
directives depending whether
using autoconf (for a library) and cmake (for my application using that
library). For example autoconf
declares #define HAVE_UNISTD_H 1 while cmake declares #define
HAVE_UNISTD_H.
Using #cmakedefine01 instead of #cmakedefine does not solve the problem
because statement
#define HAVE_UNISTD_H 0 is apparently something else than #undef
HAVE_UNISTD_H (and the
library is using preprocessing checks as #ifdef HAVE_UNISTD_H). I also did
not find solution in autoconf.
Should the variable be defined using AC_DEFINE statement, I can use
AC_DEFINE(HAVE_UNISTD_H,,),
instead of simple AC_DEFINE(HAVE_UNISTD_H). This will produce #define
HAVE_UNISTD_H (which is compatible with #cmakedefine). The problem is
however, that autoconf configure script for the library relies on
AC_HEADER_STDC (thus not processing explicitly HAVE_UNISTD_H) without a
chance to choose
which version of AC_DEFINE to use.

Is there a way out?

Thanks for help.

Daniel Rypl

--
View this message in context:
http://cmake.3232098.n2.nabble.com/Compatibility-between-cmake-based-directives-and-autoconf-based-directives-tp7583105.html
Sent from the CMake mailing list archive at Nabble.com.
--

41 matches

Mail list logo