From cmake Thu Jan 28 19:28:11 2016 From: Andreas Pakulat Date: Thu, 28 Jan 2016 19:28:11 +0000 To: cmake Subject: Re: [CMake] globs case sensitivity depends on platform Message-Id: X-MARC-Message: https://marc.info/?l=cmake&m=145400960307432 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0256710708==" --===============0256710708== Content-Type: multipart/alternative; boundary=001a113a90ee56767c052a69eb5b --001a113a90ee56767c052a69eb5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jan, On Thu, Jan 28, 2016 at 4:52 PM, =F0=9F=90=8B Jan Hegewald wrote: > Hi Andreas, > > > On 28.01.2016, at 16:43, Andreas Pakulat wrote: > > > > Hi Jan, > > > > On Thu, Jan 28, 2016 at 2:35 PM, =F0=9F=90=8B Jan Hegewald > wrote: > > Hi Nils, > > > > > On 28.01.2016, at 13:39, Nils Gladitz wrote: > > > > > > You might already be aware but CMake discourages using GLOB for sourc= e > 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 platfor= ms. > > > > 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 th= is > function producing the same results on different platforms. In fact I'd b= e > 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) > 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 regardles= s > 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. 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 --001a113a90ee56767c052a69eb5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jan,

On Thu, Jan 28, 2016 at 4:52 PM, =F0=9F=90=8B Jan Hegewald <jan.h= egewald@awi.de> wrote:
Hi A= ndreas,

> On 28.01.2016, at 16:43, Andreas Pakulat <apaku@gmx.de> wrote:
>
> Hi Jan,
>
> On Thu, Jan 28, 2016 at 2:35 PM, =F0=9F=90=8B 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 s= ource 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&= #39;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)<= /div>

> 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 m= atching above mentioned expectation.

Maybe I was unclear about this, but cmake glob ignores the case rega= rdless of the FS being case sensitive or not.

Now that contradicts your initial mail, you said there that on OSX y= ou 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 stil= l gives you F* and f* files, which in my eyes is a bug in the implementatio= n.

I also just checked the CMake sources quickly a= nd it seems that the glob-support is completely 'inhouse', meaning = it does not call out to platform-specific functions (I guess that would exp= lain the discrepancy on OSX).

So I guess askin= g for the same behavior across platforms is just as reasonable (given the l= ogics 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
--001a113a90ee56767c052a69eb5b-- --===============0256710708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 --===============0256710708==--