[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cmake
Subject:    Re: [CMake] globs case sensitivity depends on platform
From:       🐋_Jan_Hegewald <jan.hegewald () awi ! de>
Date:       2016-01-29 10:08:25
Message-ID: 1893C4E2-A3D4-4D75-B7D1-45335317F376 () awi ! de
[Download RAW message or body]

Hi Andreas,

thanks for bearing with me (-:

> On 28.01.2016, at 20:28, Andreas Pakulat <apaku@gmx.de> wrote:
> 
> Hi Jan,
> 
> On Thu, Jan 28, 2016 at 4:52 PM, 🐋 Jan Hegewald <jan.hegewald@awi.de> wrote:
> Hi Andreas,
> 
> > On 28.01.2016, at 16:43, Andreas Pakulat <apaku@gmx.de> wrote:
> > 
> > Hi Jan,
> > 
> > On Thu, Jan 28, 2016 at 2:35 PM, 🐋 Jan Hegewald <jan.hegewald@awi.de> wrote:
> > Hi Nils,
> > 
> > > On 28.01.2016, at 13:39, Nils Gladitz <nilsgladitz@gmail.com> wrote:
> > > 
> > > You might already be aware but CMake discourages using GLOB for source files
> > 
> > yes, I read the docs before posting (:
> > Avoiding glob would be a workaround to my problem. But anyway I think that glob \
> > is broken if it produces different results on different platforms. 
> > I can't find any docs on cmake.org about what a globbing-expression is exactly, \
> > but the docs for file(glob) at least don't say anything about this function \
> > producing the same results on different platforms. In fact I'd be surprised if \
> > the behavior of the file(glob) function is different than using the same \
> > wildcards with ls/dir on a terminal.
> 
> the cmake glob is different from the results of a terminal ls
> 
> On the Mac apparently (based on your first mail)

Yes, on the Mac. ls behaves the same on both platforms.

> 
> > The only bug that I can see from your description is that the behavior is \
> > inconsistent with different types of FS on OSX, that is definetly not matching \
> > above mentioned expectation.
> 
> Maybe I was unclear about this, but cmake glob ignores the case regardless of the \
> FS being case sensitive or not. 
> Now that contradicts your initial mail, you said there that on OSX you get F* and \
> f* files for a case-insensitive filesystem, but on Linux you get only F*. But you \
> also said that a case-sensitive filesystem on OSX still gives you F* and f* files, \
> which in my eyes is a bug in the implementation.

Yes. On the Mac I get the same unexpected results for case sensitive and case \
insensitive FS (i.e. glob returns files with different cases).

> 
> I also just checked the CMake sources quickly and it seems that the glob-support is \
> completely 'inhouse', meaning it does not call out to platform-specific functions \
> (I guess that would explain the discrepancy on OSX). 
> So I guess asking for the same behavior across platforms is just as reasonable \
> (given the logics are fully under CMake's control) as asking for it to reflect what \
> a ls/dir would do on the corresponding platform. 
> I think a bugreport is the correct next step, even if it merely leads to a \
> clarification of the behavior in the documentation. 
> Andreas

OK, I did that: https://public.kitware.com/Bug/view.php?id=15941

FYI, regarding the specification of glob patterns there is \
https://public.kitware.com/Bug/view.php?id=8814

Best,
Jan

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


[prev in list] [next in list] [prev in thread] [next in thread]