I have a concern with the MX generator regarding `SystemClock_Config()` in that it's Visibility option can't be enabled, nothing happens when it's clicked. I'm using the "Separate .c/.h files per peripheral" option and the "Don't generate main()" option for better portability and c++ compatibility where I write my own `main.cpp` that doesn't interfere with the autogenerated files in any way other than importing them.
When these options are enabled, `SystemClock_Config()` remains in the autogenerated `main.c` file, non-static, but the `main.h` does not contain the declaration so it's unreachable unless it's declared somewhere. I find making the declaration in my `main.cpp` quite ugly as from my perspective it's the job of the generator to provide usable header declarations. I'm also quite surprised that the function remains in `main.c` when the "Don't generate main()" option is used, I would expect a pair of `rcc.c` and `rcc.h` files to house this function.
For this reason, I've "hacked" the declaration into the following section of `main.h`:
/* USER CODE BEGIN EFP */
void SystemClock_Config(void);
/* USER CODE END EFP */
This is also kind of ugly, the same ad-hoc declaration still exists in the autogenerated `main.c` (along with the definiton of course), but it will survive the MX code generation. Still, I'm touching the autogenerated files and I deeply dislike this approach. To me, the fact that autogenerated files are allowed to be touched in "user code" blocks by developers is a fundamentally bad design choice from the perspective of software development anyway, but it could be another topic of discussion.
In general, I'm not sure why `main.c` and `main.h` are generated at all when the above options are used, it's misleading as the `main()` is no longer defined therein. There are some handler stubs remaining in `main.c` but a similar argument could be made that they should come in another source/header pair, maybe `handler.c` and `handler.h`.
Can someone clarify this situation, is it a known shortcoming?
