[cmake-developers] Test unsuccessful for cmake version 2.8.10.20121108-gc31e1
Hi, running make test on the latest available cmake yields to the following ... Start 12: kwsys.testSystemInformation 13/272 Test #12: kwsys.testSystemInformation ..***Exception: SegFault 0.13 sec ... 99% tests passed, 1 tests failed out of 272 Label Time Summary: Label1= 0.04 sec Label2= 0.04 sec Total Test time (real) = 721.84 sec The following tests FAILED: 12 - kwsys.testSystemInformation (SEGFAULT) Errors while running CTest make: *** [test] Fehler 8 Exit 2 ... The system in ubuntu 12.04, 64-bit. Are there any log-files I should provide? This one ./Tests/SystemInformation/CMakeFiles/CMakeOutput.log is 149568 bytes long and contains 12 entries The output was: 0 The last lines (1355 to 1604) end with ... remove lib [gcc_s] remove lib [gcc] remove lib [gcc_s] remove lib [gcc] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6] == [/usr/lib/gcc/x86_64-linux-gnu/4.6] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu] == [/usr/lib/x86_64-linux-gnu] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib] == [/usr/lib] collapse dir [/lib/x86_64-linux-gnu] == [/lib/x86_64-linux-gnu] collapse dir [/lib/../lib] == [/lib] collapse dir [/usr/lib/x86_64-linux-gnu] == [/usr/lib/x86_64-linux-gnu] collapse dir [/usr/lib/../lib] == [/usr/lib] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6/../../..] == [/usr/lib] implicit libs: [stdc++;m;c] implicit dirs: [/usr/lib/gcc/x86_64-linux-gnu/4.6;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib] ... Regards Kornel signature.asc Description: This is a digitally signed message part. -- 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 0013661]: If CTest terminates via abort() , it displays a message box waiting for user input
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13661 == Reported By:Kay-Uwe (Kiwi) Lorenz Assigned To: == Project:CMake Issue ID: 13661 Category: CTest Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-11-08 06:24 EST Last Modified: 2012-11-08 06:24 EST == Summary:If CTest terminates via abort() , it displays a message box waiting for user input Description: We use ctest in a fully automated non-interactive environment. We now experienced ctest aborting in an unusual way using the abort() system call. This results in a message box waiting for the user pressing OK. This is not the expected behaviour of a non-interactive program. Default behaviour on windows of abort() is to display a message box --- Microsoft Visual C++ Runtime Library --- Runtime Error! Program: C:\Workspace\MyApp\Release\MyApp.exe abnormal program termination --- OK --- And additionally the program exits with status code 3. I would expect ctest only to stop with status code 3 without displaying this annoying msg-box. See http://stackoverflow.com/questions/9718695/how-can-i-supress-all-error-dialogs-when-a-process-crashes-i-only-want-it-to-cr and http://msdn.microsoft.com/en-us/library/e631wekh.aspx for solution. == Issue History Date ModifiedUsername FieldChange == 2012-11-08 06:24 Kay-Uwe (Kiwi) LorenzNew 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
Re: [cmake-developers] Test unsuccessful for cmake version 2.8.10.20121108-gc31e1
Am Donnerstag, 8. November 2012 um 09:47:55, schrieb Kornel Benko kor...@lyx.org Hi, running make test on the latest available cmake yields to the following ... Start 12: kwsys.testSystemInformation 13/272 Test #12: kwsys.testSystemInformation ..***Exception: SegFault 0.13 sec ... 99% tests passed, 1 tests failed out of 272 Label Time Summary: Label1= 0.04 sec Label2= 0.04 sec Total Test time (real) = 721.84 sec The following tests FAILED: 12 - kwsys.testSystemInformation (SEGFAULT) Errors while running CTest make: *** [test] Fehler 8 Exit 2 ... I traced it down to Source/kwsys/SystemInformation.cxx:1327 int fam=ifa-ifa_addr-sa_family; In my case, ifa-ifa_addr happens to be NULL. Changing this line to int fam=-1; if (ifa-ifa_addr) fam=ifa-ifa_addr-sa_family; cures it. Regards Kornel signature.asc Description: This is a digitally signed message part. -- 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
Re: [cmake-developers] Test unsuccessful for cmake version 2.8.10.20121108-gc31e1
On 11/08/2012 06:27 AM, Kornel Benko wrote: 13/272 Test #12: kwsys.testSystemInformation ..***Exception: SegFault 0.13 sec I traced it down to Source/kwsys/SystemInformation.cxx:1327 int fam=ifa-ifa_addr-sa_family; In my case, ifa-ifa_addr happens to be NULL. Thanks for tracking it down. That was introduced in upstream KWSys here: http://public.kitware.com/gitweb?p=KWSys.git;a=commitdiff;h=857bda17 We just updated CMake to use a version of KWSys including this change so it didn't affect us until now. I've proposed a fix upstream: http://review.source.kitware.com/8412 which should make it through to us soon. Thanks, -Brad -- 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 0013662]: Package generation fails on Mac OSX 10.8
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13662 == Reported By:R Wackerbarth Assigned To: == Project:CMake Issue ID: 13662 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-11-08 09:50 EST Last Modified: 2012-11-08 09:50 EST == Summary:Package generation fails on Mac OSX 10.8 Description: Mac OS X 10.8 (Mountain Lion) no longer supports Package Maker Steps to Reproduce: Dashboard test shows failure Additional Information: There is a newer application package generator, productbuild == Issue History Date ModifiedUsername FieldChange == 2012-11-08 09:50 R Wackerbarth 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 0013663]: FindBoost.cmake does not find
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13663 == Reported By:sebp Assigned To: == Project:CMake Issue ID: 13663 Category: (No Category) Reproducibility:have not tried Severity: major Priority: normal Status: new == Date Submitted: 2012-11-08 11:37 EST Last Modified: 2012-11-08 11:37 EST == Summary:FindBoost.cmake does not find Description: FindBoost does not find any libraries. The actual library is e.g. located at /usr/lib64/libboost_program_options-mt.so on Fedora 17 which is not recognized by CMake. Steps to Reproduce: Create a project which needs to link to boost library. Running cmake . -DBoost_DEBUG=TRUE -DBOOST_LIBRARYDIR=/usr/lib64 results in -- [ /usr/share/cmake/Modules/FindBoost.cmake:566 ] _boost_TEST_VERSIONS = 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42 -- [ /usr/share/cmake/Modules/FindBoost.cmake:568 ] Boost_USE_MULTITHREADED = ON -- [ /usr/share/cmake/Modules/FindBoost.cmake:570 ] Boost_USE_STATIC_LIBS = ON -- [ /usr/share/cmake/Modules/FindBoost.cmake:572 ] Boost_USE_STATIC_RUNTIME = OFF -- [ /usr/share/cmake/Modules/FindBoost.cmake:574 ] Boost_ADDITIONAL_VERSIONS = -- [ /usr/share/cmake/Modules/FindBoost.cmake:576 ] Boost_NO_SYSTEM_PATHS = -- [ /usr/share/cmake/Modules/FindBoost.cmake:644 ] Declared as CMake or Environmental Variables: -- [ /usr/share/cmake/Modules/FindBoost.cmake:646 ] BOOST_ROOT = -- [ /usr/share/cmake/Modules/FindBoost.cmake:648 ] BOOST_INCLUDEDIR = -- [ /usr/share/cmake/Modules/FindBoost.cmake:650 ] BOOST_LIBRARYDIR = /usr/lib64 -- [ /usr/share/cmake/Modules/FindBoost.cmake:652 ] _boost_TEST_VERSIONS = 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42 -- [ /usr/share/cmake/Modules/FindBoost.cmake:734 ] location of version.hpp: /usr/include/boost/version.hpp -- [ /usr/share/cmake/Modules/FindBoost.cmake:753 ] version.hpp reveals boost 1.48.0 -- [ /usr/share/cmake/Modules/FindBoost.cmake:785 ] guessed _boost_COMPILER = -gcc47 -- [ /usr/share/cmake/Modules/FindBoost.cmake:795 ] _boost_MULTITHREADED = -mt -- [ /usr/share/cmake/Modules/FindBoost.cmake:838 ] _boost_RELEASE_ABI_TAG = - -- [ /usr/share/cmake/Modules/FindBoost.cmake:840 ] _boost_DEBUG_ABI_TAG = -d -- [ /usr/share/cmake/Modules/FindBoost.cmake:883 ] _boost_LIBRARY_SEARCH_DIRS = /usr/lib64;/usr/include/lib;/usr/include/../lib;/usr/include/stage/lib;C:/boost/lib;C:/boost;/boost/boost_1_48_0/lib;/boost/boost_1_48/lib;/boost/lib;/boost;/sw/local/lib -- [ /usr/share/cmake/Modules/FindBoost.cmake:961 ] Searching for PROGRAM_OPTIONS_LIBRARY_RELEASE: boost_program_options-gcc47-mt-1_48;boost_program_options-gcc47-mt;boost_program_options-mt-1_48;boost_program_options-mt;boost_program_options -- [ /usr/share/cmake/Modules/FindBoost.cmake:993 ] Searching for PROGRAM_OPTIONS_LIBRARY_DEBUG: boost_program_options-gcc47-mt-d-1_48;boost_program_options-gcc47-mt-d;boost_program_options-mt-d-1_48;boost_program_options-mt-d;boost_program_options-mt;boost_program_options -- [ /usr/share/cmake/Modules/FindBoost.cmake:1107 ] Boost_FOUND = FALSE CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:1191 (message): Unable to find the requested Boost libraries. Boost version: 1.48.0 Boost include path: /usr/include The following Boost libraries could not be found: boost_program_options No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:9 (find_package) -- Configuring incomplete, errors occurred! == Issue History Date ModifiedUsername FieldChange == 2012-11-08 11:37 sebp New Issue 2012-11-08 11:37 sebp File Added: boost-example.zip == -- Powered by www.kitware.com Visit other Kitware open-source projects at
[cmake-developers] _PyPopenProcs warning and comment in cmWin32ProcessExecution.cxx
Hi there, http://open.cdash.org/viewBuildError.php?type=1buildid=2652291 has a new warning (as a result of my adding warning flags) of an unused variable. The variable is referenced in a comment. I'm guessing a snippet came from elsewhere. I can remove the _PyPopenProcs variable, but I think the comment should be fixed too at the same time. However, I don't know what the comment should be changed to. Can someone else take over that task? Thanks, Steve. -- 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
Re: [cmake-developers] _PyPopenProcs warning and comment in cmWin32ProcessExecution.cxx
On 11/08/2012 12:44 PM, Stephen Kelly wrote: Hi there, http://open.cdash.org/viewBuildError.php?type=1buildid=2652291 has a new warning (as a result of my adding warning flags) of an unused variable. The variable is referenced in a comment. I'm guessing a snippet came from elsewhere. I can remove the _PyPopenProcs variable, but I think the comment should be fixed too at the same time. However, I don't know what the comment should be changed to. That is an ancient version of the process execution implementation which is only kept for backward compatibility to implement the exec_program() command IIRC. We don't maintain it anymore so the comments don't matter. Just remove the unused variable and its comment. -Brad -- 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
Re: [cmake-developers] _PyPopenProcs warning and comment in cmWin32ProcessExecution.cxx
Brad King wrote:
On 11/08/2012 12:44 PM, Stephen Kelly wrote:
Hi there,
http://open.cdash.org/viewBuildError.php?type=1buildid=2652291
has a new warning (as a result of my adding warning flags) of an unused
variable. The variable is referenced in a comment. I'm guessing a snippet
came from elsewhere.
I can remove the _PyPopenProcs variable, but I think the comment should
be fixed too at the same time. However, I don't know what the comment
should be changed to.
That is an ancient version of the process execution implementation
which is only kept for backward compatibility to implement the
exec_program() command IIRC. We don't maintain it anymore so the
comments don't matter. Just remove the unused variable and its
comment.
If I remove all comments which refer to a _Py* variable, it looks like this:
diff --git a/Source/cmWin32ProcessExecution.cxx
b/Source/cmWin32ProcessExecution.cxx
index 9a536c1..5752ab6 100644
--- a/Source/cmWin32ProcessExecution.cxx
+++ b/Source/cmWin32ProcessExecution.cxx
@@ -271,13 +271,6 @@ bool cmWin32ProcessExecution::Wait(int timeout)
return this-PrivateClose(timeout);
}
-/*
- * Internal dictionary mapping popen* file pointers to process handles,
- * for use when retrieving the process exit code. See _PyPclose() below
- * for more information on this dictionary's use.
- */
-static void *_PyPopenProcs = NULL;
-
static BOOL RealPopenCreateProcess(const char *cmdstring,
const char *path,
const char *szConsoleSpawn,
@@ -679,18 +672,6 @@ bool cmWin32ProcessExecution::PrivateOpen(const char
*cmdstring,
}
}
- /*
- * Insert the files we've created into the process dictionary
- * all referencing the list with the process handle and the
- * initial number of files (see description below in _PyPclose).
- * Since if _PyPclose later tried to wait on a process when all
- * handles weren't closed, it could create a deadlock with the
- * child, we spend some energy here to try to ensure that we
- * either insert all file handles into the dictionary or none
- * at all. It's a little clumsy with the various popen modes
- * and variable number of files involved.
- */
-
/* Child is launched. Close the parents copy of those pipe
* handles that only the child should have open. You need to
* make sure that no handles to the write end of the output pipe
@@ -761,43 +742,6 @@ cmWin32ProcessExecution::~cmWin32ProcessExecution()
this-CloseHandles();
}
-/*
- * Wrapper for fclose() to use for popen* files, so we can retrieve the
- * exit code for the child process and return as a result of the close.
- *
- * This function uses the _PyPopenProcs dictionary in order to map the
- * input file pointer to information about the process that was
- * originally created by the popen* call that created the file pointer.
- * The dictionary uses the file pointer as a key (with one entry
- * inserted for each file returned by the original popen* call) and a
- * single list object as the value for all files from a single call.
- * The list object contains the Win32 process handle at [0], and a file
- * count at [1], which is initialized to the total number of file
- * handles using that list.
- *
- * This function closes whichever handle it is passed, and decrements
- * the file count in the dictionary for the process handle pointed to
- * by this file. On the last close (when the file count reaches zero),
- * this function will wait for the child process and then return its
- * exit code as the result of the close() operation. This permits the
- * files to be closed in any order - it is always the close() of the
- * final handle that will return the exit code.
- */
-
- /* RED_FLAG 31-Aug-2000 Tim
- * This is always called (today!) between a pair of
- * Py_BEGIN_ALLOW_THREADS/ Py_END_ALLOW_THREADS
- * macros. So the thread running this has no valid thread state, as
- * far as Python is concerned. However, this calls some Python API
- * functions that cannot be called safely without a valid thread
- * state, in particular PyDict_GetItem.
- * As a temporary hack (although it may last for years ...), we
- * *rely* on not having a valid thread state in this function, in
- * order to create our own from scratch.
- * This will deadlock if _PyPclose is ever called by a thread
- * holding the global lock.
- */
-
bool cmWin32ProcessExecution::PrivateClose(int /* timeout */)
{
HANDLE hProcess = this-ProcessHandle;
Should I commit that?
Thanks,
Steve.
--
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
Re: [cmake-developers] _PyPopenProcs warning and comment in cmWin32ProcessExecution.cxx
Yes. That's clearly from the original source of this file (It was
copied into CMake from ITK, and looks like it must have come from
python originally.)
The comments are completely irrelevant to the existing code from today.
On Thu, Nov 8, 2012 at 1:43 PM, Stephen Kelly steve...@gmail.com wrote:
Brad King wrote:
On 11/08/2012 12:44 PM, Stephen Kelly wrote:
Hi there,
http://open.cdash.org/viewBuildError.php?type=1buildid=2652291
has a new warning (as a result of my adding warning flags) of an unused
variable. The variable is referenced in a comment. I'm guessing a snippet
came from elsewhere.
I can remove the _PyPopenProcs variable, but I think the comment should
be fixed too at the same time. However, I don't know what the comment
should be changed to.
That is an ancient version of the process execution implementation
which is only kept for backward compatibility to implement the
exec_program() command IIRC. We don't maintain it anymore so the
comments don't matter. Just remove the unused variable and its
comment.
If I remove all comments which refer to a _Py* variable, it looks like this:
diff --git a/Source/cmWin32ProcessExecution.cxx
b/Source/cmWin32ProcessExecution.cxx
index 9a536c1..5752ab6 100644
--- a/Source/cmWin32ProcessExecution.cxx
+++ b/Source/cmWin32ProcessExecution.cxx
@@ -271,13 +271,6 @@ bool cmWin32ProcessExecution::Wait(int timeout)
return this-PrivateClose(timeout);
}
-/*
- * Internal dictionary mapping popen* file pointers to process handles,
- * for use when retrieving the process exit code. See _PyPclose() below
- * for more information on this dictionary's use.
- */
-static void *_PyPopenProcs = NULL;
-
static BOOL RealPopenCreateProcess(const char *cmdstring,
const char *path,
const char *szConsoleSpawn,
@@ -679,18 +672,6 @@ bool cmWin32ProcessExecution::PrivateOpen(const char
*cmdstring,
}
}
- /*
- * Insert the files we've created into the process dictionary
- * all referencing the list with the process handle and the
- * initial number of files (see description below in _PyPclose).
- * Since if _PyPclose later tried to wait on a process when all
- * handles weren't closed, it could create a deadlock with the
- * child, we spend some energy here to try to ensure that we
- * either insert all file handles into the dictionary or none
- * at all. It's a little clumsy with the various popen modes
- * and variable number of files involved.
- */
-
/* Child is launched. Close the parents copy of those pipe
* handles that only the child should have open. You need to
* make sure that no handles to the write end of the output pipe
@@ -761,43 +742,6 @@ cmWin32ProcessExecution::~cmWin32ProcessExecution()
this-CloseHandles();
}
-/*
- * Wrapper for fclose() to use for popen* files, so we can retrieve the
- * exit code for the child process and return as a result of the close.
- *
- * This function uses the _PyPopenProcs dictionary in order to map the
- * input file pointer to information about the process that was
- * originally created by the popen* call that created the file pointer.
- * The dictionary uses the file pointer as a key (with one entry
- * inserted for each file returned by the original popen* call) and a
- * single list object as the value for all files from a single call.
- * The list object contains the Win32 process handle at [0], and a file
- * count at [1], which is initialized to the total number of file
- * handles using that list.
- *
- * This function closes whichever handle it is passed, and decrements
- * the file count in the dictionary for the process handle pointed to
- * by this file. On the last close (when the file count reaches zero),
- * this function will wait for the child process and then return its
- * exit code as the result of the close() operation. This permits the
- * files to be closed in any order - it is always the close() of the
- * final handle that will return the exit code.
- */
-
- /* RED_FLAG 31-Aug-2000 Tim
- * This is always called (today!) between a pair of
- * Py_BEGIN_ALLOW_THREADS/ Py_END_ALLOW_THREADS
- * macros. So the thread running this has no valid thread state, as
- * far as Python is concerned. However, this calls some Python API
- * functions that cannot be called safely without a valid thread
- * state, in particular PyDict_GetItem.
- * As a temporary hack (although it may last for years ...), we
- * *rely* on not having a valid thread state in this function, in
- * order to create our own from scratch.
- * This will deadlock if _PyPclose is ever called by a thread
- * holding the global lock.
- */
-
bool cmWin32ProcessExecution::PrivateClose(int /* timeout */)
{
HANDLE hProcess = this-ProcessHandle;
Should I commit that?
Thanks,
Steve.
--
Powered by
Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing
On Thu, Nov 8, 2012 at 10:54 AM, Petr Kmoch petr.km...@gmail.com wrote: Attached are modified patches adding EXCLUDE_FROM_DEFAULT_BUILD_CONFIG. The tests do not pass for me on VS 10. For example, VSExcludeFromDefaultBuild-Debug output contains: Run Build Command: ...\devenv.com VSExcludeFromDefaultBuild.sln /build Debug /project ALL_BUILD 11-- Skipped Build: Project: BuiltInDebug, Configuration: Debug x64 -- 11Project not selected to build for this solution configuration ... CMake Error at ResultTest.cmake:11 (message): File .../Debug/BuiltInDebug.exe was expected to exist! -Brad -- 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 0013664]: Emacs integration should be easier
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13664 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 13664 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-08 16:13 EST Last Modified: 2012-11-08 16:13 EST == Summary:Emacs integration should be easier Description: Integrating CMake with compilation-mode is obscenely difficult Steps to Reproduce: It's not much code, but the fact that we have to load and trawl the cmake_install.cmake file is just... wrong. (defun cmake-project-filename () (let ((filename (match-string-no-properties 1))) (save-match-data (with-temp-buffer (insert-file-contents-literally cmake_install.cmake) (goto-char (point-min)) (re-search-forward Install script for directory: \\(.+\\)) (cons filename (match-string-no-properties 1)) (push 'cmake compilation-error-regexp-alist) (push '(cmake ^\\(?:CMake Error at \\| \\)\\(.+?\\):\\([0-9]+\\) ([A-Za-z_][A-Za-z0-9_]*) (cmake-project-filename) 2) compilation-error-regexp-alist-alist) == Issue History Date ModifiedUsername FieldChange == 2012-11-08 16:13 Dave Abrahams 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 0013665]: include_directories(SYSTEM) should promote
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13665
==
Reported By:mwoehlke
Assigned To:
==
Project:CMake
Issue ID: 13665
Category: CMake
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-08 17:01 EST
Last Modified: 2012-11-08 17:01 EST
==
Summary:include_directories(SYSTEM) should promote
Description:
In some instances (possibly related to CMake version),
include_directories(SYSTEM ${foo}) has no effect.
Steps to Reproduce:
include_directories(${foo})
include_directories(SYSTEM ${foo})
Additional Information:
It appears that CMake ignores an include_directories(SYSTEM) for include
directories that already exist. This is more likely in large projects where e.g.
a top-level CMake file (or even a UseFoo.cmake) includes directories without
SYSTEM, and a leaf CMakeLists.txt does an include_directories(SYSTEM) of the
same directories.
I think it would be better following the expected behavior of
include_directories if, rather than ignore the directive if the directory is
already in include_directories, to 'promote' it to SYSTEM (probably without
changing the order).
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-08 17:01 mwoehlke 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 0013666]: CMake fails to support existing custom VS_GLOBAL_* properties in VS10 (ProjectExtensions - VisualStudio - UserProperties)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13666 == Reported By:Andreas Mohr Assigned To: == Project:CMake Issue ID: 13666 Category: CMake Reproducibility:N/A Severity: major Priority: normal Status: new == Date Submitted: 2012-11-09 01:48 EST Last Modified: 2012-11-09 01:48 EST == Summary:CMake fails to support existing custom VS_GLOBAL_* properties in VS10 (ProjectExtensions - VisualStudio - UserProperties) Description: While working on related functionality in vcproj2cmake, I noticed that while CMake has VS_GLOBAL_* properties (which on VSx side are different things: official *or* custom!) which are properly being generated into VS7 Globals section, in the VS10 generator there seems to be nothing done about it despite it seeming to be expected to go into the ProjectExtensions element (VisualStudio - UserProperties sub elements). A popular example of it would be the RESOURCE_FILE setting (or perhaps also QtVersion?). From some QD analysis it appears that the properties that CMake manages (improperly lumps together!!) as VS_GLOBAL_* are managed by VS in this way: VS7/8: project-global attribute keys are the official/fixed VS_GLOBAL_* values, whereas keys in Globals element are any user-custom values VS10: element keys in Globals element are the official/fixed VS_GLOBAL_* values, whereas keys in UserProperties (i.e. ProjectExtensions) element are any user-custom values Severity major since failing to generate the UserProperties section from all non-official user-custom VS_GLOBAL_* properties kills all user-supplied project properties on VS10, thus possibly causing major grief on user side, and it would be rather very easy to correct. Unless UserProperties section content happened to in fact be something different on VS10 and these properties are not supposed to be generated there... (would probably need some more analysis of known content in public sample project files) Thanks for listening! :) == Issue History Date ModifiedUsername FieldChange == 2012-11-09 01:48 Andreas Mohr 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
