Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
This catches some optimization problems, mostly in the use of `all()`
and `any()`. Basically writing `any([x == 5 for x in f])` vs `any(x == 5
for x in f)` reduces the performance because the entire concrete list
must first be created, then iterated over, while in the second f is
iterated and checked element by element.
If we encounter a file under the Boost library directory that doesn't
look like a Boost library binary, we should ignore it.
We log a warning for each file we ignore, except for ones we know are
safe to ignore (e. g. PDB files from the SourceForge Windows
distribution). This should avoid polluting the log.
Fixes#8325.
Looks like boost dependency mixes up it's compiler and linker argument
order when it is removing duplicates (?) from those. This causes
unnecessary recompilations of everything depending on those components.
Use OrderedSet to remove the duplicates while also maintaining
consistent order for them.
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
This boolean parameter is added to check_and_set_roots() and detect_lib_dirs()
when true it will first search the compiler library directories before checking
the standard lib directories. This is set to false when using BOOST_ROOT and
set to true when useing other system directories like /usr/local
Also simplify using a set to remove duplicate lib files
Also remove the part where you search the Cellar in homebrew, this is
unnescessary now that symlinks can be followed it should find boost
when searching /usr/local so no need to search the Cellar
This does two things:
* allows the library files to be symlinks
* searches `lib` and `lib64` in `BOOST_ROOT` even if it finds lib
directories from the compiler
The first condition is needed for the homebrew on macOS because boost and boost
python are provided in seperate packages and are put together in /usr/local/lib
with symlinks to the library files. The both conditions are needed for high
performace computing environments where dependencies are often provided in
nonstandard directories with symlinks
A test case was added which looks for boost libraries in seperate directories
which have been symlinked to BOOST_ROOT/lib
This both moves the env reading to configuration time, which is useful,
and also simplifies the implementation of the boost dependency. The
simplification comes from being able to delete basically duplicated code
since the values will be in the Properties if they exist at all.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
* Add boost_root support to properties files
This commit implements `boost_root`, `boost_includedir`, and
`boost_librarydir` variable support to native and cross properties
files. The search order is currently environment variables, then
these variables, and finally a platform-dependent search.
* Add preliminary boost_root / boost_includedir tests
Each test contains a fake "version.hpp", as that's how boost detection is
currently being done. We look for this file relative to the root directory,
which probably shouldn't be allowed (it previously was for BOOST_LIBRARYDIR
but not for BOOST_ROOT). It also cannot help with breakage detection in
libraries, however it looks like this wasn't getting tested beforehand.
I've given the two unique version numbers that shouldn't be present in any
stock version of boost (001 and 002).
* Add return type to detect_split_root
* Return empty list when nothing found in BOOST_ROOT, rather than None
* Update boost_root tests
* Create nativefile.ini based on location of run_project_tests.py
* Add fake libraries to ensure boost_librarydir is being used
* Require all search paths for boost to be absolute
* Redo boost search ordering
To better match things like pkg-config, we now look through native/cross files,
then environment variables, then system locations for boost installations.
Path detection does not fall back from one method to the next for properties or
environment variables--if boost_root, boost_librarydir, or boost_includedir is
specified, they must be sufficient to find boost. Likewise for BOOST_ROOT and
friends. pkg-config detection is still optional falling back to system-wide
detection, for Conan.
(Also, fix a typo in test 33's nativefile)
* Correct return type for detect_roots
* Correct boost dependency search order in documentation
* Print debug information for boost library finding, to resolve CI issues
* Handle native/cross file templates in a more consistent way
All tests can now create a `nativefile.ini.in` if they need to use some
parameter that the testing framework knows about but they can't.
* Pass str--rather than PosixPath--to os.path.exists, for Python35
* Look for boost minor versions, rather than boost patch versions in test cases
* Drop fake dylib versions of boost_regex
* Prefer get_env_var to use of os.environ
* Correct error reporting for relative BOOST_ROOT paths
* Bump version this appears in. Also, change "properties file" to "machine file" as that appears to be the more common language.
This is especially useful for Conan, where only the boost.pc
file is provided and manually setting BOOST_ROOT is not a
good solution since it is in a private cache directory.
See #5438
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
This makes the typing annotations basically impossible to get right, but
if we only have one key then it's easy. Fortunately python provides
comprehensions, so we don't even need the ability to pass multiple keys,
we can just [extract_as_list(kwargs, c) for c in ('a', 'b', 'c')] and
get the same result.
This PR significantly improves the handling of the boost library
tags and also ensures that the found libraries are always compatible
(have the same ABI tag). The current setup can also be extended to
filter for additional features (static linking with the runtime, etc.).
Additionally, BOOST_ROOT is better supported (it is now guaranteed
that all found files belong to a single root directory).
Finally, boost.py is now fully annotated (and checked with mypy).
Currently PkgConfig takes language as a keyword parameter in position 3,
while the others take it as positional in position 2. Because most
dependencies don't actually set a language (they use C style linking),
using a positional argument makes more sense. ExtraFrameworkDependencies
is even more different, and duplicates some arguments from the base
ExternalDependency class.
For later changes I'm planning to make having all of the dependencies
use the same signature is really, really helpful.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.