[cmake-developers] [CMake 0011310]: vim script to open --help-command output in a split window
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11310 == Reported By:Matthias Kretz Assigned To: == Project:CMake Issue ID: 11310 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2010-10-13 09:21 EDT Last Modified: 2010-10-13 09:21 EDT == Summary:vim script to open --help-command output in a split window Description: This is a little script to open a vertical split window with the output of cmake --help-command for the word under the cursor. Alex suggested to post it here so that you may bundle it with the other vim scripts for cmake. == Issue History Date ModifiedUsername FieldChange == 2010-10-13 09:21 Matthias Kretz New Issue 2010-10-13 09:21 Matthias Kretz File Added: cmakehelp.vim == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
So, I think we have to use the new name approach. Do we want to call it 2? Or should we call it something else? Alex, do you have time to do this? I want to get the CMake release out very soon. Thanks. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011311]: Visual Studio 2008 MIDL and cmake 2.8.2
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11311 == Reported By:Julian Lim Assigned To: == Project:CMake Issue ID: 11311 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2010-10-13 12:49 EDT Last Modified: 2010-10-13 12:49 EDT == Summary:Visual Studio 2008 MIDL and cmake 2.8.2 Description: I'm submitting a patch for 2.8.2 cmake which consist of a patch (described in issue http://www.cmake.org/Bug/view.php?id=8165) that is designed cmake 2.8 AND 3 more items that we worked on. We are working on Visual Studio 2008 COM project which has IDL files and need MIDL to generate the .TLB and header and source files, and we faced with 2 major issues. (1) Looking at 2.8.2 code, the patch from http://www.cmake.org/Bug/view.php?id=8165 hasn’t been applied. After we manually apply it, got us a step forward and now we faced with issue http://www.cmake.org/Bug/view.php?id=2. http://www.vtk.org/Bug/view.php?id=8165 1-- Build started: Project: vbabc, Configuration: Release Win32 -- 1Creating Type Library... 1midl : command line warning MIDL1009 : unknown argument ignored ..\..\..\..\source\libvbabc\vbabc.idl 1Processing Release\ 1Release 1c1 : fatal error C1083: Cannot open source file: 'Release': Invalid argument 1midl : command line error MIDL1003 : error returned by the C preprocessor (2) 1Build log was saved at file://c:\source\build\msvc\vc\libvbabc\vbabc.dir\Release\BuildLog.htm 1vbabc - 2 error(s), 1 warning(s) == Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped == (2) After issue http://www.cmake.org/Bug/view.php?id=1 resolved, we could finally MIDL tools ran against IDL files. There were 2 issues we face when issue http://www.cmake.org/Bug/view.php?id=1 is resolved. a. The .TLB files are generated inside build directory (example, vbabc.dir/Release) but Visual Studio is still looking for it in the CMAKE Source directory. Yes, we do want these files to be generated in vbabc.dir/Release which is the object directory because this will enable us to build from multiple processes and do not interfere with each build. b. The generated headers is not in any Include path that when our source include it an error occurs. c. For Linker, DebugInformation is YES for Release version. The patch I'm submitting face all these issues in 2.8.2. -Julian Lim Tradebot Systems == Issue History Date ModifiedUsername FieldChange == 2010-10-13 12:49 Julian Lim New Issue 2010-10-13 12:49 Julian Lim File Added: cmLocalVisualStudio7Generator.cxx.2.8.2.patch == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Tuesday 12 October 2010, David Cole wrote: On Tue, Oct 12, 2010 at 5:21 PM, Brad King brad.k...@kitware.com wrote: ... releases and will get us through this CMake rc cycle safely. Future enhancements to FPHSA2 may need yet another new module, but I think that is in the nature of this particular function. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I really think a second function is the way to go here. It is the least risky and maintains full compatibility with existing module overrides. It does not have to be named FPHSA2 (I am not a big fan of 2 named functions...) but I do think it needs to be a newly-named function, and keep the old function as is. We can come up with better solutions moving forward, but for now, to keep *everything* working well without breaking anything *else*... I think a second function is our only realistic option. No, it's not. Using the full path (as already _completely done_ in the AddCMAKE_CURRENT_LIST_DIR branch) is 100% safe now and in future cmake releases. Adding FPHSA2.cmake now in 2.8.3 is safe now, but not as soon as new features are added to it in 2.8.4 or later versions. Projects will have copies of it and it can break just the same way then. What am I missing here ? Where is the risk (or any problem) when using the full path ? I don't understand the argumentation. FYI, kdelibs 4.5.2 (released 2 weeks ago) has the full-featured FPHSA.cmake, so this one will be compatible with 2.8.3, but I think no matter what we decide for now, 4.5.2 could be ignored if it stays the only release which may have some oddity. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Tuesday 12 October 2010, Brad King wrote: On 10/12/2010 03:32 PM, Alexander Neundorf wrote: On Tuesday 12 October 2010, Bill Hoffman wrote: Anyway, in the short term, we are going to go with FPHSA2, Alex do you have time to do that? FPHSA2 would have been my last choice. In staging there is already the branch AddCMAKE_CURRENT_LIST_DIR: http://cmake.org/gitweb?p=stage/cmake.git;a=log;h=refs/heads/AddCMAKE_CUR RENT_LIST_DIR where I implemented the option with the hardcoded paths: The original FPHSA floated around outside of CMake in many projects before it was distributed with CMake. It is a long-established API that has been re-implemented (via copying) in many projects. Therefore it is too late to change. See James Bigler's comment earlier in this thread about ABI compatibility approaches. No one proposes changing the ABI of malloc in C because many custom allocation libraries override it at link time. Currently projects have the option to override it with CMAKE_MODULE_PATH to providing a module with the same API but a tweaked implementation. With the CURRENT_LIST_DIR approach that option goes away, and any project that does it already will break. Yes, because this option is what makes cmake break KDE currently. This is the problem, this is what must be changed. Nothing breaks with the CURRENT_LIST_DIR, since this only applies to the modules shipped with cmake, so those get what they expect. The modules shipped with the project still get their own FPHSA.cmake. I can't think of a constellation which could break. Otherwise this means that no matter what new features we add to any of cmake's modules, we cannot use any of them in any other module. Do we want that ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Wednesday 13 October 2010, Bill Hoffman wrote: So, I think we have to use the new name approach. Do we want to call it 2? Or should we call it something else? Alex, do you have time to do this? I think it's not a good solution, and the one with CURRENT_LIST_DIR is definitely better and already implemented. And I am still convinced that I am right here, see my other mails. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Wednesday 13 October 2010, Alexander Neundorf wrote: ... Adding FPHSA2.cmake now in 2.8.3 is safe now, but not as soon as new features are added to it in 2.8.4 or later versions. Projects will have copies of it and it can break just the same way then. Example: assume projects will take a copy of FPHSA2.cmake now. KDE will have one. In cmake 2.8.4 FPHSA2 may have some new option for better handling of the COMPONENTS argument of find_package(). - same breakage again as we have now, if no full path is used. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Wednesday 13 October 2010, Alexander Neundorf wrote: On Tuesday 12 October 2010, Brad King wrote: ... Currently projects have the option to override it with CMAKE_MODULE_PATH to providing a module with the same API but a tweaked implementation. With the CURRENT_LIST_DIR approach that option goes away, and any project that does it already will break. Yes, because this option is what makes cmake break KDE currently. This is the problem, this is what must be changed. Nothing breaks with the CURRENT_LIST_DIR, since this only applies to the modules shipped with cmake, so those get what they expect. The modules shipped with the project still get their own FPHSA.cmake. I can't think of a constellation which could break. Example: assume a project relies on the fact that FindZLIB.cmake gets their modified copy of FPHSA.cmake, which e.g. sets some additional variable, or looks at some additional variable (realistically I don't think such a modified version, i.e. not just simply an older version, exists). If we rename the file to FPHSA2.cmake, this will not be the case anymore, so their project is broken. The same happens if FindZLIB.cmake uses CURRENT_LIST_DIR. Additionally FPHSA2.cmake has other (likely) chances to break in the future (see my other email). Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
