able to detect Visual Studio 6.0, 7.0, 7.1, 8.0 and Visual C++ Toolkit
2003. Detected settings are used in the cases when:
- only version number is passed (using msvc : 8.0 ;)
- incomplete configuration command is given (using msvc : 8.0 : cl.exe ;)
- any available compiler is configured (using : default ;)
- all available compilers are configured (using : all ;)
A user is free to overwrite any of detected settings.
Patch from Alexey Pakhunov.
[SVN r31120]
of the 'toolset.configure' framework. The new rule supports two special
version values:
- 'all': configures all detected versions of Visual C++ with default
settings;
- 'default': configure the default detected version of Visual C++. It
prefers newer versions to older ones.
'msvc.init' is still completely valid and should be used until
'toolset.configure' will be introduced. 'msvc.init' provides the same
functionality as 'msvc.configure' does.
Patch from Alexey Pakhunov.
[SVN r31093]
targets. In that case, we used to create a long list of targets and searched
it whenever new target is registered. Now the list is for each path/name
combination, so is much shorter.
[SVN r31054]
Patch from Alexey Pakhunov.
What this patch does is allows to match absense of optional feature in
the 'flags' rule. For example:
flags msvc .SETUP <architecture>/<address-model>64 : " x86_amd64" ;
flags msvc .SETUP <architecture>ia64/<address-model> : " x86_ia64" ;
This will produce "x86_amd64" when the <address-model> is set to 64
and <architecture> is not set. Likewise, for <architecture>ia64 and unset
address model.
Without this patch, we'd have two choices:
- adding 'default' to the list of feature values. But that would
add 'architecture-default' to the target path. Ick!
- creating top-level variable .SETUP with default value, and only
matching configurations with fully-specified feature values. But
this won't handle the case above: we really need to check
which one of two features is unspecified.
[SVN r31036]
never contains moccable classes.
The trick here is that if we have:
exe a : a.cpp b.ui ;
Then we should produce b.h target that is not used by any action -- it's
only indirectly used by include in a.cpp.
So, we declared .ui -> .obj generator, so that it's invoked when
building exe, but make it return header, not .obj.
Second, the path of b.h should be added to include paths. But it was
not done, because b.h is not used anywhere and so is not included in
'subvariant' for this target -- which object is used to compute extra
incude path.
* build/virtual-target.jam
(register): Add result to .recent-targets
(recent-targets, clear-recent-targets): New functions.
* build/targets.jam
(basic-target.generate): Create subvariant from
'virtual-target.recent-targets' not just directly returned targets.
* tools/qt4.jam: Declare custom generator for ui->h conversion.
[SVN r30770]
