[cmake-developers] [CMake 0011740]: NMake improperly located

2011-01-21 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11740 == Reported By:Xavier Décoret Assigned To:

[cmake-developers] [CMake 0011746]: CTest test failure outputs should be sorted numerically

2011-01-21 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11746 == Reported By:Sean McBride Assigned To:

[CMake] Defining CDash subprojects in CMakeLists.txt

2011-01-21 Thread Frank Stappers
Hello, Yesterday, I tried to create subprojects from our existing project on our dashboard. So, I've read David Cole's article (Issue 10 - July 2009) and it seems that the labels of a target should match the name of the subproject, and that with the help of a custom-created CTest driver-file the

Re: [CMake] cpack bundle on osx

2011-01-21 Thread Yngve Inntjore Levinsen
Thank you so much for your tips and help Michael! My stupid mistake as you can see it below is that I ran the install target command AFTER the fixup_bundle. Hence the app did not exist in its location when the fixup_bundle ran, but when I checked afterwards it all looked as one would expect.

Re: [CMake] cpack bundle on osx

2011-01-21 Thread Michael Jackson
IS your application a GUI application or an terminal application? If it is really a terminal application then you really should NOT be creating an .app bundle but instead just a plain executable. ___ Mike Jackson

[CMake] Find_package: general question

2011-01-21 Thread Vincent Garcia
Dear CMake users, I have this BIG project which has tons of subdirectories (many levels). In each (final) subdirectory, I create targets (executables and libraires). So I have my top level CMakeLists.txt and one CMakeLists.txt file (which is also a project) in each subdirectory. Everything

Re: [CMake] cpack bundle on osx

2011-01-21 Thread Yngve Inntjore Levinsen
It is a pure terminal application, so you are probably right. However, the old way to install it was that a user had to first install Fink, then wait a few hours for the correct gcc version to be installed with gfortran, then download the correct version of the executable. Or he/she could

[CMake] [New Module] FindEXIF.cmake

2011-01-21 Thread Simone Rossetto
Hello to everyone. I've written the new module FindEXIF.cmake that looks for libexif and I'd like to be the maintainer for this module. Attached to this email the FindEXIF.cmake. It works correctly on GNU/Linux and MacOSX, while on Windows it requires the environment variable EXIF_ROOT_DIR to

Re: [CMake] Restrictions on where a binary can be put?

2011-01-21 Thread Alexander Neundorf
On Friday 21 January 2011, Michael Hertling wrote: On 01/20/2011 07:01 PM, Alexander Neundorf wrote: On Sunday 09 January 2011, Michael Hertling wrote: ... I don't really understand why you want to get the LOCATION from your target, anyway, the get_target_property works fine if you use

Re: [CMake] cpack bundle on osx

2011-01-21 Thread Michael Jackson
With some small modifications to some cmake code you can create a self contained installation with your binary and dependent libraries which is self contained in a folder that can be moved any where. I have a project where I do exactly this. I have my executable installed in

Re: [CMake] [New Module] FindEXIF.cmake

2011-01-21 Thread Michael Jackson
The only thing I might add to it would be something like the following: # Only set EXIF_ROOT_DIR to the environment variable if # the user has not specifically set it as a -D variable # on the command line or in CMake-GUI as a CMake Variable. if (${EXIF_ROOT_DIR} STREQUAL ) SET

Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied

2011-01-21 Thread Aaron_Wright
This is with both 2.8.3 and 2.8.4-rc1. On a side note, VS2010 is not trying to compile the *.res file as part of the executable, because it is marked HEADER_FILE_ONLY, and in addition I can remove it entirely from the project. Instead, even when the *.res file appears no where in the solution

Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied

2011-01-21 Thread David Cole
This is similar in nature to http://public.kitware.com/Bug/view.php?id=11147and friends... The fix for that issue is ending up being obj file specific, though, because we have a special handler in place for files with obj extensions. Perhaps we need similar handling for res files. (They are

