Case sensitivity in ConfigurableFileCollection


(Shahji) #1

On Windows, following two snippets behave differently. Is this an expected behavior i.e. by design? Windows is case insensitive OS and so I would expect gradle to account for that and handle it gracefully.

source.from project.fileTree(dir: 'src', include: 'abc.cpp') // Notice the file name is all lowercase
source.from project.fileTree(dir: 'src', include: 'Abc.cpp') // Notice that the file is Pascal case

The file on disk is named ‘Abc.cpp’. In the former case, the file isn’t picked up and is not part of the source set but it is in the latter case.

(Daniel Lacasse) #2

Hi @Shahji,

Gradle doesn’t do any additional effort in handling case insensitivity between OS. A general rule of thumb is to write what you mean. This means that if on the file system it’s Pascal case, then write it as Pascal case. Asserting for such behavior would have a performance impact and would need to reimplement lots of the libraries we use. I’m not saying we can’t do it, it’s just we don’t have a strong enough case for such feature and optimization.

What would be your use case aside from catching errors early?



(Shahji) #3

The specific use case had to do with missing header in output from cppHeaders task for native builds. The header was named with extension ‘.H’ instead of ‘.h’ and windows explorer wasn’t showing file extensions so it wasn’t immediately obvious as to why the file wasn’t getting included. Another instance I ran into similar problem was when a dependency was included with mismatch casing (lua vs. Lua).

Also, its about expectations. I wasn’t expecting casing to be an issue when I was debugging these issues on Windows.

We have certain tools that generate source code during build pre-step and, unfortunately, the files are generated with different casing on different platforms (lower case snake casing on Unix/Linux and Pascal casing on Windows). With this new knowledge , we have some tools to fix for successful migration.

(Daniel Lacasse) #4

It’s a very good point and you are right it’s a common gotcha when dealing with multiple OS. I think what we could do is warn about case mismatch on case-insensitive platforms. On case-sensitive platforms, we wouldn’t be able to help in any way except with the current behavior which is crashing with file not found. We could still improve the error message by suggesting the other case file name.

Although it’s a valid feature (I opened this issue to track the feature), it could be a good idea to look for an alternative solution such as a wrapper to the process that warns about case sensitivity mismatch. I know on Windows it’s possible to catch all file open and execute some post-processing. You could roll your own solution with Procmon, filter on Gradle processes and post-process the event stream to catch any case mismatch. It will slow down the build so I would suggest you add a CI pipeline that checks just that if you need it to be automated or something similar.