<div dir="ltr"><div>Brad, below is the list of variables set manually by me before testing QNX SDK environment variables, the qcc will fail if any of them are missing:</div><div><br></div><div>set QNX_CONFIGURATION=d:\opt\qnx-software-systems</div><div>set QNXLM_LICENSE_FILE=@<a href="http://10.144.209.10" target="_blank">10.144.209.10</a></div><div>set QNX_HOST=d:\opt\qnx650sp1\host\win32\x86</div><div>set QNX_TARGET=d:\projects\pasa\ford\r6\QNX_SDK\target\qnx6</div><div>set PATH=d:\opt\qnx650sp1\host\win32\x86\usr\bin;%PATH%</div><div><br></div><div>> Do you mean some kind of dll injection to intercept CreateProcess calls?<br></div><div><br></div><div>I doubt, but that does not mean it does not. I remember errors from Ninja when it was trying to execute "%1" in CreateProcess call, but suspect that was a problem in escape characters in .ninja file.</div><div><br></div><div>I did short research again and would want to explain from scratch.</div><div><br></div><div>1. My story takes start from the existing QNX project based on Makefiles and my effort was to inject CMake into that build tree. QNX SDK always uses Unix environment which means:</div><div>- Makefiles always use Unix syntax</div><div>- environment guarantees that you can use shell scripts in your Makefiles as commands</div><div><br></div><div>2. When you want to reuse existing .sh scripts in your CMake target rules it apparently fails because Ninja does not know how to execute them. QNX SDK make tool does.</div><div><br></div><div>3. The most problematic issue for me was that qcc and gcc tools from QNX SDK cannot run without QNX_HOST and QNX_TARGET variables set. Also qcc will fail if QNX_CONFIGURATION and QNXLM_LICENSE_FILE are missing or license server is not available (but that is another story). CMake build works in two stages: generation and native build. Setting listed env variables at generation stage is absolutely valid. But setting them again later at build stage leads to issues:</div><div>- you need to explicitly load environment variables each time before build</div><div>- if you have multiple QNX SDKs you might accidentally load wrong variable set</div><div>- if you use IDE launched from clean shell with default variables you cannot source env variables saved in some script anymore</div><div>- if you use IDE you probably need to explicitly replicate env variables in some IDE specific way</div><div><br></div><div>CMake has solution to overcome problems like this: cache. But apparently cache does not work when you need to save environment variables which need to be loaded _before_ build starts.</div><div><br></div><div>So the only way to fix that was to wrap compiler into script, that does: a) environment variable setup, b) launch real compiler, forwarding passed arguments to it.</div><div><br></div><div>This wrapper script cannot be common, because for each kind of build env variable set will be different. So it need to be created at CMake generation time saving current QNX* env variables into this wrapper script. So next time you can open clean shell and run 'make' or 'ninja' and it will properly use environment variables defined previously at generation stage.</div><div><br></div><div>I implemented that in my toolchain file, redirecting CMAKE_C_COMPILER to my gcc_wrapper.sh and that was working perfectly for 'Unix Makefiles' generator. 'Ninja' generator was failing because it cannot execute .sh files. Fine, lets replace CMAKE_C_COMPILER="gcc_wrapper.sh" with CMAKE_C_COMPILER="/path/to/sh.exe gcc_wrapper.sh". But that does not work, because CMAKE_C_COMPILER expects full path to executable, not command line. I reworked wrapper as Windows batch file: gcc_wrapper.bat. Now it works under 'Ninja' but fails under 'Unix Makefiles', because QNX SDK make overrides .bat processing somehow.</div><div><br></div><div>Maybe there were another reasons, but at some point I decided that the most appropriate way will be to stop playing with Windows environment. If QNX SDK applications always expect Unix environment we should give it to them. That is why I added 'Unix Ninja' generator that will always use sh as shell tool.</div><div><br></div><div>Thanks,</div><div>Daniel</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 19, 2015 at 2:50 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 01/16/2015 01:13 PM, Daniel Levin wrote:<br>
> The CMake and Ninja were part of the bigger build script,<br>
> which was running under the QNX SDK sh.exe.<br>
> When running under this shell it overrides some environment<br>
> variables (compare attached files).<br>
<br>
</span>The main differences I see are:<br>
<br>
* The Windows shell is a 64-bit cmd and the MSYS one is 32-bit<br>
* PATH has been converted to MSYS-style and prepended with /usr/bin<br>
* Added: QNX_HOST=c:\opt\qnx650-gcc-4.8.1\host\win32\x86<br>
* Added: QNX_TARGET=c:\opt\qnx650-gcc-4.8.1\target\qnx6<br>
* Added: TERM=cygwin, consistent with MSYS shells<br>
* Added: SHLVL=1<br>
* The "TEMP" and "TMP" variables are /tmp instead of the Windows dirs<br>
<br>
So this is a MSYS shell.  AFAIK ninja under MSYS sh.exe normally<br>
works even for pure Windows builds.  Perhaps their shell does more.<br>
<span><br>
> But as far as I remember it also does some nasty launcher overrides,<br>
> intercepting calls to cmd, bat and sh and tries to process them<br>
> somehow else.<br>
<br>
</span>Do you mean some kind of dll injection to intercept CreateProcess calls?<br>
<br>
I'd really like to have a deep understanding of the situation before<br>
adding a lot of escaping code for a specialized environment.  It<br>
may be that ninja simply needs to learn how to isolate itself in<br>
this case.<br>
<br>
Thanks,<br>
-Brad<br>
</blockquote></div><br></div></div>