On Thu, Dec 11, 2008 at 3:54 PM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
Guys, while reading through your fruitful comments, I've became to the following conclusions:
1. We should preserve default behavior of each toolset when building boost, e.g., for gcc compilation should be performed with visibility=default 2. We should give the ability to users: a) simplify build of custom libraries by providing macros such as BOOST_SYMBOL_EXPORT etc b) build needed boost library with custom visibility (hidden, ms-compat etc).
All this ideas are implemented in attached patches.
The first patch is for boost-build. It provides new composite feature 'hide-symbols' with available options: on, off, ms-compat, inlines-hidden. So, if I would like to build filesystem with hidden visibility, I can do the followings: * In boost root directory type "bjam /boost/filesystem hide-symbols=on" * In my library's Jamfile: alias filesystem : /boost/filesystem : <hide-symbols>on ;
'hide-symbols' feature should work only for gcc and darwin toolsets. For the others it does nothing. Unfortunately I had no ability to test darwin.
It worth mentioning that I'm not a boost.build expert, so this patch supposed to be rather *ugly* and should be carefully reviewed by some boost.build guy.
The second patch affects all the boost configuration files with BOOST_XXX_DECL macroses: __declspec(dllexport)/(dllimort) are simply replaced with macroses BOOST_SYBMOL_EXPORT/IMPORT.
As you may see, attached patches preserve default behavior of boost build procedure.
Unit tests. I've performed unit testing for affected libraries (with gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) ). All of them (except serialization) was built with hidden visibility. It was 2 failures in program_options (as Andrey predicted ;) ) in BOOST_CHECK_THROW: exception wasn't caught (variable_map_test_dll, unicode_test_dll). All the others run smoothly (unless I missed something).
Exceptions. This worries me a lot, since all the exceptions that wasn't *properly exported* will never be caught. Saying *properly exported* I mean: they always have default visibility or have been exported from shared library and have at least one key function, i.e. "non-pure virtual function that is not inline at the point of class definition"
To reproduce this issue, you can try to build attached sample project and run ./install/fee_client /some/invalid/path: boost::filesystem_error and boost::system_error won't be caught. (Note, dependent boost libraries should be build with default visibility).
Regards
P.S. Again, comments and questions will be really apreciated
Any feedback? Regards