[cmake-developers] [CMake 0012417]: CDT4 generator: source path configured incorrectly
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12417 == Reported By:Simon Barner Assigned To: == Project:CMake Issue ID: 12417 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-08-24 04:51 EDT Last Modified: 2011-08-24 04:51 EDT == Summary:CDT4 generator: source path configured incorrectly Description: I use CMake 2.8.5 to generate Eclipse CDT4 projects (Eclipse Helios SR2 for C/C++ developers, CDT with mingw makefiles). Since 2.8.5, for each project that is added using add_subdirectory(), a linked resource is created which enables me to easily navigate to files of subprojects. However, the source path for my linked subproject seems to be incorrect since I get the following warnings (see below for a test case). Invalid project path: Missing project folder or file \test@build\test for source path Invalid project path: Missing project folder or file \test@build\sub for source path Unfortunately, this seems to prevent the Eclipse indexer from correctly picking up the files in my subprojects. I had a look at the generated .cproject, and here the following path entries are generated: pathentry kind=src path=[Source directory]/ pathentry kind=src path=/sub/ pathentry kind=src path=/test/ When I manually modify the generated .cproject file to match the actual virtual folders the warnings go away and the index works correctly: pathentry kind=src path=[Source directory]/ pathentry kind=src path=[Subprojects]/sub/ pathentry kind=src path=[Subprojects]/test/ Please note, it also possible to simply add the virtual [Subprojects] folders as a path entry: pathentry kind=src path=[Source directory]/ pathentry kind=src path=[Subprojects]/ Steps to Reproduce: Here is my test case (see also attachment) Directory layout: project project/test/CMakeLists.txt project/test/sub/CMakeLists.txt project/build project/test/CMakeLists.txt: -- project(test) add_subdirectory(test) -- project/test/sub/CMakeLists.txt: -- project(sub) -- I configured an out-of-source build to project/build which I imported into Eclipse. == Issue History Date ModifiedUsername FieldChange == 2011-08-24 04:51 Simon Barner New Issue 2011-08-24 04:51 Simon Barner File Added: testcase-CDT4.zip == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012418]: make error when configuring cmake with MinGW/MSYS
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12418 == Reported By:a123b Assigned To: == Project:CMake Issue ID: 12418 Category: CMakeSetup Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-08-24 05:44 EDT Last Modified: 2011-08-24 05:44 EDT == Summary:make error when configuring cmake with MinGW/MSYS Description: $ configure - CMake 2.8.5, Copyright 2000-2009 Kitware, Inc. Found GNU toolchain C compiler on this system is: gcc C++ compiler on this system is: g++ Makefile processor on this system is: make g++ is GNU compiler g++ has STL in std:: namespace g++ has ANSI streams g++ has streams in std:: namespace g++ has sstream g++ has operator!=(string, char*) g++ has stl iterator_traits g++ has standard template allocator g++ has allocator::rebind g++ does not have non-standard allocator::max_size argument g++ has stl containers supporting allocator objects g++ has header cstddef g++ requires template friends to use g++ supports member templates g++ does not have standard template specialization syntax g++ has argument dependent lookup g++ does not have struct stat with st_mtim member g++ has ios::binary openmode g++ has ANSI for scoping - - Error when bootstrapping CMake: Problem while running make - Log of errors: /cmake-2.8.5/Bootstrap.cmk/cmake_bootstrap.log - == Issue History Date ModifiedUsername FieldChange == 2011-08-24 05:44 a123b New Issue 2011-08-24 05:44 a123b File Added: cmake_bootstrap.log == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012419]: Project Dependencies in VS Generators broken
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12419 == Reported By:cbielow Assigned To: == Project:CMake Issue ID: 12419 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-08-24 07:35 EDT Last Modified: 2011-08-24 07:35 EDT == Summary:Project Dependencies in VS Generators broken Description: For VS solution files (tried VS9 and VS10): Invoking a target X from a sub-Project will fail to build dependencies Y of X and gives Project not selected to build for this solution configuration. Steps to Reproduce: minimal example attached (see run.bat to run it). Additional Information: Dirty Workaround: Specify a dependency just like Y (with another name) in the sub-Project and make it depend on X. Then it will be build. == Issue History Date ModifiedUsername FieldChange == 2011-08-24 07:35 cbielowNew Issue 2011-08-24 07:35 cbielowFile Added: Cmakebug.zip == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GenerateExportHeader macro in CMake?
Stephen Kelly wrote: Yep, I've just had a look and possibily fixed the Intel and HPUX cases. I did indeed fix the Intel and HPUX cases. The AIX one fails because the visibility test passes, because check_cxx_compiler_flag does not have a FAIL_REGEX for its warning: http://www.cdash.org/CDash/testDetails.php?test=109778717build=1458523 http://www.cdash.org/CDash/testDetails.php?test=110283056build=1458523 I've also pushed a possible fix for that to check_cxx_compiler_flag on the branch. The FAIL_REGEX I added for AIX was successful. However, now that box reports some garbage: ld: 0706-014 The -b Tests/CMake- build/Tests/Module/GenerateExportHeader/libsharedtest/fail1/libshared option is not recognized. Someone with access to the box would have to find out what's going wrong. It might have been caused by a space in the path, which I've just added a fix for. It might be worth running some tests twice: Once from a path with a space in it, and once without. Or run all tests from a path with a space in it to prevent these kinds of bugs. I would prefer to turn off the tests for it anyway, but I don't know what platform test to make. What is the equivalent to if (WIN32) return() endif() for AIX? The CentOS machine seems to have problems unrelated to this test: http://www.cdash.org/CDash/testDetails.php?test=109887854build=1457339 http://www.cdash.org/CDash/viewTest.php?buildid=1457339 All have ' undefined reference to `_Unwind_Resume'' in their output. Do I have to do anything about this? That only leaves Watcom as you say, and I've just tried to simplify the tests for that compiler. If the timeouts persist, I can start just disabling some tests for that compiler. This one is still timing out. I've disable the test for it with (CMAKE_COMPILER_FLAG MATCHES Watcom). Thanks, Steve. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GenerateExportHeader macro in CMake?
On Wed, Aug 24, 2011 at 2:02 PM, Stephen Kelly steve...@gmail.com wrote: Stephen Kelly wrote: Yep, I've just had a look and possibily fixed the Intel and HPUX cases. I did indeed fix the Intel and HPUX cases. Thank you. The AIX one fails because the visibility test passes, because check_cxx_compiler_flag does not have a FAIL_REGEX for its warning: http://www.cdash.org/CDash/testDetails.php?test=109778717build=1458523 http://www.cdash.org/CDash/testDetails.php?test=110283056build=1458523 I've also pushed a possible fix for that to check_cxx_compiler_flag on the branch. The FAIL_REGEX I added for AIX was successful. That's fine... However, now that box reports some garbage: ld: 0706-014 The -b Tests/CMake- build/Tests/Module/GenerateExportHeader/libsharedtest/fail1/libshared option is not recognized. Someone with access to the box would have to find out what's going wrong. It might have been caused by a space in the path, which I've just added a fix for. It might be worth running some tests twice: Once from a path with a space in it, and once without. Or run all tests from a path with a space in it to prevent these kinds of bugs. I would prefer to turn off the tests for it anyway, but I don't know what platform test to make. What is the equivalent to if (WIN32) return() endif() for AIX? The test itself passes on AIX, as seen here: http://www.cdash.org/CDash/testDetails.php?test=109727151build=1460504 It's only the particular machine that you pointed to that has problems. There are *several* tests that fail on that machine with the space in the path. That's one of the reasons it's only in Nightly and not Nightly Expected The CentOS machine seems to have problems unrelated to this test: http://www.cdash.org/CDash/testDetails.php?test=109887854build=1457339 http://www.cdash.org/CDash/viewTest.php?buildid=1457339 All have ' undefined reference to `_Unwind_Resume'' in their output. Do I have to do anything about this? No -- this will go away eventually. Either by being fixed or being banished. That only leaves Watcom as you say, and I've just tried to simplify the tests for that compiler. If the timeouts persist, I can start just disabling some tests for that compiler. This one is still timing out. I've disable the test for it with (CMAKE_COMPILER_FLAG MATCHES Watcom). You mean CMAKE_COMPILER_ID as in this commit, right? http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99b2aabd460d0c508ffa7b21283a0512e322e717 That's fine. Thanks, Steve. Thank *you* -- your persistence has paid off. I think tomorrow it will be passing enough to merge over to 'master' ... :-) David ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GenerateExportHeader macro in CMake?
David Cole wrote: The test itself passes on AIX, as seen here: http://www.cdash.org/CDash/testDetails.php?test=109727151build=1460504 It's only the particular machine that you pointed to that has problems. There are *several* tests that fail on that machine with the space in the path. That's one of the reasons it's only in Nightly and not Nightly Expected Ok. Nevertheless I think it would make sense for cdash to always check out and build in a directory with a space in it. There could be other bugs lurking. That only leaves Watcom as you say, and I've just tried to simplify the tests for that compiler. If the timeouts persist, I can start just disabling some tests for that compiler. This one is still timing out. I've disable the test for it with (CMAKE_COMPILER_FLAG MATCHES Watcom). You mean CMAKE_COMPILER_ID as in this commit, right? http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99b2aabd460d0c508ffa7b21283a0512e322e717 That's fine. On closer inspection I figured it should be CMAKE_CXX_COMPILER_ID. I don't know if CMAKE_COMPILER_ID would work too... Thank *you* -- your persistence has paid off. I think tomorrow it will be passing enough to merge over to 'master' ... :-) Great. Hopefully it will be useful to many. Steve. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GenerateExportHeader macro in CMake?
On Wed, Aug 24, 2011 at 2:27 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: The test itself passes on AIX, as seen here: http://www.cdash.org/CDash/testDetails.php?test=109727151build=1460504 It's only the particular machine that you pointed to that has problems. There are *several* tests that fail on that machine with the space in the path. That's one of the reasons it's only in Nightly and not Nightly Expected Ok. Nevertheless I think it would make sense for cdash to always check out and build in a directory with a space in it. There could be other bugs lurking. The vast majority of our dashboard builds are done on build trees and source trees that have a space in the full path name. We only do non-space-in-the-path builds on machines where there are problems with other tools over which we have no control. We all strive to have cmake, ctest and cpack work flawlessly when there are spaces in file and path names. We only punt on a given dashboard machine when we have to. That only leaves Watcom as you say, and I've just tried to simplify the tests for that compiler. If the timeouts persist, I can start just disabling some tests for that compiler. This one is still timing out. I've disable the test for it with (CMAKE_COMPILER_FLAG MATCHES Watcom). You mean CMAKE_COMPILER_ID as in this commit, right? http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99b2aabd460d0c508ffa7b21283a0512e322e717 That's fine. On closer inspection I figured it should be CMAKE_CXX_COMPILER_ID. I don't know if CMAKE_COMPILER_ID would work too... You're right, it should be CMAKE_CXX_COMPILER_ID (or _C_). And do you have the right logical sense of the if test? Do you want that simple main for the Watcom compiler, or should it be a NOT? (I'm just asking to double-check, I haven't dug in and read enough of your test to fully appreciate the chunk shown in the gitweb diff view.) Thank *you* -- your persistence has paid off. I think tomorrow it will be passing enough to merge over to 'master' ... :-) Great. Hopefully it will be useful to many. I'm sure it will. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012420]: CMake fails to identify the compiler
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12420 == Reported By:Bhadresh Desai Assigned To: == Project:CMake Issue ID: 12420 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-08-25 01:44 EDT Last Modified: 2011-08-25 01:44 EDT == Summary:CMake fails to identify the compiler Description: CMake fails to identify compiler as a result you cannot build even a simple C/C++ program on AIX 5.3 Additional Information: The issue is converting CMakeCXXCompilerId.cpp.in and CMakeCCompilerId.c.in to CMakeCXXCompilerId.cpp and CMakeCCompilerId.c For some reason the first character in file is missed out when creating the .cpp and .c file. As a work around I had to put additional space at the beginning of the file. Also there is issue around @CMAKE_CXX_COMPILER_ID_PLATFORM_CONTENT@ in both files. I had to add / (a space and /) in front of @CMAKE_CXX_COMPILER_ID_PLATFORM_CONTENT@ to get it working. I am attaching both modified files. == Issue History Date ModifiedUsername FieldChange == 2011-08-25 01:44 Bhadresh Desai New Issue 2011-08-25 01:44 Bhadresh Desai File Added: CMakeCXXCompilerId.cpp.in == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
