The fix for Requires generation in #3406 missed a second code path with the same
problem.
Passing a pkgconfig dependency to requires would produce Q, t, 5, C, o,r, e'
instead of 'Qt5Core'.
This was introduced in 8efd940.
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.
- 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.
And, with that, update the test cases that checked that preserving the
original permissions worked to set install_umask=preserve explicitly in
those projects' default_options.
Tested: ./run_tests.py
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
The `install` parameter that is present in the `permittedKwargs`
annotation is wrong. The correct parameter name, which is also
consistent with the rest of functions in the `gnome` module, is
`install_dir`.
This implements support for visual studio solution directories.
Projects will by default be put into directories that map their sub-directory
name in the source folder. No directories are created if `--layout=flat` is used.
Fixes: #2524
This adds a new method, partial_dependency to all dependencies. These
sub dependencies are copies of the original dependency, but with one or
more of the attributes replaced with an empty list. This allows creating
a sub dependency that has only cflags or drops link_arguments, for
example.
I'm not really happy about this to be honest, I don't like having both
-- and -D options, I think it's stupid to have two ways to do exactly
the same thing, especially since we then have to validate that someone
hasn't passed the argument both ways.
However, other people want this, so here it is.
Fixes#969
Currently meson only accepts `-Dopt=value` for builtin options when
calling `meson configure` and `--opt=value` for builtin options when
calling `meson` initially. This is a confusing behavior, and users only
get a small warning at the top of a potentially long configuration
summary to catch this.
This has confused end users and developers alike, there are at least 5
duplicates of the bug this fixes, and I have personally been asked about
this more times than I can count. The help documentation doesn't make
it clear that -D cannot be used to set options like prefix and bindir.
This adds support for -D options to the initial meson call, but not --
options to the meson configure call. I think it's better to have one way
to do things, and -- options are kinda one off while -D is used
everywhere else, so lets stick with that.
Related #969
We have all the information needed to calculate the builtin arguments in
the coredata module already, don't duplicate that in the mesonmain
module as well.
Currently we manually pass the argparse action, this isn't very DRY,
since the builtin_types already has all the data necessary to find that.
This adds a new function to determine the action based on the default
type.
Since we want to make the options passed to `meson` and `meson
configure` equivalent, we need to allows pass -D<lang>_args and
-D<lang>_link_args to `meson`. This path assumes that if one is set then
the other must be, which isn't true.
GCC does not print a warning or error for unknown options if the options
are to disable warnings. Therefore, when checking for options starting
'-Wno-', also check the opposite enabling option. This fixes the case
where e.g. -Wno-implicit-fallthrough is incorrectly reported as supported
by gcc 5.4. To avoid missed warnings when using combinations of flags, such
as in test case "112 has arg", we limit the checking of for the positive
option to where the negative option is checked alone.
This patch exploits the information residing in ltversion to set the
-compatibility_version and -current_version flags that are passed to the
linker on macOS.
GNU LD does not use soname when linking a PE/COFF binary, so it makes no
difference, but it breaks when using the llvm linker (lld), which does
not support the soname flag when building PE/COFF binaries for Windows.
Fix#3179
This way they override all other arguments. This matches the order of
link arguments too.
Note that this means -I flags will come in afterwards and not override
anything else, but this is correct since that's how toolchain paths
work normally too -- they are searched last.
Closes https://github.com/mesonbuild/meson/issues/3089
Otherwise we can't do the following workflow:
if not find_program('foo', required : false).found()
subproject('provides-foo')
endif
Where 'provides-foo' has a meson.override_find_program() on
a configure_file() or similar.
The linkers currently do not support ninja compatible output of
dependencies used while linking. Try to guess which files will be used
while linking in python code and generate conservative dependencies to
ensure changes in linked libraries are detected.
This generates dependencies on the best match for static and shared
linking, but this should not be a problem, except for spurious
rebuilding when only one of them changes, which should not be a problem.
Also makes sure to ignore any libraries generated inside the build, to
keep the optimisation working where changes in a shared library only
cause relink if the symbols have changed as well.
Previously pkg-config files generated by the pkgconfig modules for static libraries
with dependencies could only be used in a dependencies with `static: true`.
This was caused by the dependencies only appearing in Libs.private even
if they are needed in the default linking mode. But a user of a
dependency should not have to know if the default linking mode is static
or dynamic; A dependency('somelib') call should always pull in all
needed pieces into the build.
Now for meson build static libraries passed via `libraries` to the generate
method automatically promote dependencies to public.
This caching is only for a single run, so it doesn't help reconfigure.
However, it is useful for subproject setups where different subprojects
will run the same compiler checks.
The cache is also per compiler instance and is not used for functions
that want to read or run the outputted object file or binary.
For gst-build, this halves the number of compiler checks that are run
and reduces configuration time by 20%.