|
|
Boost Testing : |
From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-05-24 15:55:38
Rene Rivera wrote:
> Jonathan Turkanis wrote:
>> Rene Rivera wrote:
>>
>>> Jonathan Turkanis wrote:
>>>
>>>
>>>> Two of the iostreams regression tests, gzip_test.cpp and
>>>> zlib_test.cpp rely on the third-party open source library zlib. In
>>>> addition, bzip2_test.cpp relies on the third-party open source
>>>> library libbz2.
>>>
>>> Ideally those tests and features would be disabled if the libraries
>>> are not available.
>
>> As far as I know there's no standard location for either zlib source
>> or binary on Windows, so I don't see how to do this unless I disable
>> the compression filters by default on Windows.
>
> If you are requiring that users/testers set the environment vars to
> indicate where those are installed. Then you can use that fact that
> those are set, or not set, to enable, disable the features.
I guess this is true on Windows. If neither the environment variables for the
source nor the environment variables for prebuilt binaries are set, I can
disable the compression filters and print a warning.
On unix, though, if the environment variables locating the full source code are
not set, the Jamfile assumes that the library will be linked with prebuilt
binaries, and looks for environment variables telling it where to find the
headers and the binaries. If the second set of variables aren't set, it assumes
that these files are in locations where they will be found automatically.
> I don't think this applies only to Windows though. It's equally
> plausible for Unix like compilation to fail if those libraries are not
> available in standard locations (those found by the compiler by
> default).
True, but it seems to be working everywhere except Tru64 at comsoft. It's seems
to work well enough on Unix/Linux that I'd like to leave it as is.
> So I would always lean towards not enabling such "optional" features
> unless asked for by the user. It's a question of whether you are
> willing to answer the inevitable questions from users why the library
> doesn't work the first time a user builds it ;-)
Good point. I'm now leaning towards disabling compression by default on Windows.
Jonathan