But this wasn’t in our short/mid-term plans and for sure requires testing and some development, which volume might grow depending on results of testing, so can’t promise/guarantee/estimate this right now. We can consider changing build-wrapper and plugin to rely on invocation of cc1 “frontend” instead of “driver”. SEGGER Evaluation Software for Nordic Semiconductor nrF52-DK 1. And so build-wrapper recognizes “driver” and ignores “frontend”.Īccording to your log: emBuild.exe doesn’t use “driver” and executes “frontend” cc1.exe directly, what perfectly explains why JSON is empty - this is simply not supported.Īccording to content of “SEGGER Embedded Studio for ARM 3.40” they even don’t provide GCC “driver”, only “frontend”. Typical usage/interaction with GCC by build-system or by user happens via executables gcc or g , so called “driver”, which in his turn uses other executables, in particular cc1, so called “frontend” that is not intended to be used directly by user. I’ll assume that discussion is still about “SEGGER”, log is correct, while “batch file” is unrelated/typo. Seems that there is inconsistency between what you provide as content of “batch file” - “IAR”, topic of discussion and content of logs - “SEGGER”. This is Nordic’s officially supported IDE, so it is good to test with if you are having issues. Vojtech.vladyka: :: BUILDER-PATH is where IAR is installed used for building, C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\common\bin\IarBuild.exe In addition to using CLion for debugging, it’s sometimes useful to use Segger Embedded Studio (SES). JSON is completely useless in cases when compiler is not recognized, while log is quite useful, so please provide file build-wrapper.log (file next to json) to help us understand why compiler is not recognized as GCC or Clang. To run the examples in a build environment based on SEGGER Embedded Studio (SES): Connect the Development Kit with the USB cable to your computer. For another example there is ArmClang compiler based on Clang, but it manifests itself differently than Clang and in some cases even behaves differently, so changes were required in both build-wrapper and plugin.īased only on documentation seems that Segger Embedded Studio is indeed, as you say, based/uses GCC and Clang. For opposite example there is WindRiver compiler based on GCC, however changes in build-wrapper were required for recognition of this compiler as GCC. For example AFAIK there was absolutely no problems with GCC from Android NDK. While we support various derivatives of GCC and Clang, there are corner cases. What really matters - is compiler used under the hood and its invocation from build system. Underlying compiler is GCC or LLVM, but it is encapsulated by emBuild.exe which is acting as make.īuild system (whether it is make, ninja, nmake, msbuild, scons, bazel, gradle, just bash or cmd, or whatever else) is mostly doesn’t matter for build-wrapper.
0 Comments
Leave a Reply. |