On Windows OS, this might not matter, but on Linux and OSX using gcc toolchain, it may break existing build systems e.g. the Makefiles in the examples.
If Nordic is trying to follow a convention of all lower case filenames, then (1) could be fixed in the name of the file, and (2) could be fixed by changing all example Makefiles, where they define include paths to "CMSIS/Include". This is a suggested fix for Nordic, and a workaround for readers. There might be better fixes.
The symptoms are:
make emits "no rule to make _build/gcc_startup_nrf52.o" because the Makefile rule specifies .s which does not match the .S of the source file.
compiler emits "core_cm4.h: No such file or directory" because the include paths point to a directory "CMSIS/Include" which does not exist.
This regression seems to have occurred since yesterday.
Hi, I have not had time to look into the details of this issue, but based on your report we will have to look into the Makefiles and resolve the issues there. The difference between a .S and a .s file is that the preprocessor will run on .S files before the assembler runs. To support preprocessor usage in .S files, they need to be named as they are in SDK 12.0.