Which Boost libraries support which compilers/versions
Let us say that a Boost user wants to find out if Boost library, for the latest Boost version, supports a particular compiler/version which he is using. He goes to the main Boost page in his HTML documenation for Boost and looks to find this information. It is reasonable to assume he looks under the Documentation link, although I personally think that a specific link, with an explanation about the information for which he is looking, on the main page should direct him to such information since it is of primary importance to Boost end users to know this. In the documentation page there is nothing on top which immediately tells him this information. When he scrolls down he sees the line which says, "See Compiler Status page to find out what library works with which compiler." So he clicks on this link. A very nice page of explanation, among its excellently written information, directs him to the Compiler Status Summary, and he clicks on this link. On the compiler status summary page he is met with links for a Developer Report, User Report, Inspection Report, and License Report and a general summary of compiler pass/fail rates on the Linux platform, which is dated 17 months ago. This is pretty poor, not only becaause it implies that Boost only support Linux compilers and the general report is from 17 months ago, but also because he has no idea what each of the links means. But let us suppose that he is undaunted and decides to click on the User Report, since he is an end user. The user report regression page is now shown and he clicks on one of the links in the list to his left to see the regression tests for that library. Let us suppose it is Boost smartptr, but it could be any library. He now looks for the compiler he is interested in among the header groupings. For the current release, on Windows, he sees Borland 5.8.2, Borland 5.9.0, msvc 8.0, intel-win 9.1, msvc 7.1, cw 9.4, intel vc 7.1 win 9.1, and msvc 8.0 wm5. He then assumes, quite reasonably, that if a specific compiler is not on this list, it is not supported in the latest release for the particular library. So evidently VC 6.0, VC 7.0, various forms of gcc, and the latest release of Comeau are not supported by any libraries for the latest release. But wait, he noticed on the Boost main page that gcc 3.4.x, vc 6.0 ( and 6.5, ie SP5 ), and vc 7.0 are supported for the latest release. So he assumes that regression tests have not been run for these compilers on Windows. Let us suppose by some quirk of fate, and the contingencies of his job, he actually has to work with on of these compilers. He now goes to the documentation for the library he is interested in, let us say smartptr again, by going back to the general Boost documentation page and clicks on smartptr. There is nothing there, as he suspects, that is going to list what compilers are supported by this library in the current release. This will generally be true for any Boost library, so I am not picking on smartptr. Now he does not know, other than by trying to actually use a Boost library, whether that library actually works with the compiler he is actually using. Finally, let us suppose by an equal quirk of fate and the contingencies of his job, that he is not using the latest release of Boost but must use an earlier release. Here the documentation for the earlier release contains no regression reports at all for that release but only for the latest release. So for any other release it is impossible to determine whether a particular compiler/version is supported by a particular library. I do realize that the config system in Boost will often tell the end user whether his compiler/version is supported in general for a particular Boost release when he tries to use it. But it does not tell the end user, in the case that the compiler/version is generally supported by the config system, whether or not a particular library supports his compiler/version and, if he can not find the results in the regression tests or in the particular library's version, it becomes difficult for him to determine. I do not think that the situation I have outlined here is good for Boost from the end users perspective. The typical end user, when wanting to use a particular 3rd party library whether of Boost or otherwise, wants to know immediately, before any other action is taken, whether that library supports the compiler/version he is using. I believe Boost should make it both much easier and always possible to determine whether a particular compiler/version can be used with a particular library in a particular version of Boost without the end user trying to use a library and, if he can not, encountering compiler errors. He may not know, even from compiler errors, whether or not the errors are his own or simply because the compiler is not supported for that library. This is not a criticism of Boost in general and certainly not the excellent smartptr library, but instead it is an effort to get Boost to create some easier system by which end users can determine whether or not they can use a Boost library in the particular working situation in which they find themselves.
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
I do not think that the situation I have outlined here is good for Boost from the end users perspective. The typical end user, when wanting to use a particular 3rd party library whether of Boost or otherwise, wants to know immediately, before any other action is taken, whether that library supports the compiler/version he is using.
I believe Boost should make it both much easier and always possible to determine whether a particular compiler/version can be used with a particular library in a particular version of Boost without the end user trying to use a library and, if he can not, encountering compiler errors. He may not know, even from compiler errors, whether or not the errors are his own or simply because the compiler is not supported for that library.
This is not a criticism of Boost in general and certainly not the excellent smartptr library, but instead it is an effort to get Boost to create some easier system by which end users can determine whether or not they can use a Boost library in the particular working situation in which they find themselves.
We all know it's a problem, but nobody has yet designed and implemented a solution. Perhaps you'd be willing to take up the charge? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
I do not think that the situation I have outlined here is good for Boost from the end users perspective. The typical end user, when wanting to use a particular 3rd party library whether of Boost or otherwise, wants to know immediately, before any other action is taken, whether that library supports the compiler/version he is using.
I believe Boost should make it both much easier and always possible to determine whether a particular compiler/version can be used with a particular library in a particular version of Boost without the end user trying to use a library and, if he can not, encountering compiler errors. He may not know, even from compiler errors, whether or not the errors are his own or simply because the compiler is not supported for that library.
This is not a criticism of Boost in general and certainly not the excellent smartptr library, but instead it is an effort to get Boost to create some easier system by which end users can determine whether or not they can use a Boost library in the particular working situation in which they find themselves.
We all know it's a problem, but nobody has yet designed and implemented a solution. Perhaps you'd be willing to take up the charge?
I am not a Boost developer but rather an end user using Boost. I do not know why you want end users to solve problems which the Boost developers should solve IMO. The most obvious solution is that each compiler/version supported for a particular release of Boost needs a regression test run for each library of that release, and that final test result needs to be kept permanently somewhere for each Boost release. If this is not possible it seems that each library developer should know which of the compilers/versions which are supported for a given release of Boost works for his library and keep that information permanently somewhere in his library documentation. If neither of these are possible then it is up to the end user to experiment with each library he wants to use for a given release of Boost. Normally with 3rd party software, the software developer of that library can ascertain and document which compiler/versions are supported to work with his library. I do not understand why Boost developers do not consider this information important enough to at least document what compiler/versions work with their library. It seems you want someone else, such as I who am a non-Boost developer, to do this for you, but I have no idea why unless you feel that merely making the suggestion that the system should be better means that I should have the responsibility to make it better.
Edward Diener wrote:
I am not a Boost developer but rather an end user using Boost.
There is no sharp distinction between the two in the newfangled open source world. Imagine that you want to use shared_ptr on FooC++ 4.1a running on FooOS 3.11. Who, in your opinion, has a) the incentive b) the physical ability to run shared_ptr_test on this platform?
The most obvious solution is that each compiler/version supported for a particular release of Boost needs a regression test run for each library of that release, and that final test result needs to be kept permanently somewhere for each Boost release.
Saying "needs" by itself does not spawn the volunteers who will actually run the tests. In addition, Boost may decide to not support VC 6.0 for a particular release, but shared_ptr may still be perfectly functional. Who, in your opinion, needs to run the regression tests for shared_ptr on VC 6.0?
If this is not possible it seems that each library developer should know which of the compilers/versions which are supported for a given release of Boost works for his library and keep that information permanently somewhere in his library documentation.
How could I know? I simply don't have access to all platforms that shared_ptr supports, and neither do I have the time to run the tests on each. What's wrong with just running the tests yourself if you want to see whether shared_ptr supports your particular configuration?
Edward Diener wrote:
I am not a Boost developer but rather an end user using Boost. I do not know why you want end users to solve problems which the Boost developers should solve IMO.
In open source projects, the only difference between a developer and a user is a bit of volunteer time. Sebastian Redl
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
We all know it's a problem, but nobody has yet designed and implemented a solution. Perhaps you'd be willing to take up the charge?
I am not a Boost developer but rather an end user using Boost. I do not know why you want end users to solve problems which the Boost developers should solve IMO.
What people "should" do has little bearing on what is practical or possible for them to by themselves. What's most needed here, as in so many other areas of Boost, is not a bunch of individuals solving problems, but leadership from people who understand and care about the issues. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
We all know it's a problem, but nobody has yet designed and implemented a solution. Perhaps you'd be willing to take up the charge?
Well, I have the same problem. Here is what I'm doing to address it. I'm making some shell scripts to run the boost build / test on the current configuration. This is basically a slightly modfied/updated version of runtest.sh (written by Rene Rivera) found in the tools/regression directory. The object of this new script isn not to download and test the latest version in the CVS system on the local environment. Its aim will be to validate the current boost installation by running all the test and generated a local table - similar to the compiler status table. This gives me what I need. That it is it tells me that the local combination of boost version, libraries, compiler and operating system works (or does not work) as it should. I believe that every user of boost in a production environmentment should undergoe this process. (Actually, a similar process should be undertaken with all software. Commercial software usually includes a series of tests and demos that the user can can run to verify that everything works as it is expected to. I need this now because I have a customer with several platforms with different combinations of os/compiler versions. Its unrealistic to expect that boost testing process to produce such information. Even if it did - there is no guarentee the the test conditions are identical. Robert Ramey
Robert Ramey wrote:
David Abrahams wrote:
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
We all know it's a problem, but nobody has yet designed and implemented a solution. Perhaps you'd be willing to take up the charge?
Well, I have the same problem.
Here is what I'm doing to address it. snip...
I believe that every user of boost in a production environmentment should undergoe this process. (Actually, a similar process should be undertaken with all software. Commercial software usually includes a series of tests and demos that the user can can run to verify that everything works as it is expected to.
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ? That would be fine if Boost supplied such a test script for each library for any particular version of Boost, or even intends to support such a test script in the future. Is there presently such a script ? If so, and it were as easy to run as specifying a command on a command line within whatever is the shell for the particular operating system the user runs, or even if it were a Python script which requires some version of the free Python product on the end users machine, I would be glad to use it, and I imagine many other end users would also. Please understand I am talking about something which can test any particular library and not Boost as a whole, since trying to determine Boost as a whole, for a particular compiler/version for a particular version of Boost, is done by the config system. My point is that the config system may well say that a particular compiler/version is supported as a whole while a particular library may not support that compiler/version. That is often the case with older, more non-conforming libraries and while programmer's may well want to use the latest version of a particular compiler or a better compiler, the contingencies of work in corporate America, or corporate anyplace else, as well as the end users own choice, may keep that from happening.
Edward Diener wrote:
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ?
Every end user who is not sure whether his configuration is supported by a particular library can run the tests. This is generally done by invoking 'bjam' (or 'bjam --toolset=foo' if the default doesn't work) in the directory containing the tests, for example libs/smart_ptr/test. One can also use 'bjam shared_ptr_test' to single out a particular test. The resulting output could've been friendlier, and the whole procedure better documented, of course. In a perfect world typing 'bjam' (or possibly 'bjam show' or something similar) in a test dir would cause an HTML page with the results to be launched in the default browser. :-)
Peter Dimov wrote:
Edward Diener wrote:
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ?
Every end user who is not sure whether his configuration is supported by a particular library can run the tests. This is generally done by invoking 'bjam' (or 'bjam --toolset=foo' if the default doesn't work)
This now gets into understanding how bjam works. Argh !!! How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ? I am assuming that one must look at Boost Build documentation to determine this. However, let us say for VC++, the name msvc only specifies a compiler but not a version. Now one has to investigate how one specifies both a compiler and a version on the bjam command line. Good luck in finding this out for any end-user who does not have the patience of Job.
in the directory containing the tests, for example libs/smart_ptr/test. One can also use 'bjam shared_ptr_test' to single out a particular test. The resulting output could've been friendlier, and the whole procedure better documented, of course.
In a perfect world typing 'bjam' (or possibly 'bjam show' or something similar) in a test dir would cause an HTML page with the results to be launched in the default browser. :-)
What I am arguing for is that the end user, given a compiler and a version of that compiler, should have an easy path to determine whether a library supports that compiler/version. I wish I could believe that bjam is easy, but I do not. In particular, telling what compiler/version on the bjam command line seems like a complicated thing to me.
Edward Diener wrote:
This now gets into understanding how bjam works. Argh !!!
How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ?
The mapping is on the Getting Started page, or at least linked directly from it. Sebastian Redl
Sebastian Redl wrote:
Edward Diener wrote:
This now gets into understanding how bjam works. Argh !!!
How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ?
The mapping is on the Getting Started page, or at least linked directly from it.
Thanks, I found it.
Edward Diener wrote:
Peter Dimov wrote:
'bjam' (or 'bjam --toolset=foo' if the default doesn't work)
This now gets into understanding how bjam works. Argh !!!
I don't see why. Peter just mentioned what you could find out by reading the Boost Library guidelines, and by running "bjam --help".
How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ?
The toolset names are documented in the getting started docs. And the version number is irrelevant.
I am assuming that one must look at Boost Build documentation to determine this.
No. Just reading the getting started docs <http://www.boost.org/more/getting_started/windows.html#identify-your-toolset>. Which you would do if you are a user.
However, let us say for VC++, the name msvc only specifies a compiler but not a version. Now one has to investigate how one specifies both a compiler and a version on the bjam command line.
No. The version is irrelevant. And in the case of some toolsets, like msvc, detected automatically. You don't need to specify the version if you are a user. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Edward Diener wrote:
Peter Dimov wrote:
'bjam' (or 'bjam --toolset=foo' if the default doesn't work) This now gets into understanding how bjam works. Argh !!!
I don't see why. Peter just mentioned what you could find out by reading the Boost Library guidelines, and by running "bjam --help".
How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ?
The toolset names are documented in the getting started docs. And the version number is irrelevant.
No, this is not true if more than one version of a toolset is installed. Those cases do happen and one may be forced to use an earlier version.
I am assuming that one must look at Boost Build documentation to determine this.
No. Just reading the getting started docs <http://www.boost.org/more/getting_started/windows.html#identify-your-toolset>. Which you would do if you are a user.
Yes, I see it now. Thanks !
However, let us say for VC++, the name msvc only specifies a compiler but not a version. Now one has to investigate how one specifies both a compiler and a version on the bjam command line.
No. The version is irrelevant. And in the case of some toolsets, like msvc, detected automatically. You don't need to specify the version if you are a user.
See above. I love it when people say, "you do not need 'that' because everything works automatically" but do not take into account one's environment where specifically one does need 'that'. That is evidently why specifying a version for a compiler appears to be missing from the Boost Build docs when calling bjam from the command line, but I do see the explanation in the Getting Started Guide. Still it is a guess. Is it, just to take an example, 'msvc-7' or 'msvc-7.0' ( probably the latter ), but I guess I could try both and see what happens.
Edward Diener wrote:
Peter Dimov wrote:
Edward Diener wrote:
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ?
Every end user who is not sure whether his configuration is supported by a particular library can run the tests. This is generally done by invoking 'bjam' (or 'bjam --toolset=foo' if the default doesn't work)
This now gets into understanding how bjam works. Argh !!!
How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ?
I'm actually quite sympathetic to your reaction. :-) In this case the 'Getting Started' document seems to explain things relatively well: http://www.boost.org/more/getting_started/index.html and our hypothetical user would probably need to confront bjam earlier or later anyway because of filesystem, regex or another useful library that requires building. This whole process will be of course easier if we have a "how do I run the tests for a specific library" guide. Khm. You seem to find your way with words quite well. (ducks)
Peter Dimov wrote:
This whole process will be of course easier if we have a "how do I run the tests for a specific library" guide. Khm. You seem to find your way with words quite well. (ducks)
[fires] Here's a blank space for you, or anyone else who wants to help, to write such a page <http://svn.boost.org/trac/boost/wiki/TestingOneLibrary>. When people thinks the page is good enough tell the IBD volunteers and they'll figure out hwo to incorporate it into the new web site. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Peter Dimov wrote:
Edward Diener wrote:
Peter Dimov wrote:
Edward Diener wrote:
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ? Every end user who is not sure whether his configuration is supported by a particular library can run the tests. This is generally done by invoking 'bjam' (or 'bjam --toolset=foo' if the default doesn't work) This now gets into understanding how bjam works. Argh !!!
How does one find out the name of the toolset which corresponds to the compiler/version which one wants to test ?
I'm actually quite sympathetic to your reaction. :-)
Thanks !
In this case the 'Getting Started' document seems to explain things relatively well:
http://www.boost.org/more/getting_started/index.html
and our hypothetical user would probably need to confront bjam earlier or later anyway because of filesystem, regex or another useful library that requires building.
Yes, I agree. I just wish the explanation for Boost Build v2 were easier to understand for doing the simple things. I am sure it is a wonderful system but the explanation for it seems very convoluted to me.
This whole process will be of course easier if we have a "how do I run the tests for a specific library" guide. Khm. You seem to find your way with words quite well. (ducks)
In the promulgation of one's escetary cogitation and in the articulation of one's superficial sentimentalities, one should beware of platitudinous ponderosities. <g> ( ducks also ) I offered a long time ago to help anyone within Boost writing documentation in the areas of grammatical structure and good English usage, but I really have little time, outside of doing my job and earning a living, to devote myself to writing documentation for others. As a developer of my own concepts I do feel a responsibility of writing good documentation, however.
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
I offered a long time ago to help anyone within Boost writing documentation in the areas of grammatical structure and good English usage, but I really have little time, outside of doing my job and earning a living, to devote myself to writing documentation for others. As a developer of my own concepts I do feel a responsibility of writing good documentation, however.
What's missing is not necessarily documentation, but policy, structure, and organization within which the documentation will be written and presented. Developing that isn't the responsibility of any individual library developer, which is why, when someone comes along who seems to have a vision of what's needed, he gets invited to set that structure up. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Edward Diener wrote:
Robert Ramey wrote:
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ?
That would be fine if Boost supplied such a test script for each library for any particular version of Boost, or even intends to support such a test script in the future. Is there presently such a script ? If so, and it were as easy to run as specifying a command on a command line within whatever is the shell for the particular operating system the user runs, or even if it were a Python script which requires some version of the free Python product on the end users machine, I would be glad to use it, and I imagine many other end users would also.
That's what I think as well. Currently in tools/regression there is runtest.sh. I should be in your local copy of boost. Take a look at it. The last steps in this script run bjam, process_jam_log, and compiler_status programs to build a table to view the results of all the tests with the local tools. This table can be browsed with any html browser. There is a similar version within the serialization library which does the samething for just that library. ( libs/serialization/test). Included there are scripts for *nix shell and *.bat file for windoz. I was much disappointed to find that these scripts wouldn't run with V2 and I'm in the process of making adjustments. This will be very useful to me and perhaps others. Ideally, I would like to see the boost "getting started" documentation include a final section" named something like "Validating your boost Installation" which runs such a script. Perhaps there might be a mechanism for uploading the results somewhere as the testers do but that would not be important to me. One pay off for me would be to be able to ask a user who is having ABI problems or something like that to "validate his local boost installation" so that a whole class of possible causes could be eliminated at the start. Robert Ramey
Robert Ramey wrote:
Edward Diener wrote:
Robert Ramey wrote:
You believe that every end user who wants to use a particular Boost library should run a test script just to determine whether or not that library is supported by Boost for the compiler/version which that person uses ?
That would be fine if Boost supplied such a test script for each library for any particular version of Boost, or even intends to support such a test script in the future. Is there presently such a script ? If so, and it were as easy to run as specifying a command on a command line within whatever is the shell for the particular operating system the user runs, or even if it were a Python script which requires some version of the free Python product on the end users machine, I would be glad to use it, and I imagine many other end users would also.
That's what I think as well.
Currently in tools/regression there is runtest.sh. I should be in your local copy of boost. Take a look at it.
It is there but it does me little good if I am running Windows.
The last steps in this script run bjam, process_jam_log, and compiler_status programs to build a table to view the results of all the tests with the local tools. This table can be browsed with any html browser.
There is a similar version within the serialization library which does the samething for just that library. ( libs/serialization/test). Included there are scripts for *nix shell and *.bat file for windoz. I was much disappointed to find that these scripts wouldn't run with V2 and I'm in the process of making adjustments. This will be very useful to me and perhaps others.
Ideally, I would like to see the boost "getting started" documentation include a final section" named something like "Validating your boost Installation" which runs such a script. Perhaps there might be a mechanism for uploading the results somewhere as the testers do but that would not be important to me.
One pay off for me would be to be able to ask a user who is having ABI problems or something like that to "validate his local boost installation" so that a whole class of possible causes could be eliminated at the start.
Peter Dimov suggested running the tests for each library in which one is interested. Fair enough, but the compiler names and the version numbers one needs to use for a particular compiler, as well as the bjam command line, are obscure to me. In general I find the bjam documentation well-intentioned but very difficult to understand. There has to be an easier way.
Edward Diener wrote:
Robert Ramey wrote:
Edward Diener wrote:
Robert Ramey wrote:
That's what I think as well.
Currently in tools/regression there is runtest.sh. I should be in your local copy of boost. Take a look at it.
It is there but it does me little good if I am running Windows.
People have to start with something. Robert is choosing to use the shell script for this, perhaps because that's easiest for him. If his solution works out someone else might translate it to BAT, or more likely Python, or even support it directly in Boost.Build.
Peter Dimov suggested running the tests for each library in which one is interested. Fair enough, but the compiler names and the version numbers one needs to use for a particular compiler, as well as the bjam command line, are obscure to me.
See my other reply to this.
In general I find the bjam documentation well-intentioned but very difficult to understand.
Yes, and we know. But how is it difficult to understand? What's missing? It's very hard to write good documentation, and most programmers are not good at writing docs. We even have a relatively new effort to driven by Matias Capeletto, one of the Google Summer of Code students, to improve Boost documentation overall. Perhaps you can help them, not by joining the effort, but by the simple act of providing critique as a user where/what/how can be improved and/or is lacking.
There has to be an easier way.
Certainly. But good solutions take time and effort ;-) I think Robert is driving in a good direction and we'll hopefully learn how we can improve the testing structure from his efforts. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Edward Diener wrote:
Peter Dimov suggested running the tests for each library in which one is interested. Fair enough, but the compiler names and the version numbers one needs to use for a particular compiler [...] are obscure to me.
Can you clarify that? Not that docs are stellar, but I fail to understand what can be obscure about *compiler names*. Did you see this: http://boost.org/boost-build2/doc/html/bbv2/reference/tools.html which lists Boost.Build toolsets and corresponding product names. It also lists, for cases where compiler vendor went crazy with branding, what compiler version what product has. - Volodya
Vladimir Prus wrote:
Edward Diener wrote:
Peter Dimov suggested running the tests for each library in which one is interested. Fair enough, but the compiler names and the version numbers one needs to use for a particular compiler [...] are obscure to me.
Can you clarify that? Not that docs are stellar, but I fail to understand what can be obscure about *compiler names*. Did you see this:
http://boost.org/boost-build2/doc/html/bbv2/reference/tools.html
which lists Boost.Build toolsets and corresponding product names. It also lists, for cases where compiler vendor went crazy with branding, what compiler version what product has.
How does one specify a compiler version on the bjam command line ( not in a jamfile rule ) ? Is this documented anywhere in Boost Build ? Before you say that one never does that, consider the situation where I have three different versions of gcc ( or msvc ) and I want to run some jam file against the earliest one.
participants (7)
-
David Abrahams -
Edward Diener -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Sebastian Redl -
Vladimir Prus