From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-09-03 13:18:59
Hi Johannes.
I've been thinking of adding something like this soon as it's
preventing us from finishing cleanly porting one of our projects to MSVC
9.0.
We should also decide how to mangle Boost library names when built
with these features turned on and off. I think this is implemented in
the common.format-name() rule or something like that in the
tools/common.jam module. When we do, we also need to synchronize with
everyone on the main Boost library development list as this will affect
more than the build system itself (docs would need updating, possibly
some sort of backward compatibility options may be needed, someone could
have other/better solutions on how to deal with this, etc...).
Note that if we implement the behaviour you suggest (and with which I
in generally agree) the change will affect the way Boost libraries get
built as currently they get built with Microsoft's 'security' settings
turned on by default and this will make those setting turned off by
default. This is something else to consider and discuss on the main
Boost library development list.
I have some questions too:
* Why the 'theater' part of the name?
* How about a <msvc-checked-iterators> feature defining _SCL_SECURE
as 0 for 'off' (default) or 1 for 'on'.
* How about a <msvc-security-warnings> feature defining
_SCL_SECURE_NO_WARNINGS & _CRT_SECURE_NO_DEPRECATE for 'off' (default)
or not defining them for 'on'.
* Are we sure we want the <msvc-security-warnings> feature (or
<crt-security-theater> as you called it) to be marked as
link-incompatible? Doesn't this just enable or disable compiler/linker
warnings and does not affect the built executable/object code/library?
If we can agree on how to implement this here, then we can proceed to
the next step and discuss the Boost library related issues on the Boost
library development list.
Best regards,
Jurko Gospodnetić