[cmake-developers] [CMake 0011722]: CMake.desktop: wrong Exec field
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11722 == Reported By:arrowdodger Assigned To: == Project:CMake Issue ID: 11722 Category: QtDialog Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-01-19 05:27 EST Last Modified: 2011-01-19 05:27 EST == Summary:CMake.desktop: wrong Exec field Description: cmake-gui uses a path to build as it's argument, not CMakeCache.txt itself. So, %f should be replaced with %d. Steps to Reproduce: Using Dolphin or any other file manager program try to open CMakeCache.txt file using CMake program. It will open last used project, not the excepted one. == Issue History Date ModifiedUsername FieldChange == 2011-01-19 05:27 arrowdodgerNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011723]: eclipse build
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11723 == Reported By:Galeazzi Assigned To: == Project:CMake Issue ID: 11723 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-01-19 11:58 EST Last Modified: 2011-01-19 11:58 EST == Summary:eclipse build Description: suppose I have a project with: add_subdirectory(path/lib1 ${CMAKE_CURRENT_BINARY_DIR}/ib1) when I change a source of lib1 and click on build over the eclipse project, eclipse doesn't build anything. If I change a source of the main project it launches the build correctly. I also tried to test the same thing with a simple MinGW Makefile (instead of Eclipse CDT 4 - MinGW Makefile) and it works properly in both two cases. Steps to Reproduce: Just create a project with the same structure above == Issue History Date ModifiedUsername FieldChange == 2011-01-19 11:58 Galeazzi New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011725]: CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works if unqualified
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11725 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 11725 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-01-19 17:03 EST Last Modified: 2011-01-19 17:03 EST == Summary:CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works if unqualified Description: At the top of my top-level CMakeLists.txt file, I have SET(CMAKE_USER_MAKE_RULES_OVERRIDE CMakeCommon.txt) My CMakeCommon.txt file lives right alongside the aforementioned listfile, and things worked dandily like this for the last few years (up to 2.8.1). With 2.8.3, however, I get this: (cut here) -- The C compiler identification is Intel -- Using predefined Intel compiler flags -- Check for working C compiler: C:/Program Files (x86)/Intel/Compiler/C++/9.1/EM64T/Bin/icl.exe CMake Error at X:/freeport/arch/win64_icl_mt/share/cmake-2.8/Modules/CMakeCInformation.cmake:79 (INCLUDE): include could not find load file: CMakeCommon.txt Call Stack (most recent call first): CMakeLists.txt:3 (PROJECT) (cut here) Things work again if I edit the line to SET(CMAKE_USER_MAKE_RULES_OVERRIDE ${CMAKE_SOURCE_DIR}/CMakeCommon.txt) However, I believe the previous behavior was reasonable, where this variable would implicitly be interpreted relative to ${CMAKE_SOURCE_DIR} rather than anywhere else. == Issue History Date ModifiedUsername FieldChange == 2011-01-19 17:03 Daniel R. GomezNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] xcode project and static library dependencies
BTW, it might make more sense to move this to the cmake-developers mailing list. I've transfered this thread to the developer list. See below for continuation.. On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote: On 1/18/2011 2:40 PM, Brad King wrote: On 1/18/2011 2:12 PM, Nick Kledzik wrote: When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. This is where CMake puts files in single-configuration generators. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. This is where CMake puts files in multi-configuration generators. Both of the above are expected default behaviors. Both can be changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and its per-configuration equivalent. All CMake generators must honor these. None of these locations are the native location where Xcode would put a build result. Xcode has settings like CONFIGURATION_BUILD_DIR to control where the build outputs go. This already works. Is there some reason your changes cannot use these? My understanding is that the main problem with the current generator is all the extra build phases and OTHER_LDFLAGS stuff used to deal with link line ordering and static libraries. This is what Bill summarized: On 1/13/2011 3:41 PM, Bill Hoffman wrote: - have a static library show up more than once on a link line - be able to specify the order of static libraries on the link line - be able to relink and executable when a static library that it depends on is rebuilt. I'm more interested in a solution to implementation issues like these than in interface details like where output files go. -Brad So, for Xcode and VS IDE, CMake will place things in directories like Debug, Release. For example, you should get something like this: ${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe Xcode does support building multiple configurations like Debug, Release, etc. Where is the native location for those files? As I said, it is per-user xcode settings. You cannot infer the location from source tree cmake has access to. At build time, the location is known within xcode. So, I added a copy-file phase to have xocde copy the resulting binary from the native location to the standard location the cmake expects. There is little overhead for this. I've now have a patch which: 1) preserves link order 2) builds libraries into the xcode native location 4) removes pre and post shell script phases previously used to fix dependency problems 3) xcode projects now have proper dependencies WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode, build-all, set the current target to be cmake, make a source change, hit build, and have xcode just compile that one file, re-archive the library, then re-link cmake tool. I also debugged all this in Xcode by setting arguments for the cmake tool and hitting the build-and-debug within xcode! Attached is the patch from cmake-2.8.3 sources: cmake-xcode.patch Description: Binary data This cmake also creates an xcode project that builds LLVM. It is still not quite optimal because there are a bunch of cases where custom rules cause a custom make file to be generated which is executed from within xcode via a shell script phase. Xcode does not now which files the script might modify, so xcode has to be conservative and re-check all timestamps. There are ways to add custom scripts with specified input and output files in xcode. I may get to fixing that someday... How does one run the test suite? I saw the instructions about building cmake for make, then executing make Experimental. I did that and all 184 or 184 tests passed. But it looks like this is running the cmake generated makefiles - not cmake generated xcode projects. -Nick ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] xcode project and static library dependencies
On Wed, Jan 19, 2011 at 8:08 PM, Nick Kledzik kled...@apple.com wrote: BTW, it might make more sense to move this to the cmake-developers mailing list. I've transfered this thread to the developer list. See below for continuation.. On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote: On 1/18/2011 2:40 PM, Brad King wrote: On 1/18/2011 2:12 PM, Nick Kledzik wrote: When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. This is where CMake puts files in single-configuration generators. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. This is where CMake puts files in multi-configuration generators. Both of the above are expected default behaviors. Both can be changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and its per-configuration equivalent. All CMake generators must honor these. None of these locations are the native location where Xcode would put a build result. Xcode has settings like CONFIGURATION_BUILD_DIR to control where the build outputs go. This already works. Is there some reason your changes cannot use these? My understanding is that the main problem with the current generator is all the extra build phases and OTHER_LDFLAGS stuff used to deal with link line ordering and static libraries. This is what Bill summarized: On 1/13/2011 3:41 PM, Bill Hoffman wrote: - have a static library show up more than once on a link line - be able to specify the order of static libraries on the link line - be able to relink and executable when a static library that it depends on is rebuilt. I'm more interested in a solution to implementation issues like these than in interface details like where output files go. -Brad So, for Xcode and VS IDE, CMake will place things in directories like Debug, Release. For example, you should get something like this: ${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe Xcode does support building multiple configurations like Debug, Release, etc. Where is the native location for those files? As I said, it is per-user xcode settings. You cannot infer the location from source tree cmake has access to. At build time, the location is known within xcode. So, I added a copy-file phase to have xocde copy the resulting binary from the native location to the standard location the cmake expects. There is little overhead for this. I am still not sure why you need the extra copy. That is a concern. If Xcode were to put things in a predictable place, we could just have CMake look there, just like in VS when we look in the Debug, Release, etc, directories. I've now have a patch which: 1) preserves link order 2) builds libraries into the xcode native location 4) removes pre and post shell script phases previously used to fix dependency problems 3) xcode projects now have proper dependencies That sounds great. WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode, build-all, set the current target to be cmake, make a source change, hit build, and have xcode just compile that one file, re-archive the library, then re-link cmake tool. I also debugged all this in Xcode by setting arguments for the cmake tool and hitting the build-and-debug within xcode! Attached is the patch from cmake-2.8.3 sources: This cmake also creates an xcode project that builds LLVM. It is still not quite optimal because there are a bunch of cases where custom rules cause a custom make file to be generated which is executed from within xcode via a shell script phase. Xcode does not now which files the script might modify, so xcode has to be conservative and re-check all timestamps. There are ways to add custom scripts with specified input and output files in xcode. I may get to fixing that someday... How does one run the test suite? I saw the instructions about building cmake for make, then executing make Experimental. I did that and all 184 or 184 tests passed. But it looks like this is running the cmake generated makefiles - not cmake generated xcode projects. To run the tests, do this: 1. build your modified CMake 2. build a second CMake with the one from step 1, with -GXcode 3. run ./bin/Release/ctest -C Release from the binary tree of CMake. That will use the Xcode generator for the tests, also will verify that CMake itself can be built with your modified CMake. So, something like this: mkdir CMakeTest; cd CMakeTest /path/to/your/modified/cmake/bin/cmake -GXcode ../CMake /path/to/your/modified/cmake/bin/cmake --build . --config Release ./bin/Release/ctest -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Tue, Jan 18, 2011 at 11:08 AM, David Cole david.c...@kitware.com wrote: On Tue, Jan 18, 2011 at 1:53 PM, Brad King brad.k...@kitware.com wrote: On 1/18/2011 1:50 PM, Manuel Klimek wrote: Since this is a big integration style test, is it also possible to integrate a python test? (the whole test would fit into a few lines of python then) We'd prefer not to depend on python, but certainly a prototype in python would be a good start. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Brad's being polite when he says we'd prefer not to depend on python. CMake itself *will not* depend on python. And for any test that is expected to be run on all of our dashboard clients before it's accepted into CMake 'master', such a test cannot depend on python either. So the question is: do you want to run this test as part of the dashboard clients? I'm happy to comply with whatever decision you make, given the trade-off between maintainability of the test and dependency on python. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers