This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It would expedite adoption & support of new cross compilers if there was a generic way to describe to interface to a cross compiler tool chain - some compilers have very gcc "compatible" arguments for compiling/assembling/linking, but most do not. Having a (XML perhaps) interface to formally describe how to pass arguments of certain functionality to a compiler and how to read the output, files generated, and handle return codes from the executable. So to prepossess with compiler "A" takes this argument and sends it to stdout, where as compiler "B" uses that argument and produces a file pattern based on the input file. These XML files describing the tool collections could then be used in scanning a compiler path and "autodetect" the compiler family. Alternatively, add the IAR (arm) cross compiler/assembler/linker leveraging gmake with CygWin/MinGW as I am really hating the IAR IDE and build interface, prompting me to make this request.
Also, having a method available to share the XML configuration back to the NetBeans community (perhaps in the form of a plugin that can be pushed back out) would also help in adoption, so users are not re-inventing an interface with every installation of the same compiler.
(In reply to comment #1) > Also, having a method available to share the XML configuration back to the > NetBeans community (perhaps in the form of a plugin that can be pushed back > out) would also help in adoption, so users are not re-inventing an interface > with every installation of the same compiler. Please have a look at http://netbeans.org/bugzilla/show_bug.cgi?id=210860
have a look at http://netbeans.org/kb/docs/cnd/toolchain.html as well and there are already some contributed toolchains from community http://plugins.netbeans.org/plugin/36176/cuda-plugin http://plugins.netbeans.org/plugin/27033/msp430-toolchain and even Visual Studio http://plugins.netbeans.org/plugin/42519/?show=true
Some links are dead - like the MSP430 - any chance the references can be updated?
It was quite a struggle and I'm still not able to transparently get something like IAR's compiler to work with the plugin. Reviewing MSVC interface, it actually seems to circumvent the interface by creating a mediator that is the actual plugin and calls out the appropriate installation of MSVC compiler. It seems strait forward to get something like GCC cross compilers to work, but others seems to have a significant hurtle. Is it worth attaching the broken plugin here for review?
(In reply to dgtlrift from comment #5) > Is it worth attaching the broken plugin here for review Yes, please attach plugin. I can review it. Alexander
Created attachment 153958 [details] Plugin attempting to use IAR compiler by detecting settings from registry Attached plugin project attempts to use MinGW Make and IAR compiler. IAR compiler is discovered via "regestry" keys.
(In reply to dgtlrift from comment #7) > Created attachment 153958 [details] > Plugin attempting to use IAR compiler by detecting settings from registry > > Attached plugin project attempts to use MinGW Make and IAR compiler. IAR > compiler is discovered via "regestry" keys. Hi dgtlrift, Could you provide steps to install IAR compiler. I need it to check your plugin. Alexander
https://www.iar.com/iar-embedded-workbench/downloads/ contains the download links for all the cross compiler architectures supported by IAR - approximately 20+ unique instruction sets. Ultimately, my goal is to get the plugin to work generically across all the IAR compilers, but for the short term I've been trying to get it to work with either ARM or Renesas m16c cross compilers. ARM http://supp.iar.com/Download/SW/?item=EWARM-EVAL m16c http://supp.iar.com/Download/SW/?item=EWRX-EVAL The compilers can co-exist and upon installation will create registry keys and all registry information will be stored under: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench Installation of the IAR EW ARM installation will result in registry keys such as: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench\1.0\LIBSRCARM\7.30.1 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench\5.0\EWARM\7.30.1 Installation of the IAR EW Renesas M16c installation will result in registry keys such as: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench\1.0\LIBSRCM16C\3.70.1 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench\6.5\EWM16C\3.70.1 The actual key seems to be based on the compiler version and and IDE version. As a side, the supported architecture cross compilers: Arm Holdings ARM Renesas RX Renesas RL78 Renesas RH850 Renesas V850 Renesas H8 Renesas M16C/R8C Renesas 78K Renesas SuperH Renesas M32C Renesas R32C TI MSP430 Intel 8051 Atmel AVR Atmel AVR32 STMicroelectronics STM8 FreeScale ColdFire FreeScale HCS12 FreeScale S08 Maxim MAXQ Samsung SAM8 National Semiconductor CR16C
Correction - URL for m16c should be http://supp.iar.com/Download/SW/?item=EWM16C-EVAL (In reply to dgtlrift from comment #9) > https://www.iar.com/iar-embedded-workbench/downloads/ contains the download > links for all the cross compiler architectures supported by IAR - > approximately 20+ unique instruction sets. > > Ultimately, my goal is to get the plugin to work generically across all the > IAR compilers, but for the short term I've been trying to get it to work > with either ARM or Renesas m16c cross compilers. > > ARM http://supp.iar.com/Download/SW/?item=EWARM-EVAL > m16c http://supp.iar.com/Download/SW/?item=EWRX-EVAL > > The compilers can co-exist and upon installation will create registry keys > and all registry information will be stored under: > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench > > Installation of the IAR EW ARM installation will result in registry keys > such as: > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded > Workbench\1.0\LIBSRCARM\7.30.1 > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded > Workbench\5.0\EWARM\7.30.1 > > Installation of the IAR EW Renesas M16c installation will result in registry > keys such as: > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded > Workbench\1.0\LIBSRCM16C\3.70.1 > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded > Workbench\6.5\EWM16C\3.70.1 > > The actual key seems to be based on the compiler version and and IDE version. > > As a side, the supported architecture cross compilers: > Arm Holdings ARM > Renesas RX > Renesas RL78 > Renesas RH850 > Renesas V850 > Renesas H8 > Renesas M16C/R8C > Renesas 78K > Renesas SuperH > Renesas M32C > Renesas R32C > TI MSP430 > Intel 8051 > Atmel AVR > Atmel AVR32 > STMicroelectronics STM8 > FreeScale ColdFire > FreeScale HCS12 > FreeScale S08 > Maxim MAXQ > Samsung SAM8 > National Semiconductor CR16C
Created attachment 154021 [details] proposed patch for tool collection The patch fixes: - layer - package name - tool collection flavor I tested it on ARM. IDE can detect tool collection. 2 problems: - tool collection options should be changed. IDE cannot compile simple application. - IDE need a "default model" (predefined include paths and macros). IDE detect model by executing compiler with special options. Your tool collection inherits GNU options. "-x c -E -v" for include pats and "-x c -E -dM" for macros. It does not work with your tool collection.
(In reply to Alexander Simon from comment #11) > Created attachment 154021 [details] > proposed patch for tool collection > > The patch fixes: > - layer > - package name > - tool collection flavor > > I tested it on ARM. > IDE can detect tool collection. > > 2 problems: > - tool collection options should be changed. IDE cannot compile simple > application. > - IDE need a "default model" (predefined include paths and macros). IDE > detect model by executing compiler with special options. Your tool > collection inherits GNU options. "-x c -E -v" for include pats and "-x c -E > -dM" for macros. It does not work with your tool collection. Thanks for this - it has been a great help. I see I will have to update the interface for the compiler arguments and will dig into that. I have gotten the pristine patched plugin to register and find the compiler - sometimes. To clarify, from 8.0.2 release, I can't (as of yet) get the installed plugin to see the compiler by navigating to Options->C/C++->Build Tools->Restore Defaults. From the mercurial head of cnd-main, and single stepping against org.netbeans.modules.cnd.toolchain.compilerset via "C/C++ Tool Collection" I have been able to get it to register using the same interface occasionally. Is it possible there's some race condition or timeout in the registry lookup? Perhaps something with the readRegistry method and the cache management implementation? What other information or logging can I activate to trace the inconstancy in behavior? Thanks much, -Jim
(In reply to dgtlrift from comment #12) > Is it possible there's some race condition or timeout in the registry > lookup? Perhaps something with the readRegistry method and the cache > management implementation? > > What other information or logging can I activate to trace the inconstancy in > behavior? This additional java options: -J-Dcnd.toolchain.personality.trace=true -J-Dnativeexecution.support.logger.level=FINEST turn on registry keys logger and execution logger. IDE prints: Read registry hklm\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench\5.0\EWARM HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IAR Systems\Embedded Workbench\5.0\EWARM InstallPath REG_SZ C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2 Found C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2 Path [C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\bin] belongs to tool chain IAR FINEST [nativeexecution.support.logger]: [42987 ms.] localhost /cygdrive/C/Program\ Files\ \(x86\)/IAR\ Systems/Embedded\ Workbench\ 7.2/arm/bin/iccarm.exe "-x" "c" "-E" "-v" "C:\\Users\\alex\\AppData\\Local\\Temp\\xyz7669234314302165365.c" [4420]: State changed: RUNNING -> FINISHING FINEST [nativeexecution.support.logger]: [42987 ms.] localhost /cygdrive/C/Program\ Files\ \(x86\)/IAR\ Systems/Embedded\ Workbench\ 7.2/arm/bin/iccarm.exe "-x" "c" "-E" "-v" "C:\\Users\\alex\\AppData\\Local\\Temp\\xyz7669234314302165365.c" [4420]: State changed: FINISHING -> FINISHED FINEST [nativeexecution.support.logger]: [42987 ms.] localhost /cygdrive/C/Program\ Files\ \(x86\)/IAR\ Systems/Embedded\ Workbench\ 7.2/arm/bin/iccarm.exe "-x" "c" "-E" "-dM" "C:\\Users\\alex\\AppData\\Local\\Temp\\xyz7669234314302165365.c" [0]: State changed: INITIAL -> STARTING .... By the way NB 8.0.2 is failed to read registry key with space. Only NB development build can read registry key with space.