Re: [boost] What plans to handle _SCEURE_SCL in the boost build system?

From: Eric Niebler (eric_at_[hidden])
Date: 2008-04-24 17:03:33

Mat Marcus wrote:
> On Thu, Apr 24, 2008 at 12:53 AM, James Talbut <James.Talbut_at_[hidden]> wrote:
>> Hi,
>>
>> There have been various discussions on here about the problems caused by
>> _SECURE_SCL, but I haven't seen any concrete plans for changes to boost
>> build to handle it.
>>
>> At a minimum the build system should be changed to enable those users
>> wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument
>> to bjam.
>>
>> Is someone working on this?
> 
> I'd love to see someone pick up the ball on this one. For what it's
> worth, I've patched my local msvc.jam to add the feature:
> 
> feature.feature stl-security-theater : off on : propagated link-incompatible ;
> 
> flags msvc.compile C++FLAGS  <stl-security-theater>off : /D_SECURE_SCL=0 ;
> flags msvc.compile C++FLAGS  <stl-security-theater>on : /D_SCL_SECURE=1 ;
> 
> As a result of our analysis of the benefits vs. performance of the
> "feature", I've set _SECURE_SCL=0 off by default. I asked on the build
> list how to augment library name mangling to make it safer, but
> haven't received a reply yet, so I may have to study a bit to make it
> better. But I will probably just ship it as above with Adobe Source
> Libraries 1.037.

Hi Mat,

Is it the secure SCL that is causing your problem, or more specifically 
the iterator debugging feature? I agree that MSVC's iterator debugging 
can cause huge performance problems, and I've had to disable it in the 
accumulator's tests to get them to complete in any reasonable amount of 
time. Here's the bjam magic I use for that:

# bring in rules for testing
import testing ;
import feature ;

feature.feature iterator_debugging
   : on off
   : composite propagated optional
   ;

feature.compose <iterator_debugging>off
   : <define>_HAS_ITERATOR_DEBUGGING=0
   ;

project
     : requirements
       <library>/boost/test//boost_unit_test_framework
       <link>static
       <include>../../..
       <toolset>msvc:<define>_SCL_SECURE_NO_DEPRECATE
       # MSVC's iterator debugging causes some tests to run forever.
       <toolset>msvc:<iterator_debugging>off
       <toolset>intel-win:<iterator_debugging>off
     ;

Now, since <iterator-debugging> is a feature, boost.build ensures that 
the test framework (against which I link) is also built with this 
feature -- very important because this setting breaks binary 
compatibility. The resulting binaries are placed in paths whose named 
encode the value of this feature, so I can't inadvertently link to an 
incompatible lib.

Does that help any? Maybe someone could add this feature to BBv2 proper.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com