feature.py:
Use the feature's name in the error output. This helps in understanding the
error message.
project.py:
The original looked like the result of a bad merge as the return value was the
exact same as the return within the try...except block. The try...except
produces a better error message upon failure.
property_set.py:
The string module is unused.
virtual_target.py:
ARM's ar.exe would fail when passed a path to the -via file that had both
POSIX and Windows path separators. Normalizing the path on the target solved
the problem.
common.py:
The requirement parameter in check_init_parameters should be a container. The
original Jam signature marks it as a list with zero or more items. These
changes convert the requirement parameter to using only a container.
msvc.py:
The call to to_seq asserts that command is always some container. So, extend()
should always be used.
tools/rc.py:
Old style exceptions aren't allowed (at least in Python 2.7). This change just
uses the existing AlreadyDefined exception.
testing.py:
loaded_tool_module_path_ is empty upon initial import. Using the __file__
variable instead will always work (provided the import system doesn't change).
This patch fixes 3 issues:
- Adds support for Intel-15 so MSVC version can be auto-selected.
- Changes GLOB to path.glob as for some reason the GLOB rule always
fails when used in this context (discovered when testing this patch).
- Changes selection logic for target-types variable - previous code
used the value of PROCESSOR_ARCHITECTURE to detect this, but that
appears to only tell you which sub-system bjam is running in. For
example on my system bjam is a 32-bit app (default for an msvc build),
but I only have the Intel 64-bit compiler installed (under /intel64/).
New logic checks whether the intel64 compiler exists and uses that if
it is - Intel's installer won't install this on 32 bit platforms in
which case the glob fails and things fall back to the ia32-intel64
cross compiler when address-model=64 is specified.
This patch makes <suppress-import-lib> property
take effect as telling Boost.Build that no
import lib will be created.
Actually, I think the name is not good enough.
Also, it appears that NOENTRY is orthogonal to
import lib.
When docutils is not configured at all, produce an
error message as opposed to trying to invoke Python
without providing a script to run.
Even better would be to search for docutils in common
places, and do so even without explicit 'using', but that's
beyond 30 mins I have right now.
Unbreak msvc initialization with versions less than 11.
There was an incorrect condition causing a search for phone support to be run, and fail,
on msvc versions known not to have such support in the first place.
1. Fixing up a bit how the phone setup script location is calculated.
2. Reusing generate-setup-cmd rule in configure-really to avoid duplication and make cleaner.
3. Adding some more comments explaining.
MSVC setup scripts are very slow, so should not be used in build actions directly.
Rewrite these scripts into their fast equivalents and use those instead.
Add toolset initialization option <rewrite-setup-script> to customize/disable this new behavior.
This is not clang's defect, however in most cases expects GNU ld as a
backend linker.
1. Use --{start,end}-group to avoid object linking order probrem.
2. Use -Wl,-B{static,dynamic} to treat static library correctly.
see also: https://svn.boost.org/trac/boost/ticket/5820
1. Adds a new feature <windows-api> for specifying the WINAPI_FAMILY API set to target. Defaults to desktop, which is how builds before my changes.
2. A few small changes for adding ARM support.
3. Changes to call to correct vcvars setup script for Windows Phone 8.
