|
|
Boost Testing : |
From: John Maddock (john_at_[hidden])
Date: 2005-11-02 06:15:44
> 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.
Hmm, I admit that figuring out the POSIX standard isn't the easiest thing to
do, but in the current standard:
nl_types.h is marked as part of the XSI feature group, and then under
unistd.h it says:
"The following symbolic constant shall be defined only if the implementation
supports the XSI option; see Section 2.1.4 (on page 19).
_XOPEN_VERSION
Integer value indicating version of the X/Open Portability Guide to which
the implementation conforms. The value shall be 600."
Looking at the output from config_info it looks as though _XOPEN_VERSION is
set to 500 under QNX, which corresponds to the Single Unix Specification
Version 2 I believe, and there are no optional features in that as far as I
know, certainly it doesn't list nl_types.h as optional.
> 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.
Hmm, that's a bjam build issue rather than a code one, I'm not sure if bbv2
supports cross compilers better.
> 2. Even if cross compilation was possible the run-time testing cannot
> be deferred and performed separately on another machine.
Understood, that's a problem with most test harnesses, again it may be worth
bringing this up on the Jamboost list.
> 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.
That's a bug then :-)
Certainly Boost.Config shouldn't do that anywhere, um I hope :-)
> 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.
Understood, but Boost.Config splits the logic up into:
* Compiler
* std lib
* Platform (system headers etc)
* Common features (POSIX feature detection etc)
So varying compiler/std lib combinations should be handed already, modulo
any bugs you may discover in the existing logic obviously.
There's currently no platform config for QNX, so really the information I'm
trying to get from you (and which a configure run would detect), are which
platform headers are present/missing, obviously this may vary by QNX
sub-platform, but once we have a basic QNX platform config header in place I
guess you can maintain that :-)
We also need to know how best to detect QNX platform/subplatforms etc.
Thanks,
John.