[cmake-developers] [CMake 0011307]: Xcode generator does not recognise *.hh files correctly
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11307 == Reported By:dsieger Assigned To: == Project:CMake Issue ID: 11307 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-10-12 09:01 EDT Last Modified: 2010-10-12 09:01 EDT == Summary:Xcode generator does not recognise *.hh files correctly Description: The Xcode generator does not recognize C++ *.hh header files correctly. The filetype is set to sourcecode instead of sourcecode.cpp.h. The attached patch fixes this. == Issue History Date ModifiedUsername FieldChange == 2010-10-12 09:01 dsiegerNew Issue 2010-10-12 09:01 dsiegerFile Added: hh.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, Marcus D. Hanwell wrote: On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.orgwrote: ... Personally, I would try a rc3 with CMP0017 set to NEW and see how it goes. It works for kdelibs and for our project at work (which doesn't have a lot of fancy cmake stuff). If it is just that one file why not go with the simple solution? I would love to see a policy where includes in the same directory would be considered first, and then the normal search behavior. I wasn't sure how feasible this was in an rc3. Avogadro effectively copied what KDE was doing, and so maybe the issue is not that widespread. I don't have the avogadro sources here. What does it do, i.e. what did it copy from KDE ? Does it a find_package(KDE4) ? Or does it include its own version of FindPackageHandleStandardArgs.cmake ? 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, Marcus D. Hanwell wrote: 2010/10/12 Alexander Neundorf neund...@kde.org On Tuesday 12 October 2010, Marcus D. Hanwell wrote: On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.org wrote: ... Personally, I would try a rc3 with CMP0017 set to NEW and see how it goes. It works for kdelibs and for our project at work (which doesn't have a lot of fancy cmake stuff). If it is just that one file why not go with the simple solution? I would love to see a policy where includes in the same directory would be considered first, and then the normal search behavior. I wasn't sure how feasible this was in an rc3. Avogadro effectively copied what KDE was doing, and so maybe the issue is not that widespread. I don't have the avogadro sources here. What does it do, i.e. what did it copy from KDE ? Does it a find_package(KDE4) ? Or does it include its own version of FindPackageHandleStandardArgs.cmake ? It has its own copy of FindPackageHandleStandardArgs.cmake, which is used in some of the Find modules. Avogadro is a dependency of Kalzium (KDE Edu), but is C++/Qt based itself. I was more thinking of all the other packages out there that may have done similar, and the fact that we should avoid breaking their builds with a new CMake release. Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro, and KDE4 is not the only project which breaks together with current cmake 2.8.3. This reduces the number of acceptable solutions I think. Remaining are as far as I see: -set new policy CMP0017 to NEW by default Projects with an exotic setup may break, but that's probably better than breaking all KDE 4.5.0/1 builds. One could also argue that these projects relied on internal implementation details of cmake. As a pro, I think this behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense, since we have that dependency but currently it's not enforced. -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also to CMakeParseArguments.cmake and FindPackageMessage.cmake IMO not a solution, just a quick fix for the moment, because we have to maintain this forever in the future and basically we need to check *all* other include()s in CMAKE_ROOT. -rename the enhanced FPHSA to FPHSA2 Worse than above, since this doesn't give any guarantee that the same does not happen again in the next cmake release with the renamed function. Did I miss anything ? 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
2010/10/12 Alexander Neundorf neund...@kde.org On Tuesday 12 October 2010, Marcus D. Hanwell wrote: 2010/10/12 Alexander Neundorf neund...@kde.org On Tuesday 12 October 2010, Marcus D. Hanwell wrote: On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.org wrote: ... Personally, I would try a rc3 with CMP0017 set to NEW and see how it goes. It works for kdelibs and for our project at work (which doesn't have a lot of fancy cmake stuff). If it is just that one file why not go with the simple solution? I would love to see a policy where includes in the same directory would be considered first, and then the normal search behavior. I wasn't sure how feasible this was in an rc3. Avogadro effectively copied what KDE was doing, and so maybe the issue is not that widespread. I don't have the avogadro sources here. What does it do, i.e. what did it copy from KDE ? Does it a find_package(KDE4) ? Or does it include its own version of FindPackageHandleStandardArgs.cmake ? It has its own copy of FindPackageHandleStandardArgs.cmake, which is used in some of the Find modules. Avogadro is a dependency of Kalzium (KDE Edu), but is C++/Qt based itself. I was more thinking of all the other packages out there that may have done similar, and the fact that we should avoid breaking their builds with a new CMake release. Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro, and KDE4 is not the only project which breaks together with current cmake 2.8.3. This reduces the number of acceptable solutions I think. Yes, that is correct. I think it is hard to assess which projects might be broken after release that have not tried an rc. I would not be surprised if quite a few out there might break. Remaining are as far as I see: -set new policy CMP0017 to NEW by default Projects with an exotic setup may break, but that's probably better than breaking all KDE 4.5.0/1 builds. One could also argue that these projects relied on internal implementation details of cmake. As a pro, I think this behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense, since we have that dependency but currently it's not enforced. I would tend to agree with you there. -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also to CMakeParseArguments.cmake and FindPackageMessage.cmake IMO not a solution, just a quick fix for the moment, because we have to maintain this forever in the future and basically we need to check *all* other include()s in CMAKE_ROOT. Agreed. -rename the enhanced FPHSA to FPHSA2 Worse than above, since this doesn't give any guarantee that the same does not happen again in the next cmake release with the renamed function. I think this is the simplest, but I can see why you would rather avoid it. Did I miss anything ? I don't think so. I would go with option 1 or 3. Effectively the policy would be the reverse of most though, and so very confusing - setting it to OLD is more likely to cause breakage than setting it to NEW. This would mean that the standard documentation would not really apply well to this one policy, and it could cause a lot of confusion. I wonder if Brad or Bill have any thoughts on this? Marcus ___ 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
Remaining are as far as I see: -set new policy CMP0017 to NEW by default Projects with an exotic setup may break, but that's probably better than breaking all KDE 4.5.0/1 builds. One could also argue that these projects relied on internal implementation details of cmake. As a pro, I think this behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense, since we have that dependency but currently it's not enforced. -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also to CMakeParseArguments.cmake and FindPackageMessage.cmake IMO not a solution, just a quick fix for the moment, because we have to maintain this forever in the future and basically we need to check *all* other include()s in CMAKE_ROOT. -rename the enhanced FPHSA to FPHSA2 Worse than above, since this doesn't give any guarantee that the same does not happen again in the next cmake release with the renamed function. I think at this point we are going to have to go with FPHSA2. We can work on a longer term strategy for getting around this problem after this current release is done. I want the release to stay on schedule. In the future, I want to setup a Contract with CMake dashboard for KDE so that things like this don't happen again, and we are not forced to pick a sub-optimal solution. This (FPHSA change) has been in CMake next/master since Aug, and we go to do an RC, and we find out we have a problem! I have started to create contract tests. I have a VTK one that is running each night. It will build a known working version of VTK against CMake next. In a few weeks I will announce this to the lists and create a way for projects to setup a contract with CMake test. Anyway, in the short term, we are going to go with FPHSA2, Alex do you have time to do that? -Bill ___ 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, Alan W. Irwin wrote: ... cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR) because you absolutely need CMP0017. I believe most projects (including PLplot) will eventually need that policy as well because there is a tendency to copy and modify CMake find modules to the project's special needs for any mature project. Thus, I assume PLplot will need CMP0017 in the future, but when that occurs I will bump our minimum version to a high enough value so we are assured of having that policy. Am I missing something? Yes. The (currently known) problem is that FPHSA.cmake in cmake had features added in a backward compatible way, but projects which have a copy of an older (e.g. cmake 2.8.2) FPHSA.cmake break, because their older version is not forward-compatible to the one in cmake 2.8.3, and because of the handling of CMAKE_MODULE_PATH their old, not-forward compatible version is confronted with the parameters for the new version, which they cannot handle. The new CMP0017 would *by default change* the behaviour, in order to avoid that breakage. What could break: projects, which * have a copy of some cmake module shipped with cmake in their CMAKE_MODULE_PATH * AND which rely on the fact that when include()ing/find_package()ing some other module shipped with cmake (where they don't have a copy of), that this called module (from CMAKE_ROOT) gets their own copy of the previously mentioned module loaded when it does a include()/find_package() I think such constellations should be quite rare. Such projects would break. They could be fixed again by either setting CMP0017 to OLD, or by having the full chain of cmake modules as a copy. E.g. if they rely on FindPNG.cmake getting their own copy of FindZLIB.cmake, they would have to include also FindPNG.cmake in their sources. 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, Bill Hoffman wrote:
Remaining are as far as I see:
-set new policy CMP0017 to NEW by default
Projects with an exotic setup may break, but that's probably better than
breaking all KDE 4.5.0/1 builds. One could also argue that these projects
relied on internal implementation details of cmake. As a pro, I think
this behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT)
makes sense, since we have that dependency but currently it's not
enforced.
-hardcode the path to FPHSA.cmake in the find-modules in cmake, probably
also to CMakeParseArguments.cmake and FindPackageMessage.cmake
IMO not a solution, just a quick fix for the moment, because we have to
maintain this forever in the future and basically we need to check *all*
other include()s in CMAKE_ROOT.
-rename the enhanced FPHSA to FPHSA2
Worse than above, since this doesn't give any guarantee that the same
does not happen again in the next cmake release with the renamed
function.
I think at this point we are going to have to go with FPHSA2.
We can work on a longer term strategy for getting around this problem
after this current release is done. I want the release to stay on
schedule.
In the future, I want to setup a Contract with CMake dashboard for KDE
so that things like this don't happen again, and we are not forced to
pick a sub-optimal solution. This (FPHSA change) has been in CMake
next/master since Aug, and we go to do an RC, and we find out we have a
problem!
I have started to create contract tests. I have a VTK one that is
running each night. It will build a known working version of VTK
against CMake next. In a few weeks I will announce this to the lists
and create a way for projects to setup a contract with CMake test.
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_CURRENT_LIST_DIR
where I implemented the option with the hardcoded paths:
-INCLUDE(FindPackageHandleStandardArgs)
+INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
This doesn't introduce a macro with a new name (i.e. without an appended 2)
which we then have to maintain forever, and makes also sure that the correct
FPHSA.cmake is loaded by cmake 2.8.3 (which FPHSA2 does only for cmake 2.8.3,
but not for coming cmake 2.8.3, and I think it is quite likely that
FPHSA()/FPHSA2() will get more options in coming releases)
Even while I think this is not a good solution, it is a safe short-term fix,
and we can figure out for 2.8.4 how we should handle CMAKE_MODULE_PATH in the
long term.
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
2010/10/12 Alexander Neundorf neund...@kde.org: On Tuesday 12 October 2010, Marcus D. Hanwell wrote: 2010/10/12 Alexander Neundorf neund...@kde.org It has its own copy of FindPackageHandleStandardArgs.cmake, which is used in some of the Find modules. Avogadro is a dependency of Kalzium (KDE Edu), but is C++/Qt based itself. I was more thinking of all the other packages out there that may have done similar, and the fact that we should avoid breaking their builds with a new CMake release. Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro, and KDE4 is not the only project which breaks together with current cmake 2.8.3. This reduces the number of acceptable solutions I think. Remaining are as far as I see: -set new policy CMP0017 to NEW by default Projects with an exotic setup may break, but that's probably better than breaking all KDE 4.5.0/1 builds. One could also argue that these projects relied on internal implementation details of cmake. As a pro, I think this behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense, since we have that dependency but currently it's not enforced. -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also to CMakeParseArguments.cmake and FindPackageMessage.cmake IMO not a solution, just a quick fix for the moment, because we have to maintain this forever in the future and basically we need to check *all* other include()s in CMAKE_ROOT. -rename the enhanced FPHSA to FPHSA2 Worse than above, since this doesn't give any guarantee that the same does not happen again in the next cmake release with the renamed function. Did I miss anything ? Yes there is another not-so-pleasant option: - revert CMake's FPHSA changes in order to stay compatible with 2.8.2 one and KDE and other currently annoying project w.r.t. FPHSA The incompatible improvement of FPHSA may be postponed to 2.8.4, and we will have to design a good solution and warn all project about bad habits before 2.8.4. Suggesting this I'm don't even know how much impact it has on CMake-shipped modules, i.e. how many modules do currently use the new FPHSA? If the idea is plain stupid just forget my mail, I genuine want to be positive on this issue not trying to shot on others efforts (Alex in this case) to improve CMake. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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 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_CURRENT_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. macro with a new name ... which we then have to maintain forever It's not too bad. The new name has the new API. The original FPHSA module can just include the new one and forward calls appropriately. Any call to the original FPHSA will either go through the CMake version of it and forward to FPHSA2 or go through a project-overridden one. Any call to the FPHSA2 will either go through the CMake version or through one overridden by a project aware of the new API. This isn't perfect but it is 100% compatible with current project 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
Re: [cmake-developers] User vs CMake include mismatch handling
On Tuesday 12 October 2010 17:27:31 David Cole wrote: On Tue, Oct 12, 2010 at 5:21 PM, Brad King brad.k...@kitware.com 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. macro with a new name ... which we then have to maintain forever It's not too bad. The new name has the new API. The original FPHSA module can just include the new one and forward calls appropriately. Any call to the original FPHSA will either go through the CMake version of it and forward to FPHSA2 or go through a project-overridden one. Any call to the FPHSA2 will either go through the CMake version or through one overridden by a project aware of the new API. This isn't perfect but it is 100% compatible with current project 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. 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. I like the malloc analogy, and think it holds here. We do have a certain responsibility to maintain API compatibility, and having a new function seems like the best way to achieve that for the release. Going forward, versioned include files, or preference towards local files might be the way to go. Marcus ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
