[Qt-creator] Using QtCreator without GCC installed, which toolchain to configure?

[André Pönitz]

On Wed, Aug 22, 2012 at 03:44:23PM +0300, Diego Iastrubni wrote:
> Hi Tobias,
> 
> I am trying to use QtCreator to *edit* code to be compiled using IAR Embedded
> Workbench  for ARM (*). Compilation integration is trivial by running a utility
> by this vendor (easy to setup in QtCreator). This is not a supported compiler
> by Qt, and I am not compiling a Qt application (duh!). They provide an IDE, but
> its a full piece of unusable shit. I actually prefer coding under linux using
> QtCreator and then pushing code to a remote git branch). Ah yes, we use git,
> and this IDE does not support GIT - which makes my life harder.
> 
> The headers for this compiler are available in:
> %PROGRAM FILES%\IAR Systems\Embedded Workbench 6.4\arm\inc\c
> %PROGRAM FILES%\IAR Systems\Embedded Workbench 6.4\arm\inc\{board} (in my case
> ST, but not relevant).
> 
> There are also some other pre-defined macros and intrinsic functions defined
> when compiling using this compiler.
> 
> Regarding the error finding in the compilation output, lets assume that I will
> get bored and do it myself (should not be that hard, might even be fun). But
> this is not my problem:
> 
> I expected that the code model would work even without knowing the exact
> toolchain.

As Tobias explained, the compiler is asked for some basic information,
like pre-configured include paths and pre-defined macros.

Run "echo | gcc -E -xc++ -v -dM -" to get an impression of what is needed.

Without that information there's no reliable way to seed the code model.
Which "stdio.h" will be used (a quick check on my local machine shows
26 of these beasts)? Which "branch" inside /usr/bin/stdio.h should be
used? The __USE_XOPEN2K one? Or not?

> Ok, so it will not know what "open", "snprintf" and others. But all
> my own classes and functions? As far I understand, those should be well defined
> and known to the code parser right?

Why? Depends on the #include'd stuff.


> (/me will try using gcc as a toolchain and report again in a day or two).

You could try to set up a 'fakegcc' script that just outputs the equivalent
of the command above and point the "Compiler Path" setting of a clone
of a GCC-like tool chain to that script.

Andre'