Re: [cmake-developers] Bug fix requests for the *next* release of CMake...
Am Dienstag 29 März 2011, 19:56:03 schrieb David Cole: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. The simple answer is as always: fix all bugs I submitted ;) http://www.cmake.org/Bug/view.php?id=11333 FindThreads incorrectly adds -pthread to linker options http://www.cmake.org/Bug/view.php?id=7830 Likely a dupe of the above http://www.cmake.org/Bug/view.php?id=12054 FindJava.cmake too noisy on second run http://www.cmake.org/Bug/view.php?id=10740 This has been fixed in 2.8.4, but the doc update was not committed http://www.cmake.org/Bug/view.php?id=10476 No program output if CTest aborts test with timeout http://www.cmake.org/Bug/view.php?id=11792 Improve handling of CTEST_SITE http://www.cmake.org/Bug/view.php?id=11792 Code comments for many commands are wrong (copypaste) http://www.cmake.org/Bug/view.php?id=8466 Provide finer control than pass/fail for a test program Here are also some bugs that are resolved and can be closed as they are fixed in 2.8.4: http://www.cmake.org/Bug/view.php?id=11362 http://www.cmake.org/Bug/view.php?id=11329 http://www.cmake.org/Bug/view.php?id=11791 Eike ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012099]: Unable to quote cmd line args to be passed to nvcc
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12099 == Reported By:Ofri Sadowsky Assigned To: == Project:CMake Issue ID: 12099 Category: CMake Reproducibility:have not tried Severity: major Priority: high Status: new == Date Submitted: 2011-04-17 10:07 EDT Last Modified: 2011-04-17 10:07 EDT == Summary:Unable to quote cmd line args to be passed to nvcc Description: I am trying to build a CUDA project with Visual Studio 2010 and CMake. I know that this is a sensitive issue. Basically, I get a compilation error when nvcc tries to parse a stddef.h file, and runs into the use of an undefined macro named nullptr. A colleague of mine had patched my VS2010/CUDA setup so that with an ordinary VS project I can properly compile CUDA source files into .obj. One of the steps involved changing the VS rules so that the command line includes the following text: -Xcompiler /Dnullptr=0 /Dnullptr_t=__nullptr_t /D__nullptr=((void*)0) The quotation marks are essential, because otherwise the parentheses around the (void *) are parsed incorrectly. As you can see, the missing macros are defined, so that the original problem is bypassed. However hard I tried, I could not produce the proper quotation marks to be passed as nvcc command line arguments. It came to a point that when I take the command line produced within the CMake-generated VS project (using Verbose mode), and simply add the above options, my source file get compiled. But I can't get CMake to produce the same outcome. Example: Use the OPTIONS flag on the cuda_add_library. By default, this simply separates the -Xcompiler from the rest of the stuff, and creates an invalid command line, where Xcompiler becomes one of the options for Xcompiler. If I remove the -Xcompiler then I can't get the quotation right around the options, and then the parentheses scramle things up. It looks as though something is wrong in the way that the OPTIONS are parsed. I can't pinpoint the issue, and I can't get around it. Steps to Reproduce: You can use an empty .cu file. project(Test_CMake) find_package(CUDA) if(NOT CUDA_FOUND) message(SEND_ERROR CUDA package not found!) endif() cuda_add_library(Test_CMake emptyfile.cu) Try the various options. == Issue History Date ModifiedUsername FieldChange == 2011-04-17 10:07 Ofri Sadowsky New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Checking for -pthread before -lpthread{s} in FindThreads.cmake
Rolf Eike Beer e...@sf-mail.de writes: Am Sonntag 17 April 2011, 03:23:39 schrieb Raphael Kubo da Costa: Depending on the patch implementation, this would probably fix CMake bug #7830 as a side-effect. I think 7830 is another incarnation of what I submitted as bug 11333. And there is even a patch in my bug. I see. In your bug report, you said you were going to do some testing. Has it been done? Any opinions on the original issue too? ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Checking for -pthread before -lpthread{s} in FindThreads.cmake
Am Sonntag 17 April 2011, 19:05:04 schrieb Raphael Kubo da Costa: Rolf Eike Beer e...@sf-mail.de writes: Am Sonntag 17 April 2011, 03:23:39 schrieb Raphael Kubo da Costa: Depending on the patch implementation, this would probably fix CMake bug #7830 as a side-effect. I think 7830 is another incarnation of what I submitted as bug 11333. And there is even a patch in my bug. I see. In your bug report, you said you were going to do some testing. Has it been done? Not yet. signature.asc Description: This is a digitally signed message part. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Hi, On Sunday 17 April 2011, Oliver Buchtala wrote: Hi, I like to get involved offering work on the Eclipse CDT generator. Currently, the generated project setting is not very Eclipse'ish. There have been some changes in the 2.8.x versions. You have 2.8.4 ? - one large project - linear build, i.e., build failure in early sub projects stops the whole chain You can change this e.g. by adding -k as CMAKE_ECLIPSE_MAKE_ARGUMENTS in the cmake cache. - project overview looks like navigator on cmake binary directory - source files can be found in 'includes' Can you please explain the two points above in more detail ? All in all, this is not what a developer used to CDT wants to see ;) What I want to do: - generate projects for each target (like in VC generators) Can you please explain ? Do you want a separate build tree for each project ? Or just separate Eclipse project files for each target ? Are you sure people will want to import that many projects or can they be grouped in some way in a superproject ? - based upon makefile generator eclipse cdt projects can be based upon existing makefiles (e.g. in sub-dirs) - add folders: * src: using eclipse linked folder pointing to source location (CMAKE_CURRENT_SOURCE_DIR) * cmake: eclipse linked folder pointing to CMAKE_CURRENT_BINARY_DIR We have something like this in 2.8.4. I.e. there are linked folders for each project(), and one linked folder for CMAKE_SOURCE_DIR. - add project dependencies for correct build order Having this would make the CDT generator beeing a serious citizen on the cmake generators list. Q's: - What is your opinion? A not-Makefile based native Eclipse project generator might also be an alternative, but requires more work. - Stage access? - Collaborators? Author of CDT4 generator? I'm mainly maintaining it. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Hi Alex, Am 17.04.2011 20:46, schrieb Alexander Neundorf: Hi, On Sunday 17 April 2011, Oliver Buchtala wrote: Hi, I like to get involved offering work on the Eclipse CDT generator. Currently, the generated project setting is not very Eclipse'ish. There have been some changes in the 2.8.x versions. You have 2.8.4 ? Yes. Actually current 'next' of stage. - one large project - linear build, i.e., build failure in early sub projects stops the whole chain You can change this e.g. by adding -k as CMAKE_ECLIPSE_MAKE_ARGUMENTS in the cmake cache. What does '-k' do? - project overview looks like navigator on cmake binary directory - source files can be found in 'includes' Can you please explain the two points above in more detail ? When I generate a CDT project, sources are in 'includes' (CDT built-in folder). The rest is the content of CMAKE_BINARY_DIR. See attachment: 2.4.8 CDT4 MinGW generator on CMake/Example, Eclipse Helios, CDT 7.0.2 typo: 2.8.4 All in all, this is not what a developer used to CDT wants to see ;) What I want to do: - generate projects for each target (like in VC generators) Can you please explain ? Do you want a separate build tree for each project ? Or just separate Eclipse project files for each target ? For each target. Like in MSVC. Are you sure people will want to import that many projects or can they be grouped in some way in a superproject ? Eclipse users are used to a flat multi-project layout. They use working sets to group projects. Actually, I am personally not the greatest friend of complete flat hierarchies - but this is actually the eclipse way. You may have a look at large Eclipse java projects, e.g. Eclipse itself. Importing all projects in a directory is a one-clicker. Though, they should not be nested for that feature to work. Another typical way to separate things is to have multiple workspaces. E.g. one for each large project. So IMO there are enough ways to structure views on very large projects. Another feedback story: At work, I suggested my coworkers to give eclipse+cmake a try (without trying it myself) as we have now a CMake setup and I am a fan of CDT. They stopped disappointed beeing confused by the project layout. They are used to MSVC and a bit to Codeblocks. And, trying it the first time (yesterday) I really felt similar. Perhaps, you can understand on the basis of my screenshot. - based upon makefile generator eclipse cdt projects can be based upon existing makefiles (e.g. in sub-dirs) - add folders: * src: using eclipse linked folder pointing to source location (CMAKE_CURRENT_SOURCE_DIR) * cmake: eclipse linked folder pointing to CMAKE_CURRENT_BINARY_DIR We have something like this in 2.8.4. I.e. there are linked folders for each project(), and one linked folder for CMAKE_SOURCE_DIR. I thought have seen this beeing deactivated in source code due to some issue filed on bugtracker? - add project dependencies for correct build order Having this would make the CDT generator beeing a serious citizen on the cmake generators list. Q's: - What is your opinion? A not-Makefile based native Eclipse project generator might also be an alternative, but requires more work. I think the Makefile based approach is very reasonable as it is really tightly integrated. Actually, there is not too much missing IMO. Per target project would bring a more intuitive relation between targets and projects. This is really what I want from the IDE setting. Otherwise I will use make on the shell. I would add a project per target based on make. Per project add only the one make target. And maybe add a global ALL project. Maybe also a ZERO_CHECK project all others depend on ... for checking on CMakeLists.txt changes. Another question: you call the generator CDT4. Current CDT is 7.0.2. Though, I find 'cdtBuilder version' in current .cproject. Is CDT4 'out-of-date' or are you referring to the version in xml? Ehmm, I mean this: ?fileVersion 4.0.0? storageModule moduleId=cdtBuildSystem version=4.0.0 Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
