[config] Major upgrade to Boost.Config symbol visibility macros
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697. See https://svn.boost.org/trac/boost/changeset/62140 Thanks Jürgen Hunold for his patches and much other work on symbol visibility issues. The changeset also applied the changes to Boost.System to act as a testbed to ensure the changes are correct. That's a concern because any breakage in Boost.Config could break a lot of other stuff. We also want to get the Boost.Config changes right the first time as they kick off rebuilds of everything that uses the config system. The changes have been tested locally on Windows, Linux, and the Mac, and Boost.Filesystem has been retested on those systems as a reality check that unmodified user code continues to work. As trunk regression tests cycle and our confidence builds, we will start to suggest and/or apply changes to other libraries to make use of the new facilities. --Beman
On 2010-05-22 14:32, Beman Dawes wrote:
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697.
Cool. BTW, I noted that this changeset also includes a switch from using Boost Test to Peter Dimov's lightweight test library. Coincidentally I'm considering the very same switch for value_init_test: [value_init] Please replace Boost Test ("minimal.hpp") by lightweight_test, http://svn.boost.org/trac/boost/ticket/4246 I submitted #4246, because various compilers, including IBM V11.1, Sun 5.10, MINGW-4.3.3, and Borland 6.2.1 (Codegear, Embarcadero) no longer compile Boost Test. Is that also the reason why you switched to lightweight_test? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Niels Dekker wrote:
On 2010-05-22 14:32, Beman Dawes wrote:
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697.
Cool. BTW, I noted that this changeset also includes a switch from using Boost Test to Peter Dimov's lightweight test library. Coincidentally I'm considering the very same switch for value_init_test: [value_init] Please replace Boost Test ("minimal.hpp") by lightweight_test, http://svn.boost.org/trac/boost/ticket/4246
One downside of the lightweight test library is that it's easy to forget to "return boost::report_errors();" from main(). I see in the changeset that Beman made that mistake.
On Sat, May 22, 2010 at 9:53 AM, Peter Dimov <pdimov@pdimov.com> wrote:
Niels Dekker wrote:
On 2010-05-22 14:32, Beman Dawes wrote:
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697.
Cool. BTW, I noted that this changeset also includes a switch from using Boost Test to Peter Dimov's lightweight test library. Coincidentally I'm considering the very same switch for value_init_test: [value_init] Please replace Boost Test ("minimal.hpp") by lightweight_test, http://svn.boost.org/trac/boost/ticket/4246
One downside of the lightweight test library is that it's easy to forget to "return boost::report_errors();" from main(). I see in the changeset that Beman made that mistake.
Grrrr.... Fixed. Thank you very much! --Beman PS: I'm in awe of Peter and other Boosters ability to spot my stupid mistakes.
At Sat, 22 May 2010 16:53:34 +0300, Peter Dimov wrote:
One downside of the lightweight test library is that it's easy to forget to "return boost::report_errors();" from main(). I see in the changeset that Beman made that mistake.
Could we do anything “lightweight” with atexit and assert to make that downside go away? -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
On Sat, May 22, 2010 at 9:29 AM, Niels Dekker - address until 2010-10-10
Cool. BTW, I noted that this changeset also includes a switch from using Boost Test to Peter Dimov's lightweight test library. Coincidentally I'm considering the very same switch for value_init_test: [value_init] Please replace Boost Test ("minimal.hpp") by lightweight_test, http://svn.boost.org/trac/boost/ticket/4246
I submitted #4246, because various compilers, including IBM V11.1, Sun 5.10, MINGW-4.3.3, and Borland 6.2.1 (Codegear, Embarcadero) no longer compile Boost Test. Is that also the reason why you switched to lightweight_test?
Boost.System (and Boost.Filesystem) are critical to both Boost's and my personal testing. Thus in these I don't like dependencies on anything that has a history of breaking. I also find it is a bit easier to debug with lightweight_test on platforms I'm not very familiar with. --Beman
I submitted #4246, because various compilers, including IBM V11.1, Sun 5.10, MINGW-4.3.3, and Borland 6.2.1 (Codegear, Embarcadero) no longer compile Boost Test. Is that also the reason why you switched to lightweight_test?
Beman Dawes wrote:
Boost.System (and Boost.Filesystem) are critical to both Boost's and my personal testing. Thus in these I don't like dependencies on anything that has a history of breaking. I also find it is a bit easier to debug with lightweight_test on platforms I'm not very familiar with.
Thanks, Beman. I hope I can convince Fernando Cacciola to also start using lightweight_test for value_init_test :-) Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697.
See https://svn.boost.org/trac/boost/changeset/62140
Thanks Jürgen Hunold for his patches and much other work on symbol visibility issues.
The changeset also applied the changes to Boost.System to act as a testbed to ensure the changes are correct. That's a concern because any breakage in Boost.Config could break a lot of other stuff. We also want to get the Boost.Config changes right the first time as they kick off rebuilds of everything that uses the config system.
The changes have been tested locally on Windows, Linux, and the Mac, and Boost.Filesystem has been retested on those systems as a reality check that unmodified user code continues to work.
As trunk regression tests cycle and our confidence builds, we will start to suggest and/or apply changes to other libraries to make use of the new facilities.
FWIW, I made the necessary changes to Wave and everything seems to work fine. I'll watch the regression tests for any problems, though. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On Sat, May 22, 2010 at 3:32 PM, Beman Dawes <bdawes@acm.org> wrote:
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697.
See https://svn.boost.org/trac/boost/changeset/62140
Thanks Jürgen Hunold for his patches and much other work on symbol visibility issues.
The changeset also applied the changes to Boost.System to act as a testbed to ensure the changes are correct. That's a concern because any breakage in Boost.Config could break a lot of other stuff. We also want to get the Boost.Config changes right the first time as they kick off rebuilds of everything that uses the config system.
The changes have been tested locally on Windows, Linux, and the Mac, and Boost.Filesystem has been retested on those systems as a reality check that unmodified user code continues to work.
As trunk regression tests cycle and our confidence builds, we will start to suggest and/or apply changes to other libraries to make use of the new facilities.
--Beman
Hi Beman, This is really awesome news! I suppose it is a big step to boost ABI improvement and boost binary backward compatibility on a variety of platforms. Please note, there is a boost.build patch attached to ticket 2114 also. This patch introduces new feature: hide-symbols. So, someone could easily build e.g. boost.system with hidden visibility using following command: 'bjam /boost/system hide-symbols=on'. Also feature could be used directly in a Jamfile. For sure this patch requires to be reviewed by Boost.Build gurus and maybe applied to trunk afterwards. Regards
The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697.
See https://svn.boost.org/trac/boost/changeset/62140
Thanks Jürgen Hunold for his patches and much other work on symbol visibility issues.
The changeset also applied the changes to Boost.System to act as a testbed to ensure the changes are correct. That's a concern because any breakage in Boost.Config could break a lot of other stuff. We also want to get the Boost.Config changes right the first time as they kick off rebuilds of everything that uses the config system.
The changes have been tested locally on Windows, Linux, and the Mac, and Boost.Filesystem has been retested on those systems as a reality check that unmodified user code continues to work.
As trunk regression tests cycle and our confidence builds, we will start to suggest and/or apply changes to other libraries to make use of the new facilities.
Beman, I've added support for symbol visibility to the Intel and Sun compiler configs, and tested with the Math and System libraries with default visibility set to hidden. Everything looks to be working really well, and I was even able to delete some config code from Boost.Math as a result of the changes :-) Many thanks for taking this on, John.
participants (7)
-
Alexander Arhipenko -
Beman Dawes -
David Abrahams -
Hartmut Kaiser -
John Maddock -
Niels Dekker - address until 2010-10-10 -
Peter Dimov