|
|
Boost Testing : |
From: Jim Douglas (jim_at_[hidden])
Date: 2005-11-02 05:16:50
John,
Permit me to take one step back and recap on some details about QNX
before we proceed further. Forgive me if you know this stuff already.
QNX is a real-time OS for processors doing real work 24/7 as opposed to
sitting on a desk idle for 99.9% of the day. It is Unix-like on the
surface but very different underneath. It has all the standard shells
and the development environment generally conforms to the Unix/Linux model.
QNX is supposed to be 110% POSIX compliant as I understand that they are
very active in setting the standards. So, if you stand by your statement:
"I see that the first failure is because there is no nl_types.h. QNX is
basically lying here: nl_types.h is *required* for any system defining
_XOPEN_VERSION == 500 (as QNX apparently does), so BOOST_HAS_NL_TYPES_H
gets set in posix_features.hpp."
I will raise it with QNX and see what they have to say. A reference to
justify the point would be very helpful.
Initially QNX only ran on x86 hardware, but it now also runs on MIPS,
PowerPC, SH-4, ARM, StrongArm and Intel® XScale™ Microarchitecture.
Software development can be self-hosted or cross-developed under Windows
or Linux (to be axed with the next major release). The "top of the
range" IDE is Eclipse based (and very nice too :-)
For development you have a choice of gcc 2.95.3, gcc 3.3.5 or Intel 8.1
(Windows only) compilers. You can use the GNU C++ std libraries
appropriate to the GNU compiler or you can use the Dinkumware C++ std
lib. Dinkumware also comes in 6 variants: full, abridged, embedded; all
with and without exceptions.
In my so far brief encounter with Boost I am beginning to suspect that
the introduction of QNX as a supported OS will call into question a
number of the assumptions on which the configuration and compile-time
tests are based. I don't yet have enough Boost experience to know which
issues are critical to QNX acceptance, and it is perfectly possible I
may be wrong about some topics. Here are my observations:
1. Cross compilation of the libraries is impossible because the build
system assumes that the host OS is the same as the target OS i.e. if I
build the libs on Windows I get Windows suffixes added to the libs. I am
also aware that there are a number of other build switches triggered by
$(OS) or $(UNAME) that will affect the outcome.
2. Even if cross compilation was possible the run-time testing cannot be
deferred and performed separately on another machine.
3. A number of the conditional tests assume a fixed relationship between
compiler and C++ library, e.g. many tests check __GNUC__ to determine
which headers/features are present instead of __GLIBCPP__ . Given the
"mix and match" nature of the QNX development environment this
assumption no longer holds true.
4.
> Maybe you could cd into libs/config and do a:
>
> ./configure --enable-test
>
> and report the results.
>
> But... will the results be consistent for all QNX "platforms", at
least as
> far as OS headers etc go?
Nope, because the test assumes only one compiler and library... I will
post the results if you wish but they are pretty meaningless.
What little I have mentioned Boost to the wider QNX community has
produced a very positive response, so I think QNX acceptance will be
worth the effort. Your ideas please on the way(s) forward.
Regards
Jim