This must be explicitly set in Xcode or it will not be able to compile
mixed targets successfully. This is not needed for pure Swift targets.
Set a new variable "is_swift" so finding the bridging header does not
take O(n^2) time.
Fixes passing swift test case 5 (mixed) with Xcode backend.
Meson supports other transpilers generating source code for which
compilation rules need to be generated other than Vala. Reflect this
in variable names and comments to avoid confusion.
This commit modifies the get_target_filename_for_linking function to
always return POSIX-style paths, even on Windows systems. This is
necessary because the Ninja generator can have issues with Windows-style
paths when using the `/WHOLEARCHIVE:` flag.
This is consistent with the syntax accepted by the cl and clang-cl
compilers, as documented in the Microsoft documentation:
https: //learn.microsoft.com/en-us/cpp/build/reference/cl-filename-syntax?view=msvc-170
Fixes: 12534
This was originally added for vala only, with the rationale that vala
generates bad code that has warnings. Unfortunately, the rationale was
fatally flawed. The compiler warns about a number of things, which the
user can control depending on their code (or their code generator's
code), but some of those things are absolutely critical to warn about.
In particular, GCC 14 and clang 17 are updating their defaults to warn
-- and error by default for -- invalid C code that breaks the standard,
but has been silently accepted for over 20 years "because lots of people
do it". The code in question is UB, and compilers will generate faulty
machine code that behaves erroneously and probably has a mass of CVEs
waiting to happen.
Compiler warnings are NOT safe to just... universally turn off. Compiler
warnings could be either:
- coding style lints
- threatening statements that the code is factually and behaviorally wrong
There is no magic bullet to ignore the former while respecting the
latter. And the very last thing we should ever do is pass `-w`, since
that causes ALL warnings to be disabled, even the manually added
`-Werror=XXX`.
If vala generated code creates warnings, then the vala compiler can
decrease the log level by generating better code, or by adding warning
suppression pragmas for *specific* issues, such as unused functions.
EmbedManifest seems to default to true, which creates a default manifest based
on other parameters (likewise defaults) and makes it impossible to supply your
own with CREATEPROCESS_MANIFEST_RESOURCE_ID. There is value to being able to do
this and no value to the default one, so this should be disabled.
* unity builds: correct integer ceiling division
* edge case failure with unity builds:
- static archive bar that gets installed, that links with another static
archive foo that does not get installed
- the number of files in static archive foo is divisible by unity_size
would yield an error with ninja:
ninja: error: 'subprojects/foo/src/libfoo.a.p/meson-generated_foo-unity1.cpp.o', needed by 'src/libbar.a', missing and no known rule to make it
* unity builds: test for build failure when #files is divisible by unity_size
In the case r1 -> s1 -> s2 where s1 and s2 are uninstalled C static
libraries, the libs1.a rule does not depend on libs2.a. That means that
r1 rule must depend on both s1 and s2.
Pass link arguments directly down to linker by using `-C link-args=`
instead of letting rustc/linker resolve `-l` arguments. This solves
problems with e.g. +verbatim not being portable. Note that we also pass
`-l` args as `-Clink-args=-l` because rustc would otherwise reorder
arguments and put `-lstdc++` before `-Clink-args=libfoo++.a`.
However, when building a rlib/staticlib we should still use `-l`
arguments because that allows rustc to bundle static libraries we
link-whole. In that case, since there is no platform specific dynamic
linker, +verbatim works.
This also fix installed staticlib that now bundle uninstalled static
libraries it links to (recursively). This is done by putting them all
into self.link_whole_targets instead of putting their objects into
self.objects, and let rustc do the bundling. This has the extra
advantage that rustc can bundle static libries built with CustomTarget.
Disable bundling in all other cases, otherwise we could end up with
duplicated objects in static libraries, in diamond dependency graph
case.
Fixes: #12484
When a user invokes the scan-build target that Meson generates
all subprojects are included in the resulting report. This commit
modifies the invocation of scan-build to exclude all bugs that
scan-build finds in the subprojects from the final report.
A release note has also been added describing the changed behaviour.
Reduce code duplication by iterating target.get_dependencies() instead
of iterating target.link_targets and target.link_whole_targets
separately. This has the extra benefit of taking into account
transitive dependencies.
- For indirect C ABI static libraries, this adds missing "-l static="
arguments.
- For indirect Rust ABI dependencies, this adds missing "-L" arguments.
- Verbatim modifier was used only for link_whole_targets, it's now
always used when available.
Fixes: #11694
Previously, AIX support was updated to archive shared libraries per AIX
platform conventions, which expect .a files that contain .so files. This
is usually correct, but an edge case occurs for loadable plugins, e.g.
what meson creates for `shared_module()`. A notable example is python
extensions (SciPy, for example).
These should *not* be archived, because the .so file itself needs to be
loaded as a plugin. For example, SciPy fails to import in the python
interpreter.
Handle this by differentiating between plugins and regular libraries,
and only archiving when safe to do so.
Fixes#12219
The MSVC linker errors out if a line in the rspfile is too long.
The resolution is to use the built-in ninja keyword $in_newline instead of $in, which splits each input into separate lines.
This also moves the repacking into the interpreter, making the build
implementation simpler and removing a layering violation. This also
makes use a defaultdict to remove the need to call `.get()`
Way back in Meson 0.25, support was added to `vala_args` for Files.
Strangely, this was never added to any other language, though it's been
discussed before. For type safety, it makes more sense to handle this in
the interpreter level, and pass only strings into the build IR.
This is accomplished by adding a `depend_files` field to the
`BuildTarget` class (which is not exposed to the user), and adding the
depend files into that field, while converting the arguments to relative
string paths. This ensures both the proper build dependencies happen, as
well as that the arguments are always strings.
lcov 2.0 deprecates `--rc lcov_branch_coverage=1` for `--rc branch_coverage=1` and
gives an error when an exclude is used on a non existing directory.
I added a version check for lcov and removed the subprojects directory from the
exclusion list if it does not exist.
Fixes#11995
The MSVC code is extremely confusing, and it turns out it actually
constructs debug (pdb) files names/path independently in separate
places. This is really hard to parse. Instead, refactor it so that the
source of the debug filename is within the target itself
(get_debug_filename). Add a couple of generic methods to retrieve the
full path of the debug filename name in the backend and use that when
needed.
Add the `clang-tidy-fix` target to apply clang-tidy fixes to the source
code.
This is done by calling `run-clang-tidy` with `-fix` argument.
Add a test case to run `clang-tidy-fix` and verify the file is changed.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Rustc expects to be provided both a search path `-L`, and a link arg `-l
kind=libname`, but we don't handle that correctly. Because we combine -L
and -l arguments from pkg-config the backend must rematerialize the -L
and -l split. We currently don't do this for static archives.
Rustc does not produce object files we can reuse to build both
libraries. Ideally this should be done with a single target that has
both `--crate-type` arguments instead of having 2 different build rules.
As temporary workaround, build twice and ensure they don't get conflicts
in intermediary files created by rustc by passing target's private
directory as --out-dir.
See https://github.com/rust-lang/rust/issues/111083.
Added to existing '/I' and '-I' extraction with '-isystem', '/clang:-isystem', '/imsvc', '/external:I', which are forms of 'system' header include search path options for gcc, clang, clang-cl, and cl (msvc).
Factored 3 separate 'extract_...(...)' functions into one since they were always called together on the same args; a new combined '_extract_nmake_fields(...)' func avoids repeated iterations and checks.
Installing python sources causes the python module to call
create_install_data() before Ninja backends adds extra outputs to Vala
targets.
Target objects are supposed to be immutable, adding outputs that late is
totally wrong. Add extra vala outputs immediately, but be careful
because the main output is only added later in post_init(). Luckily
the base class already puts a placeholder item in self.outputs for the
main filename so we can just replace self.outputs[0] instead of
replacing the whole list which would contain vala outputs at that stage.
This is surprisingly what SharedLibrary was already doing.
Apple's AR is old, and doesn't add externed symbols to the symbol table,
instead relying on the user calling ranlib with -c. We need to do that
for the user
The most notable problem this causes is that when running `meson setup
--reconfigure` the build.ninja file is erroneously seen as out of date,
so ninja immediately tries to regenerate it again as it didn't see the
file get updated.
There are two problems.
The first problem is that we looked for the wrong file. Ninja creates a
few internal files, and one of them is the one we care about:
`.ninja_log`, which contains stat'ed timestamps for build outputs to aid
in checking when things are out of date. But the thing we actually
checked for is `.ninja_deps`, a file that contains a compressed database
of depfile outputs. If the latter exists, then the former surely exists
too.
Checking for the wrong file meant that we would restat outputs, but only
when some build edges were previously built that had depfile outputs.
The second problem is that we checked for this in os.getcwd() instead of
the configured build directory. This very easily fails to be correct,
except when reconfigure is triggered directly by ninja itself, in which
case we didn't need the restat to begin with.
On my project, this function was a bottleneck in setup time.
By properly caching it, the cumtime for this function
went from 26s to 4.3s when I profiled it.
This fixes two issues in constructing the default installation path
when install_dir is not specified:
- inside a subproject, install_data() would construct the destination
path using the parent project name instead than the current project
name,
- when specifying preserve_path, install_data() would construct the
destination path omitting the project name.
Fixes#11910.
Since it's deprecated anyway, we don't really want to plumb it all the
way down into the build and backend layers. Instead, we can just turn
it into a `win_subsystem` value in the interpreter if `win_subsystem`
isn't already set.