[CMake] FILE( MAKE_DIRECTORY path) prepends source path to make directory path.

2011-01-21 Thread John Drescher
I am getting a the following error: CREATING X:/32Bit/VC.90/Qt/StudyManager/bin/Debug/sqldrivers CMake Error at CMake/GetQtRuntime.cmake:21 (file): file problem creating directory: X:/CMakeBased/Qt/StudyManager/X:/32Bit/VC.90/Qt/StudyManager/bin/Debug/sqldrivers Call Stack (most recent call

Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied

2011-01-21 Thread Aaron_Wright
Well, you're probably going to think this is stupid, but the *.res file is not actually a resource file in the Microsoft sense of it. It's just a text file that happens to have the *.res extension. It's a string localization text file that our logging library knows how to read. It think it is

Re: [CMake] FILE( MAKE_DIRECTORY path) prepends source path to make directory path.

2011-01-21 Thread David Cole
You don't need those backslashes there. Try: file( MAKE_DIRECTORY ${EXECUTABLE_OUTPUT_PATH}/${Release}/sqldrivers ) On Fri, Jan 21, 2011 at 11:21 AM, John Drescher dresche...@gmail.com wrote: I am getting a the following error: CREATING X:/32Bit/VC.90/Qt/StudyManager/bin/Debug/sqldrivers

Re: [CMake] FILE( MAKE_DIRECTORY path) prepends source path to make directory path.

2011-01-21 Thread David Cole
(That made it look like you were trying to create a directory with a literal in the name...) On Fri, Jan 21, 2011 at 11:33 AM, David Cole david.c...@kitware.com wrote: You don't need those backslashes there. Try: file( MAKE_DIRECTORY ${EXECUTABLE_OUTPUT_PATH}/${Release}/sqldrivers ) On

Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied

2011-01-21 Thread David Cole
I don't think it's stupid. No judgment here. :-) But can it be renamed, or does this logging library require .res as the file extension? On Fri, Jan 21, 2011 at 11:22 AM, aaron_wri...@selinc.com wrote: Well, you're probably going to think this is stupid, but the *.res file is not actually a

Re: [CMake] FILE( MAKE_DIRECTORY path) prepends source path to make directory path.

2011-01-21 Thread John Drescher
You don't need those backslashes there. Try: file( MAKE_DIRECTORY ${EXECUTABLE_OUTPUT_PATH}/${Release}/sqldrivers ) That solved the issue. The reason for my error (besides the headache that I have at the moment) was that I copied the line from the the next line in the macro which needs to put

Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied

2011-01-21 Thread Aaron_Wright
Ah, I new that would come up. Yeah, they could be renamed. There are only a dozen or so of them. I was just trying to migrate the build system to VS2010 in between projects here at work, and this is the only thing holding me back from a smooth transition. Changing the extension is certainly an

Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied

2011-01-21 Thread David Cole
I'll take a look at the code you sent in your original post and try to see exactly why it's not working. I might not get to it until the end of the day, though. If it worked in VS2008, but not now in VS2010, then we're clearly doing something different in the generators. I'll find out if it's an

Re: [CMake] [New Module] FindEXIF.cmake

2011-01-21 Thread Simone Rossetto
That's good point. Actually on lines 43-45 the variable EXIF_ROOT_DIR is set according to $ENV{EXIF_ROOT_DIR} only if the first header-file of libexif is found in that folder. The same behaviour if the variable EXIF_ROOT_DIR is set with -D option, so if you don't set the env

[Cmake-commits] CMake branch, next, updated. v2.8.3-1463-g585e0ec

2011-01-21 Thread David Cole
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 585e0ec5065496f7508b7f75c6e653faa517c1cd (commit) via

[Cmake-commits] CMake branch, master, updated. v2.8.3-556-gb0fb662

2011-01-21 Thread KWSys Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via b0fb6624cf44c5e6dcc3f8566e9c88e428dce20a (commit) from