[CMake] subject changed: question about which bugs you're talking about

[Alexander Neundorf]

On Wednesday 11 January 2012, David Cole wrote:
> On Wed, Jan 11, 2012 at 3:08 PM, Alexander Neundorf
> 
> <a.neundorf-work at gmx.net> wrote:
> > On Wednesday 11 January 2012, Patrick Spendrin wrote:
> >> Am 02.01.2012 18:11, schrieb David Cole:
> >> > Hi all,
> >> > 
> >> > Replies requested. Short replies only. 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.
> >> > 
> >> > Example one-line reply:
> >> >   http://public.kitware.com/Bug/view.php?id=12647
> >> > 
> >> > We are aiming for quarterly releases from now on, scheduling them
> >> > every 3 months. That would make the next release of CMake version
> >> > 2.8.8, scheduled to have an "rc1" release candidate on Wed. March 7,
> >> > 2012 -- just 9 weeks from this Wednesday.
> >> > 
> >> > If you have a particular issue that you think should be fixed for
> >> > inclusion in 2.8.8, please bring it up within the next two weeks.
> >> > Ideally, each issue will be discussed as needed on the mailing list to
> >> > come to any consensus about what should be done to fix it, and then an
> >> > entry in the bug tracker may be used to keep it on the radar screen,
> >> > and to track activity related to it. You can see what's on the roadmap
> >> > for this release here:
> >> > http://public.kitware.com/Bug/roadmap_page.php?version_id=90
> >> > 
> >> > Patches are always welcome. Patches that include testing of any new
> >> > features, or tests that prove a bug is really fixed on the dashboards,
> >> > basically any patch with testing is preferred over a patch with no
> >> > testing. Also, if you are *adding* code, then you also probably need
> >> > to add *tests* of that code, so that the coverage percentage stays as
> >> > is or rises.
> >> > 
> >> > Please discuss issues here as needed, and add notes to existing issues
> >> > in the bug tracker that you are interested in seeing fixed -- we will
> >> > be looking at the mailing list and activity in the bug tracker to help
> >> > prioritize the bug fixes that will occur in the near future.
> >> 
> >> My personal issues are:
> >> http://www.cmake.org/Bug/view.php?id=10994
> >> and connected to it: http://www.cmake.org/Bug/view.php?id=11153
> >> The handling of the windows drive root is not consistent/wrong, which
> >> leads to both errors. I checked yesterday but the patches I added in
> >> 10994 do lead to an endless loop in 11153. I will try to come up with a
> >> better patch in the coming days.
> > 
> > IMO these are quite important issue, since they issue causes every
> > FooConfig.cmake file installed by any of the KDE libraries to contain
> > extra code to work around this issue, which makes them less readable and
> > harder to write (and easier to get wrong).
> > 
> > Alex
> > 
> Are you talking about http://www.cmake.org/Bug/view.php?id=10994 and
> http://www.cmake.org/Bug/view.php?id=11153 ??
> 
> How do these require extra code in your config files?
> 
> I would think putting the CMakeLists file at the root of a drive would
> be quite uncommon.

AFAIK all/most of our KDE-on-Windows developers do this using subst.

Our installed Config.cmake files (not so many yet, but there will be much 
more) have code like this:
get_filename_component(rootDir
                       ${CMAKE_CURRENT_LIST_DIR}/@relInstallDir@
                       ABSOLUTE) # get the chosen install prefix

and because of this bug, they need additionally this line:
+ get_filename_component(rootDir ${rootDir} REALPATH)

This will not make it easier to convince people that the Config.cmake files 
are a good thing, if each of them needs a workaround.

Alex