2 ms·
The simple hack is a softlink to the actual SDK. On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;) Link issue
by zh3 3y ago
The simple hack is a softlink to the actual SDK.
On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;)
Link issue was possibly macro craziness? The scars of sdk_config.h etc.
- fullstop 3y agoIf you base your project off of one of the examples, the project file has relative paths back to the SDK. For example: <file file_name="../../../../../../components/libraries/log/src/nrf_log_backend_rtt.c" /> No amount of symlinking can fix this, and there's a lot of these files. Maybe copying an example project is not the right way to do things. The link issue was, I think, the result of what Nordic does with weak symbols. I don't recall the symbol name, but it was something which caused very unusual results. Regarding LoC tallies, I often try to minimize mine. :-)
- zh3 3y agoIf you're using segger, a quick find-and-replace will take care of that (ditto GCC Makefiles). Must admit that when I started with nrf52 SDK, I too used thge embed-the-application-inside-the-SDK approach. Pretty soon that got cumbersome, so I switched to the softlink approach. The exact approach is to store the SDK somewhere, create a softlink to it in the project directory and have the project files/makefiles use that instead.