[bug report] SDK v12 has filename capitalization changes that break gcc toolchain

[butch]

1. components/toolchain/gcc/*.S should be *.s
2. components/toolchain/CMSIS/Include is now named ...cmsis/include.

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:

1. 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.

2. 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.

[Susheel Nuguru]

which projects did you compile?

[Susheel Nuguru]

tested it, it is a bug and i reported it. Adding to SDK 12 known issues

[Rune Holmgren]

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.

[butch]

OK. My project is Blinky, I am just starting, I don't need a proper fix yet. To restate: the fix proposed by the original poster, to rename the .S file to .s is NOT A PROPER WORKAROUND.

[butch]

Holmgren: I don't understand why the preprocessor would run on .S? I have never heard of that (but I am more familiar with C, and don't really know whether the "C" macro preprocessor also runs on assembly language source.) Also, if Windows ignores case, how would that work, i.e. how would the toolchain distinguish between .S and .s (in fact, only one of foo.S or foo.s could exist, and I would think any toolchain that ran the C-preprocessor on a .S file would also be running it on .s files (without apparent effect if the file included no preprocessor statements.) Again, I could be wrong, just food for thought.