Le 04/11/12 10:17, Gennadiy Rozenal a écrit :
Hi,
I've been working on portability fixes for new features in boost.test. They now works fine with gcc 4.6 and 4.7 msvc-10.0 and msvc-11.0. My attempt with clang on linux lead to compiler crashing, but I see it passing in regression on darwin, so I am not sure on the status. I do still have some issues about portability and boost.build:
1. Boost.Build does not handle correctly target foo with sources residing in subdirectory foo under location of Jamfile. I had to rename directory boost/libs/test/test/test_datasets into test_datasets_src, because of that. Hi,
I you to post on the Boost.Build/User/Dev ML when you have issues such that ones. I use to do the following without any issue [ run ../example/a_test.cpp ] Is this what you needed?
2. How do I tell that I want to pass compilation to gcc in toolset gcc-4.7 only? I've tried <toolset>gcc-4.7:<cxxflags>-std=c++11 and <toolset>gcc-4.7.2:<cxxflags>-std=c++11 and either one does not work.
<toolset>gcc:<cxxflags>-std=c++11 does work, but I want to pass different options for different versions of gcc.
Wow, I'm really surprised you have troubles with this. You need to define your toolsets in the user_config.jam file. I have for example using gcc : 4.7.1 : /usr/gcc-4.7.1/bin/g++-4.7 ; using gcc : 4.7.1x : /usr/gcc-4.7.1/bin/g++-4.7 : <cxxflags>-std="c++11" ; Someone has been requesting the addition of a 'std' feature that gives the standard, but I don't think this has been implemented or even retained.
3. Question: Should I tell *unconditionally* in Boost.Test Jamfile in boost/libs/test/build that I want to pass -std=c++11/-std=c++0x depending on a version?
If not, how do I test test_dataset target with this option? Also How do I disable for configurations which does not support it? I use to have a config.hpp file that gives some macro stating which features are available depending on the compiler/platform. In the c++ files I just check for these macros and I disable the code
Do you want to provide several versions for the same Boost release? If yes, I think that each version needs a specific Jamfile. Take a look at what Spirit has done in the past. Anyway, No, I don't think this is the place. This is up to the user to compile with whatever compiler she wants. See above. If there is code that should not work if a specific c++11 feature is not available just try to emulate it, report an #error when the user is using this file, or just don't include specific code needing the specific feature. that would not work. You can also define a new bjam feature and define the sources you include depending on this feature. This is a little bit more complex, but allows you to be more precise. You can take a look at the Jamfile in thread/build which defines a feature threadapi.
4. Issues with regression testers setup? If you look here: http://www.boost.org/development/tests/trunk/developer/test.html You will see that: a) clang linux columns are empty. Why is that?
There are some of them for Boost.Thread when the program needs to fail. I don't know why.
b) msvc-11.0 setup is broken because of: 'cl' is not recognized as an internal or external command, operable program or batch file. Well this is just another broken tester. Don't worry about it, or just contact the tester directly or iusing the Boost.Testing ML. c) sun setup is broken because of: /bin/sh: line 2: CC: not found This is anew tester that has not yet reached to have any good results. Can we fix these? As I said above, there is a specific list for this purpose. Boost.Testing.
5. Portability for other compilers. I am not quite sure which is lowest version of gcc this feature works. Anyone who is interested in making it work with older/different compilers feel free to submit patches. You have not yet said if the new features/files work with c++98 compilers?
For what I can see on the regression page it seems that test_datasets and test_tools_test are not quite portable. IMHO, I think that you are using without any check C++11 features. There are specific macros in Boost.Config that you can use to check if specific features are available. Some of them are already available in a protable way in Boost, e.g. to avoid ../boost/test/data/monomorphic/fwd.hpp:44:33: error: expected class name struct is_std_collection : std::false_type {}; you can use struct is_std_collection : boost::false_type {}; including <boost/type_traits.hpp> instead of <type_traits> But I guess you know already all that. I suggest you to use a test file for each feature provided by your library. This will let you have a better granularity of what specifically is not working with each compiler/platform. HTH, Vicente