In the process of switching from Keil uVision into arm Development Studio, and working with the mbed library, I was bitten by the 8191 chars command line length limit of Windows.
The mbed library contains many include folders and the resulting armclang command line including all such paths is well beyond the 8191 chars allowed by cmd.exe (now it is around ~20000 chars in length, and that for the baremetal profile of mbed), so it is truncated by the OS resulting in armclang refusing to compile a thing.
Has anyone coped with this?
For now I managed this using symlinks in the filesystem, a manual and error prone approach. I'm aware of the @file armclang option allowing armclang to get command line arguments from a file. Is there a way to force arm DS to use such mechanism? Any other approach?
Thanks and regards.
Although I've fixed my problem with this approach, it is not a perfect solution. The environment is not aware of the contents inside the @file, so if you put there some include paths or symbols, the IDE doesn't see them and can flag errors in your code. Of course compilation works, they are simply "fake" errors.
I'm curious about how does Keil uVision to cope with this.
Thanks & regards.
Yes, you are right that the IDE might report indexing errors for include paths or symbols for which it has no visibility, but you can add them into the project directly yourself via Properties > C/C++ General > Paths and Symbols, then select either the Includes tab or the Symbols tab.
This is a manual step, so if the include paths or symbols in the @file change, then you'll have to remember to change them in the Properties too.
You asked "I'm curious about how does Keil uVision to cope with this."Keil uVision generates via files for the compiler and the linker per file when building a project. They are mentioned here: developer.arm.com/.../B--File-TypesSee Build Files "*._AC, *._IA, *.__I, *._II, *.SCR: tool invocation files." and usually located in the Objects folder.