Currently, the backend has "x86_64" hardcoded as the architecture,
which breaks cross compiling and compiling normally on arm64. Fix
this by setting it to the host machine's CPU architecture instead.
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
This change fixes two usability issues with the genvslite project
generation. Unlike when using the full VS backend, under genvslite the
ProjectName property wasn't being set for generated projects. This means
projects end up being named according to the project files, which
includes suffixes like "@exe" in the solution, which is undesirable.
This change adds the ProjectName field in for genvslite projects, to
keep the naming consistent with projects under the VS backend.
Additionally, previously under genvslite, no projects were set to build
under any solution configuration by default. This is inconvenient, as
the user has to manually edit the build settings for each solution
configuration before they can compile at the solution level. There was a
note in the code to do something about this. This change enables
compilation at the solution level for the default startup project in the
solution, so the user can now just press F5 to build the solution and
run the default startup project, as they would typically expect.
On Linux many .so's are augmented with version information,
e.g. libxyz.so.1.2.3. CMake will happily refer to these versioned .so's
in its dependencies instead of libxyz.so (typically a symlink).
Unfortunately these versioned .so's aren't recognized as libraries by
the Backend's logic to produce build rpaths from library paths.
Fix this by recognizing any .so extension as sufficient reason to
produce a build rpath, not just if .so is the last extension.
* Vala: depend on gresources
Valac uses gresource at compile time to look up .ui files
* Automatically pass `--gresourcesdir` to valac
* gnome.compile_resources: clean up duplicate paths better
* Add a test for improved gresouce handling
Standard include paths need to be added to resolve STL and platform
headers. Additionally, compiler args need to be separated by spaces, not
semicolons, in order to be recognised.
Nvcc doesn't support `-MQ` flag, so we have to manually escape cuda
target name.
This commit escape `$out` to `$CUDA_ESCAPED_TARGET`, so now we can just
use `-MT` flag in nvcc to generate header dependencies.
Anywhere we have that, we also have the Environment object, which is
just wrapped by the Interpreter methods anyway. This avoids inderections
that are unnecessary.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
mypy will complain if backends.Backend has a lru_cache wrapped method,
but it is overridden in XCodeBackend with a method that isn't cached.
This is almost certainly a sign that we should be caching it here too
anyway. The generic backend cache was added years ago via an
intimidating commit f39d2cc3bf which
claims that it reduced call time from 60s to 0.000435s and that this was
specifically due to getting a coredata option every single time. This is
probably workload dependent, but getting an option is *not* nearly as
cheap as a throwaway function call.
Xcode does not recognize our private directories, nor does it ever
try to generate them. Instead, just import the build directories
for each swift dependency.
This fixes linking between swift targets when they are in their own
subdirectories, as they will have different build directories in that
case.
When generating aggregated targets, custom targets were not being
checked for dependencies when they should have.
Fixes passing swift test case 4 (generate).
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