* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
The returned not-found object can be from any type because we were
returning the first of the failed attempts. It also can happen that we
don't have any dependency object in which case we should just return
NotFoundDependency() object as well instead of raising an exception.
That exception was happening before, but dependency_impl() was
calling find_external_dependency() in a try block so it was hidden.
This seems to be related to deleting the current working directory.
Simply deleting all of the trees inside the build directory instead
seems to fix it. This only appears with some combination of generated
targets, running the test case against say "1 trivial" doesn't show the
bug.
See this mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=109071
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes#4091.
llvm-config --libfiles --link-shared wants to link to a bunch of shared
libraries which don't exist, so we end up at dev.py:308, but the guess
that makes ('libLLVM*.dll') doesn't take into account the existence of
implibs (which is fixable), but even if it did 'libLLVM-7.0.dll.a'
doesn't seem to exist... so not sure how to fix this...)
Also some steps towards making that work:
Adjust helper_create_binary_wrapper for MSYS2. The .bat wrapper should
run msys2 python, not try to invoke the 'py' python launcher (which may
not be present)
Suppress echoing of the command in helper_create_binary_wrapper
(otherwise the echoed command can interfere in interpreting the output
of the wrapped command, which seems to be the case when it's
llvm-config)
Daniel Mensinger
Simon McVittie
Xavier Claessens
textshell
John Ericson
Jussi Pakkanen
Dylan Baker
Niklas Haas
Jon Turney
John Ericson
Daniel Schulte