Re: [Boost-build] [BBv2][QNX6] cross compilation of the libs on Windows

From: Jim Douglas (jim_at_[hidden])
Date: 2005-11-06 05:10:08

Reece Dunn wrote:
> Jim Douglas wrote:
> 
>>I understand that BBv2 suppports cross-compilation. I would like to try 
>>building the libraries for QNX6 on the Windows hosted development 
>>system. Kindly give me some pointers as to where to start.
> 
> If I understand correctly, QNX6 uses a variant of the GCC compiler 
> (qcc).

On the Windows cross-development platform QNX6 has gcc 2.95.3, gcc 3.3.5 
and the Intel 8.1 compilers; it also had the appropriate (to the 
compiler) GNU std lib and a universally available Dinkum std lib. So 
selecting the desired combination is a must-have.

> This can be done in the user-config.jam file when you do the 
> setup. See the GCC toolset for more information, but it will be 
> something like:
> 
>     using gcc : 3.4 : qcc ;

Are there any decent instructions yet? I can't find any.

> There is also support for BBv1 architecture, instruction-set and 
> address-model in place, but they aren't currently used by the GCC toolset.

IMHO It would be better to go with v2. v1 is struggling to cope... :-)

> Volodya: the gcc toolset processes gnu, sun and *darwin* as values for 
> link-flags, but only mentions gnu and sun.
> 
> 
>>Is it possible to perform the run-timr tests on a remote platform?
> 
> You can copy the executables over and run them there :). However, AFAICS 
> there is no support in the testing framework for remote deployment and 
> execution.
> 
> This would be useful and would require the test engine to:
> 1.  copy the test executable to the target machine(s);
> 2.  remote execute the tests on those machines;
> 3.  copy the test results back to the test runner;
> 4.  process the tests as normal.

Or, be able to build all the libs and test executables as phase 1. 
Transfer these to the target machine and run (phase 2). Then merge the 
two sets of results (phase 3). This would then permit a delay and/or 
manual intervention between the phases should remote execution prove to 
be difficult or impossible.

> IIUC, this would mean querying the target computer for its operating 
> system then using that OSes remote execution logic...

No need to query - it should be part of the specification at the start 
of the tests.

> You would need to specify the username/password to use on the target 
> machine that allows remote execution.

Good point, but not always necessary for QNX. It has some proprietry 
connection tools that assume you are not exposed on a public network 
during development.

> Personally, remote execution of tests would be a very cool feature, 
> epecially if you could remote execute non-test executables (e.g. custom 
> build regression test programs) and scripts (for automated testing).

Who are the key players for BBv2?

Jim