[cmake-developers] [CMake 0011307]: Xcode generator does not recognise *.hh files correctly

2010-10-12 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11307 == Reported By:dsieger Assigned To:

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Alexander Neundorf
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Alexander Neundorf
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Marcus D. Hanwell
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:

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Bill Hoffman
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Alexander Neundorf
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Alexander Neundorf
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Eric Noulard
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Brad King
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

Re: [cmake-developers] User vs CMake include mismatch handling

2010-10-12 Thread Marcus D. Hanwell
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