Re: [jamboost] Re: [BBv2] [msvc] scoping interest for other extensions

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-15 12:01:28

Andrey Melnikov wrote:
>Reece Dunn wrote:
> > Andrey Melnikov wrote:
> >>Reece Dunn wrote:
> >>>[1] warnings support (designed for genericity, only supported in msvc
> >>>for now).
> >>>
> >>># builtin.jam
> >>>feature warnings : default on off all strict : propagated ;
> >>
> >>I wonder if there's a reason to have unified warning names?
> >>
> >>E.g. <warning-disable>dtor-not-virtual or
> >><warning-disable>copy-ctor-cannot-be-generated
> >
> > I am not sure, as there could potentially be hundreds of named warnings,
> > some of which would be added/removed from version to version of a
> > compiler. This would complicate the option mapping and maintenance of
> > the feature. I agree, it would be nice in some circumstances.
>
>Just major widely supported warnings like mentioned by me would be enough.

This should be independant of the general warning settings. Having named 
warning control would be good, but which warnings do you select? Are the 
ones you mention common across all (most) compilers and what if someone 
wants another named warning. Also, how do you turn on/off those warnings? 
E.g.:

<named-warning-on>deprecated
<named-warning-off>no-default-ctor

vs:

<warning-deprecated>on
<warning-no-default-ctor>off

> > I designed the warnings to be as generic as possible, without
> > compromising too much on control. I haven't used warning levels wither
> > as I was unsure how generic this would be.
>
>I agree. Warning levels and warnings themselves are
>implementation-specific, aren't they? What the standard says?

They are implementation specific, but all compilers provide warning 
diagnostics of some form.

> > feature warnings # the options in () are for msvc
> > :
> > default # use the compilers default warning settings (-W1)
>
>Actually no switch will be added. -W1 is just for illustration here
>because 1 is the default warning level in VC.

Noted. I was using VC as an example here anyway, so the values would be 
different for GCC, CodeWarrior, et. al.

> > all # enable all warnings (-W4 -Wp64)
> > strict # same as all, but be stricter about warnings
> > # (-W4 -Wp64 -WX)
> > : propagated ;
>
>In most cases warnings provide useful hints and point to actual minor
>bugs in the code that can be easily fixed.

Definitely.

>Sometimes warnings should be disabled locally using compiler-specific
>pragmas.
>
>But 64-bit warnings and deprecated/security warnings from Microsoft are
>specific ones. A lot of code has been written prior to appearance of
>these warnings so it's often desired to disable them globally and
>unconditionally (like in case of Boost).
>
>So I'd like to have:
>
>all # enable all warnings but disable "deprecated" and 64-bit ones
>(-W4 -wd0000)
>strict # same as all, but be stricter about warnings
> # (-W4 -Wp64)

This makes more sense combined with the seperation of warnings-as-errors 
below.

>-WX can be a separate feature (<warnings-as-errors>on)

I agree.

> >>>[2] support for specifying the character set.
>
> > I like this, but have a few minor points:
> > * stdlib-tchar should really be stdlib-charset to be consistent;
> > * I would prefer to use the names "narrow wide mbcs" in the
> > stdlib-tchar feature.
>
>This will increase the existing confusion. We need to provide clean,
>unambigous names, which are much better than Microsoft's UNICODE, _MBCS
>and _UNICODE.

I definitely agree. I was using charset because you had a <win32-charset> 
and I was using <charset> previously to be consistent with the VC project 
settings.

>Here is the rationale I have:
>
>#define UNICODE
>
>It configures MS Platform SDK. It isn't used neither by the Standard
>Library, nor by the Microsoft extensions to the Standard Library.
> [skip]
>so the feature should be named something like
><windows-api-aliases>ansi/unicode

This is a better name, but I am not too keen on the "aliases" part. They are 
defining the character type to be used, i.e. the A/W variant. I would 
suggest
<windows-api-*chartype*>ansi/unicode.

>#define _UNICODE, #define _MBSC or neither
>
>Switches TCHAR type between char and wchar_t. Switches
>Microsoft-specific _t* CRT function aliases between narrow, wide and
>narrow-multibyte versions.
> [skip]
>So the feature should be named something like
><msvcrt-tchar-aliases>narrow/ms-multibyte/wide.

I agree with what you are saying, but there are a few comments:
* <tchar.h> isn't just supported by MSVC - Borland, CodeWarrior and others 
support it;
* I prefer "multibyte" to "ms-multibyte" -- multibyte isn't MS specific!;
* again, I prefer something like "chartype" to "aliases".

Thus, we have:
<tchar-chartype>narrow/multibyte/wide

> > What happens if you have:
> >
> > <win32-charset>unicode <stdlib-charset>narrow
> >
> > and:
> >
> > TCHAR * ch = _T("To _T, or not to _T...");
> >
> > ?

>It looks like there's a problem in the design. The result depends on the
>#include order. The following example doesn't work. But if you swap the
>includes, it does.
> [snip]
>The problem is because TCHAR is defined in both headers :( The first
>definition depends on UNICODE and the other - on _UNICODE

We should mention this (potential) issue in the docs, warn if possible and 
trust the user :).

> > [1] What if you don't specify a PSDK in user-config.jam, but want to
> > specify <windows>xp for a project? Or even:
> >
> > tlb myidl : myidl.idl : <windows>2k ;
>
>In user-config you only configure the paths to all installed versions of
>PSDK and default versions to use with each toolset. What SDK to use is
>specified in your Jamfile or on the command line.

I think you answered this question below... some flavour of the MSPSDK 
module will be pulled in, so <windows>2k will be present (like is done for 
the rc toolset).

> > [2] What if you are building with a non-msvc compiler (e.g. Borland or
> > Metrowerks CodeWarrior), or evevn the default PSDK shipped with the
> > specified compiler?
>
>MSPSDK module will support all PSDK flavours, even the ones adapted for
>Borland compilers.

I.e. the native/default PSDK vs an external one.

> >>>[4] support for managed (CLR) and Java bytecode

I'll answer these points when I have had a chance to look up some things in 
the VC8 documentation.

However, these facilities should be made generic enough to support the GCC 
CIL and also the Mono .NET framework, etc.

Reece Haston Dunn
Software Engineer, Sophos
www.sophos.com