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

[Patrick Spendrin]

Am 11.01.2012 21:25, schrieb David Cole:
> 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
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
> 
> 
> 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. Why is the workaround mentioned in the bug
> insufficient?

See the explanation Alex gave - the issue is not only that files are at
the root of the drive, but also that if you have the root of the drive
in your variable, get_filename_component behaves differently (see bug
10994 which is exactly about that).
The point why subst is used is rather easy: building with
mingw+mingw32-make will lead to the restriction of ~6000 chars in
commandline (a restriction of the windows cmd.exe). Some packages we
build (kdelibs, digikam) currently are able to hit this number of
characters which makes *every* character our paths are shorter really
valuable.

regards,
Patrick