Jan Stetka wrote:

Hi,

What compiler and library combination were you using when it failed? The regression tests (follow the links on the main page) are useful for seeing which compilers pass and fail particular test cases. Some of the libraries include in the documentation what compilers they support.

The combinations which failed were Wave and Program_Options with VC6. I am not sanguine about using VC6, knowing what a poor compiler it is in terms of C++ standardization but I am forced to at least for some programs in a consulting job I am doing. I do not think regression test results are a valid way to say what compilers are supported for a library. Many of the regression tests do not even occur for particular compilers, and there are many testers doing tests, some using a particular compiler for particular libraries and others not using a particular compiler. The regression tests results appear very random, not in their actual results buit in whom is doing testing with what. Many libraries do not bother to say anything in their documentation about what compilers are supported. Boost really needs a table which specifically says, for any given release in the future, which compilers are supported for which libraries. Anything short of that is confusing and will cause end user problems.

Edward Diener wrote:

...

Is there any central place in the Boost documentation which tells, for any given release, or even just for the latest release, which compilers are supported by a given library ?

I ask this because attempting to build a particular library in Boost 1.33.1 for a particular compiler failed, and I could see no place where I could determine whether that Boost library was actually meant to support the particular compiler or not in the 1.33.1 implementation.

Peter Dimov wrote:

Edward Diener wrote:

...

Boost really needs a table which specifically says, for any given release in the future, which compilers are supported for which libraries. Anything short of that is confusing and will cause end user problems.

How would we know what to put in the table?

If you, the author of Boost libraries, do not know what compilers work correctly with your libraries, imagine how the user of one of your libraries feels when he tries to determine whether his compiler will work with your library. Really, Peter, I find it disingenuous that you believe it is not your responsibility to know or document what compilers work with your library. It is equivalent to a library author saying that his implementation may or may not work with a user's particular compiler, but the end user can figure it out somehow nonetheless. That is really some attitude for Boost developers to take. If you said that you did not know whether a compiler worked with your libraries because you did not have that compiler/platform, that is understandable, but if I were a library implementor I would assume it was my responsibility to find out one way or another, at least among the compilers which are popular and often used by developers on the platform(s) I supported.

I do what I can to support whatever is being regression tested and/or whatever is being bug-reported against. Many of these are platforms that I never use.

That is partially understandable. See above.

The regression test matrix is the only reliable place that shows what works.

The regression test matrix appears to be tests by different testers of different libraries, and certainly not of all librariews which may or may not work for a particular compiler which Boost supports in some way. I have rarely been able to make sense of what actually does work with what compiler. Is this a failing of mine to understand the matrix ? Is the matrix really a complete record of all Boost supported compilers and their tests against all libraries which ostensibly support a compiler ? What if there is no regression test of a particular compiler against a particular library ? Does that mean that the library does not support the compiler, or might it mean that nobody has submitted a test of that library with that compiler ? These are all serious questions I am asking because from what I see the regression tests do not absolutely answer what compilers work with the different Boost libraries. But maybe I am just missing the ability to interpret the regression tests correctly as an absolute indication of which Boost support compilers work with which libraries.

Peter Dimov wrote:

Yes, the matrix is a complete record of all libraries against all supported compilers. If you look at

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/summary...

But what this doesn't allow you to do is, for a new release, so which libraries have dropped/added support for your compiler. What I've always wanted to see (and have asked for before) is a difference between releases so I can see if it is worth me trying to upgrade to the latest version of boost or if I'm wasting my time because an important part of an important library no longer supports my compiler. The only answer at the moment seems to be try it and see, or some how work out which, out of all the regression tests, for all the libraries we use, are applicable to us still pass. I don't think this is a very easy thing to do. Therefore, it isn't easy to persuade management that we should invest time in moving to the newer version of boost, because we don't have an easy way of knowing if it is actually possible or not. Cheers Russell

Peter Dimov wrote:

Edward Diener wrote:

...

The regression test matrix appears to be tests by different testers of different libraries, and certainly not of all librariews which may or may not work for a particular compiler which Boost supports in some way. I have rarely been able to make sense of what actually does work with what compiler. Is this a failing of mine to understand the matrix ? Is the matrix really a complete record of all Boost supported compilers and their tests against all libraries which ostensibly support a compiler ?

Yes, the matrix is a complete record of all libraries against all supported compilers. If you look at

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/summary...

for example, you'll see that the program options library is marked "unusable" for VC 6 and 7.0. This means that the library does not support these compilers.

For bind, there's a green 'details' link that leads to

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/bind.ht...

where one can see that the three test failures on VC 6 are marked as "expected failures". Following the first of them to

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/output/...

shows a note at the top that this test failure doesn't render the library unusable.

...

What if there is no regression test of a particular compiler against a particular library ? Does that mean that the library does not support the compiler, or might it mean that nobody has submitted a test of that library with that compiler ?

The compiler is not supported by Boost.

Thanks for your answers. While the regression tests show what libraries support what compilers, it does so through testing programs. In my case I ran 'bjam "-sTOOLS=msvc"' from the Boost directory for 1.33.1 and received numerous error messages when attempting to build program_options and wave libraries. I think that if a library does not support a particular compiler, as the regression tests show for VC6 and program_options or wave, then an attempt to build libraries which do not support the compiler mentioned on the bjam command line should either skip a build of that particular library or put out a simple error message that the particular library does not support the particular compiler. It should not attempt to build the library at all if that library is clearly not supported for the particular compiler.

David Abrahams wrote:

Edward Diener <eddielee@tropicsoft.com> writes:

...

Thanks for your answers. While the regression tests show what libraries support what compilers, it does so through testing programs. In my case I ran 'bjam "-sTOOLS=msvc"' from the Boost directory for 1.33.1 and received numerous error messages when attempting to build program_options and wave libraries. I think that if a library does not support a particular compiler, as the regression tests show for VC6 and program_options or wave, then an attempt to build libraries which do not support the compiler mentioned on the bjam command line should either skip a build of that particular library or put out a simple error message that the particular library does not support the particular compiler. It should not attempt to build the library at all if that library is clearly not supported for the particular compiler.

Our test reporting and build tools have not reached that level of integration yet, but that would indeed be a great feature. Care to contribute it?

What is wrong with individual binary library developers setting their jamfiles so a compiler which their library does not support is not built ? Yes, I know that is a manual operation which imposes the knowledge that a particular compiler does not work for their library, and there may be ways to automatically determine it, but at least it aids the end-user in using that library. I do not know bjam, either v1 or v2, and frankly it appears like a bear to learn properly. I am also working at two different consulting jobs. My suggestions on this thread are not an effort to create work for library developers but rather to find a way to make libraries more easily usable by end-users like me. It was confusing to me when some libraries did not build when using VC6, which I am unfortunately forced to use at least partially in a consulting jobs with legacy code, and I had to find out if VC6 was supported by these libraries. I do hope that Boost in the future can make it easier for end users to determine whether their compiler is supported by a library, whether or not that library is being built as a binary library, or being used strictly as a header only library. I do appreciate Peter Dimov's pointing me at what to look for on the regression tests.