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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-06 06:08:22

Jim Douglas wrote:
> 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.

Ok. I know nothing about the QNX6 platform. Are there any specific 
options you need to pass to the gcc and intel compilers to do the 
cross-compile and/or naming/location differences?

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

They are on the way :). Dave and Volodya have been making some progress, 
so stay tuned :).

>> 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... :-)

What I meant was that BBv2 imported those things, so it is now possible 
(in BBv2) to say:

    bjam msvc-8.0 address-model=64

to use the x86-amd64 cross-compiler that comes with VC8. The GCC stuff 
to process architectures hasn't (yet!) been ported.

>> 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.

Sure.

>> 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.

Cool.

>> 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?

Volodya (Vladimir Prus) is the chief honcho - he knows a lot about the 
inner workings of this complex beast. Dave (David Abrahms) is the next 
in line. Rene (Rivera) knows a lot about bjam (upon which BBv1 and v2 
are built). Also, see the copyright notices on the various jam files.

Then there are others who know a little about how BBv2 works. Alexey 
Pakhunov, Andrey Melnikov and I have been working on improving the msvc 
toolset. I have also added support for warnings and (with the help of 
Rene) added some neat response file logic allowing @(FILE:E=contents) 
style syntax that has replaced the old response file logic.

Anyone is free to contribute toolsets and/or bug fixes. Just provide the 
patch or toolset file (if it is new) and people will comment on it.

My advice for trying to extend BBv2 is to read the documentation, look 
at the BBv2 Wiki and look at how the other tools are written to see how 
they work. Observing on this list is another good way to pick up how 
BBv2 works. Then start small and work up.

Also, for QNX6 support, a good place to start is to see how BBv1 does 
it. Find out what is being changed to get that support and then try and 
apply those differences to BBv2 or see if BBv2 already supports what you 
are after.

- Reece