|
Boost-Build : |
From: Johannes Brunen (jbrunen_at_[hidden])
Date: 2008-09-03 18:07:51
Hello Jurko,
> Jurko Gospodnetic wrote:
> 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...).
I think that the default behavior should probably not change. So the
standard boost build would not be affected in the first place. But, of
course, docs must be up to date and we should discuss it with the
community of users...
> 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'm not very familiar with the boost build system. Actually, I refered
to a proposal from Mat Marcus. However, I would prefer a solution which
has the same default as the current Boost Build system. I have no
problem with a default setting that does the special MS's security
options. The important point, IMHO, is the abstraction of these features
and a convenient way to turn it on or off on request. Looking at the
amount of possible settings I think that there does not exist a set of
default options that anyone fits.
> I have some questions too:
>
> * Why the 'theater' part of the name?
Oh I take this from Mat Marcus original proposal. See his post for a
reference link. I have no particular stand to the naming.
> * How about a <msvc-checked-iterators> feature defining _SCL_SECURE
> as 0 for 'off' (default) or 1 for 'on'.
Now the next one is using the wrong feature name. It is _SECURE_SCL. I
did it wrong in the first place. Maybe I was mislead by the names from
the other features of this family. You see good naming and abstraction
is important. IMO <msvc-checked-iterators> is much more to the point.
But I would default it to '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'.
I'm not sure if we should mix these two (_SCL and _CRT).
> * 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?
No, they should not be link-incompatible. They does only enable/disable
warnings.
Yours,
Johannes
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk