Age | Commit message (Collapse) | Author | Files | Lines |
|
Still a work in progress
|
|
|
|
test cases\common\135 generated assembly: rename copy.py
|
|
os.path.commonpath (and our implementation of it) both always return the
path using the native operating system path separator, so we can't just
directly compare it since the prefix could be specified in '/', and
commonpath would use '\' on Windows.
Also add a unit test for this.
|
|
|
|
On some distros, running this causes Python to find the file itself as
the implementation of the `copy` module:
$ python3 copy.py
Traceback (most recent call last):
File "copy.py", line 4, in <module>
import shutil
File "/usr/lib/python3.4/shutil.py", line 14, in <module>
import tarfile
File "/usr/lib/python3.4/tarfile.py", line 48, in <module>
import copy
File "/c/Users/nirbheek/projects/meson.git/test cases/common/134 generated llvm ir/copy.py", line 6, in <module>
shutil.copyfile(sys.argv[1], sys.argv[2])
AttributeError: 'module' object has no attribute 'copyfile'
|
|
because down the import dependency chain of copy.py the 'tarfile' module
was trying to import the 'copy' standard library module but was finding
the copy.py file first because it was in the current directory.
Closes https://github.com/mesonbuild/meson/issues/1359
|
|
Add our own implementation of os.path.commonpath
|
|
See: https://github.com/mesonbuild/meson/issues/1348
|
|
It's only useful to use those when you have to override include dirs
or library paths by appending them from various sources according to
the priority order, or if the compiler args need to be converted from
Unix/GCC-style to native (MSVC, for instance) style.
Sanity checks match neither of these.
Closes https://github.com/mesonbuild/meson/issues/1351
|
|
To reproduce, one could write:
foo = files('foo.c')
foo[0].path()
and get:
Traceback (most recent call last):
[snip]
File "/home/trhd/Projects/meson/mesonbuild/interpreterbase.py", line 398, in method_call
raise InvalidArguments('Variable "%s" is not callable.' % object_name)
UnboundLocalError: local variable 'object_name' referenced before assignment
Fix this by handling file objects separately.
|
|
Closes https://github.com/mesonbuild/meson/issues/1349
|
|
InternalTests can be run on all platforms since they have nothing
Linux-specific.
|
|
os.path.commonpath was added in Python 3.5, so just write our own for
now. pathlib was added in Python 3.4, so this should be ok. We need to
use that instead of doing str.split() etc because Windows path handling
has a lot of exceptions and pathlib handles all that for us.
Also adds a unit test for this.
|
|
|
|
|
|
|
|
|
|
tests: check custom target output is created before being used in a t…
|
|
Improve compiler argument handling with a new class CompilerArgs derived from list()
|
|
Implement a quiet option that can be used to hide OK messages for
successful tests to better highlight the failing ones.
|
|
|
|
At the same time also fix the order in which they are added. They now
match the order used in the Ninja backend.
|
|
Don't tell me how to format my comments!
|
|
Also, now the linker options are added from various sources in the same
order as compiler arguments for compile commands. As a result, all
libraries and library paths from external and internal sources are added
after all the linker options have been added.
As a result option_link_args() are added when libraries are added to the
list since currently the only thing they add are the libraries specific
in cpp_winlibs/c_winlibs. This fixes an issue where compilation with the
MinGW toolchain (which uses static libraries for winlibs) would result
in undefined symbol errors because the static libraries would be added
in the very beginning and hence would not be scanned for symbols.
Detailed comments have been added that explain where each option is
coming from and why it's been added at that specific point.
More improvements are necessary here because we currently still
unnecessarily repeat libraries from dependencies over and over, which
is a major problem in gst-build because inter-subproject dependencies
cause linker command-lines to almost exceed the argument list length
limit imposed by the kernel. It is also causing us to unnecessarily
add static libraries which have already been linked into a shared
library. See: self.build_target_link_arguments()
|
|
|
|
Helps debug issues with include directory handling.
|
|
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
|
|
While reading shebangs, when we detect an attempt to run 'python3', use
sys.executable instead. For example:
#!/usr/bin/python3
#!python3
#!/usr/bin/env python3
|
|
Without this, the test isn't testing for anything at all.
This revealed that custom target output capturing was actually broken on
the VS backends.
|
|
Back in November when this broke, we didn't notice because our tests
are run in-process, so we don't check that `msbuild RUN_TESTS.vcxproj`
and `ninja test` actually work.
Now we do.
|
|
Always generate the vcxproj file, but only add it to the build
configuration if it's either supposed to be built by default, or is
a dependency of another target that is built by default.
|
|
Also add a test() that can be run on all platforms.
Currently unit tests are only run on Linux, so this was only testing the
Ninja backend. This change reveals that build-by-default was broken with
the Visual Studio backend.
|
|
Previously, build_by_default=false targets would not be built at all
even if they were used in a test (as the exe or as a command-line
argument) which would lead to a test failure.
Now we look into all the defined tests and add all CustomTargets and
BuildTargets used in them to the list of build_by_default targets.
|
|
The next commit fixes this.
|
|
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
|
|
If the index is out of range, the fallback value is used. Includes
a test.
Closes #1337
|
|
Add prefix before including limits.h in has_function checks
|
|
The prefix has been recently added to the install data
|
|
|
|
Makes it difficult to copy the filename/datetime by double-clicking
since that includes the '.' at the end.
|
|
Earlier it would mark tests as "FAIL" even if it skipped.
|
|
MSVC does not have built-ins, so this is totally useless. Instead, add
a test for intrinsics to ensure that we do find them.
|
|
Use a single check for both cases when we have includes and when we
don't. This way we ensure three things:
1. Built-in checks are 100% reliable with clang and on macOS since clang
implements __has_builtin
2. When the #include is present, this ensures that __builtin_func is not
checked for (because of MSYS, and because it is faster)
3. We fallback to checking __builtin_func when all else fails
|
|
prefix might define _GNU_SOURCE, which *must* be defined before your
first include of limits.h, so we must define it first.
There's not really any downsides to including limits.h after the
prefix.
|
|
|
|
This makes it much clearer what each placeholder will be formatted to.
|
|
Our "43 has function" test should also work with clang and icc on Linux,
so enable them. Also detect builtins with __has_builtin if available,
which is much faster on clang.
There is a feature request for the same with GCC too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
|
|
Python 2.
|
|
|