| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
|
|
Closes #4281.
|
|
This reduces the build time about 2 sec. The result itself is not hard
to calculate. However, persistent join calls with the same 2 strings are
not that usefull. This also caused about 600'000 calls to
get_target_dir, we are now down to 60'000 calls form this function to
get_target_dir.
|
|
$ flake8 | grep -E '(E128|E203|E221|E226|E303|W291|W293)'
./mesonbuild/backend/backends.py:32:1: E303 too many blank lines (3)
./mesonbuild/modules/i18n.py:90:56: E128 continuation line under-indented for visual indent
|
|
$ flake8 | grep F401
./mesonbuild/minstall.py:15:1: F401 'gzip' imported but unused
./mesonbuild/backend/backends.py:26:1: F401 '..compilers.get_macos_dylib_install_name' imported but unused
./mesonbuild/backend/backends.py:29:1: F401 'functools.lru_cache' imported but unused
./mesonbuild/scripts/dist.py:27:1: F401 'mesonbuild.dependencies.ExternalProgram' imported but unused
|
|
Remove the code responsible for implicitly compressing manpages as .gz
files. It has been established that manpage compression is a distro
packager's task, with existing distros already having their own
implementations of compression.
Fixes #4330
|
|
On Android executables must be position independent, many
distributions enable it by default too for security reasons.
|
|
If builddir and sourcedir have different drive letters, a relative path
doesn't exist, and os.path.relpath fails with a ValueError exception.
This just fixes the places which are hit by test cases in a simple-minded
way. There are several other uses of os.path.relpath(), which might be
suspect.
|
|
Meson 0.48.0 some validation for using compiled binaries in custom
targets and generators, which is nice. It didn't take into account
though that as long as the OS is the same, some architectures support
running a related architecture natively (x86_64 can run x86 natively,
for example).
Fortunately we already have a method for covering this case available
through the Environment class.
Fixes #4254
|
|
Before, the mappings has been created over all the links, while it
actaully only used the Shared or Static Targets. This structure now is
tree like structured and cached, thus the results can be computed a lot
faster.
The generator step generate_install is now for EFL from 6 sec. down to
0.3s. Which improves the overall build time from ~20 sec. to ~14 sec.
|
|
there is a huge amount of isinstance calls, this reduces the amount of
these calls while splitting up a rather big function. It also assosiates
every target type with theire default install directory.
|
|
Otherwise if we for some reason get '/usr/lib/../lib' in there
we end up saying it is not a system path.
And for some reason here I got:
```
$ pkg-config --libs libffi î˛ 148 î˛ ST 117 îł î hotdoc
-L/usr/lib/../lib -lffi
```
|
|
This improves the backend generation time for gst-build from 7.4s to
6.6s. This is probably all the low-hanging fruit we can get, further
improvements will probably require refactoring, moving to pathlib.Path
or reimplementing CompilerArgs:
222045 0.551 0.000 1.324 0.000 compilers.py:666(__iadd__)
3691 0.230 0.000 0.885 0.000 ninjabackend.py:99(write)
233560 0.441 0.000 0.701 0.000 posixpath.py:75(join)
882 0.141 0.000 0.636 0.001 backends.py:509(generate_basic_compiler_args)
256301 0.248 0.000 0.576 0.000 compilers.py:562(_can_dedup)
37369 0.035 0.000 0.466 0.000 compilers.py:652(extend_direct)
74650 0.067 0.000 0.431 0.000 compilers.py:641(append_direct)
158153 0.089 0.000 0.405 0.000 ninjabackend.py:129(<lambda>)
845 0.064 0.000 0.391 0.000 ninjabackend.py:279(get_target_generated_sources)
58161 0.070 0.000 0.317 0.000 backends.py:217(get_target_generated_dir)
216825 0.175 0.000 0.275 0.000 ninjabackend.py:48(ninja_quote)
845 0.058 0.000 0.255 0.000 ninjabackend.py:2289(guess_external_link_dependencies)
845 0.068 0.000 0.239 0.000 backends.py:793(get_custom_target_provided_libraries)
52101 0.030 0.000 0.237 0.000 compilers.py:716(append)
1319326 0.231 0.000 0.231 0.000 {built-in method builtins.isinstance}
1189117 0.229 0.000 0.229 0.000 {method 'startswith' of 'str' objects}
3235 0.102 0.000 0.228 0.000 compilers.py:614(to_native)
Note: there are 845 build targets.
|
|
The problem with the earlier position of the generation code was, that
the results could not be cached, because the list of all link_deps was
overall different. However, it shared a special kind of subsets with
other build build targets.
Generating the set of subdirs that are required for linking, alongside
with the link dependencies brings the possibility of caching this.
This reduces the buildting from 1 min. in efl down to 20 sec. And
reduces the amount of 30872534 calls down.
this saves ~40 sec.
|
|
this saves about 6 sec.
|
|
|
|
|
|
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
Closes https://github.com/mesonbuild/meson/issues/3881
|
|
|
|
Shared modules may be resource-only DLLs, or might automatically
self-initialize using C constructors or WinMain at DLL load time.
When an import library is not found for a shared module, just print
a message about it instead of erroring out.
Fixes #3965
|
|
Be more permissive about not-found exe_wrapper
|
|
Add install target to VS
|
|
|
|
|
|
|
|
We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
|
|
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
|
|
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
|
|
To me, this looks like a mistake in 976c9abc, but perhaps there's something
I don't understand going on here.
|
|
Since `build_always` also adds a target to the set of default targets,
this option is marked deprecated in favour of the new option
`build_always_stale`.
`build_always_stale` *only* marks the target to be always considered out
of date, but does *not* add it to the set of default targets.
The old behaviour can still be achieved by combining
`build_always_stale` with `build_by_default`.
fixes #1942
|
|
On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).
However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.
We now change that install name to point to the absolute path to each
built library after installation.
Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077
With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.
|
|
We reuse the same function for generating PATH, and we don't want to
exclude system paths there for obvious reasons.
|
|
Lookup the library paths using the available compilers instead.
This makes the code work on non-Linux platforms too.
|
|
|
|
|
|
These directories contain DLLs that the executable may need, such as
libstdc++-6.dll, libwinpthread, etc.
|
|
This ensures that all the system DLLs required by executables such as
libstdc++-6.dll can be found out of the box and tests can run
|
|
When the exe runner is `wine` or `wine32` or `wine64`, etc.
This allows people to run tests with wine.
Note that you also have to set WINEPATH to point to your custom
prefix(es) if your tests use external dependencies.
Closes https://github.com/mesonbuild/meson/issues/3620
|
|
|
|
.. for executable arguments too.
This makes it possible to pass an executable to a test, which
can then run it in an appropriate environment.
|
|
|
|
No functionality changes
|
|
|
|
|
|
Fixes: #3494
|
|
Introduce install_umask to determine permissions of files in install tree. Default it to 022
|
|
To maintain backward compatibility we cannot add recursive objects by
default. Print a warning when there are recursive objects to be pulled
and the argument is not set. After a while we'll do pull recursive
objects by default.
|
|
Fixes #3401
|
|
- determine_ext_objs: What matters is if extobj.target is a unity build,
not if the target using those objects is a unity build.
- determine_ext_objs: Return one object file per compiler, taking into
account generated sources.
- object_filename_from_source: No need to special-case unity build, it
does the same thing in both code paths.
- check_unity_compatible: For each compiler we must extract either none
or all its sources, taking into account generated sources.
|
|
This option controls the permissions of installed files (except for
those specified explicitly using install_mode option, e.g. in
install_data rules.)
An install-umask of 022 will install all binaries, directories and
executable files with mode rwxr-xr-x, while all data and non-executable
files will be installed with mode rw-r--r--.
Setting install-umask to the string 'preserve' will disable this
feature, keeping the permissions of installed files same as the files in
the build tree (or source tree for install_data and install_subdir.)
Note that, in this case, the umask used when building and that used when
checking out the source tree will leak into the install tree.
Keep the default as 'preserve', to show that no behavior is changed and
all tests keep passing unchanged.
Tested: ./run_tests.py
|
