When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
We support this in a machine file:
```
[binaries]
pkgconfig = 'pkg-config'
pkg-config = 'pkg-config'
```
and you can use either one, because internally we look up both. If you
only set *one* of them, this plays awkwardly with setting $PKG_CONFIG,
since we don't know which one you set in the machine file and the
*other* one will be initialized from the environment instead.
In commit 22df45a319 we changed program
lookup of config-tool style dependencies to use the regular tool names
and only fall back on the strange internal names. This affected the
pkg-config class too.
The result is that instead of preferring `pkgconfig =` followed by
$PKG_CONFIG followed by `pkg-config =`, we inverted the lookup order.
This is a good idea anyway, because now it behaves consistently with
`find_program('pkg-config')`.
Unfortunately, we documented the wrong name in a bunch of places, and
also used the wrong name in various testsuite bits, which meant that if
you set $PKG_CONFIG and then ran the testsuite, it would fail.
Correct these references, because they are buggy.
One test case expected to find_program() a native copy for convenience
of testing against natively installed glib. Force it to resolve a native
copy.
When the pkgconfig module is imported, but not used, it will insert None
on the end of the devenv list. This list is not expected to contain
None, and causes Meson to crash. This can happen in complex build setups
(reported from mesa), where pkgconfig is only used in some
configurations
Fixes: #12032
Replace unencodable XML chars with their printable representation, so
that, xmllint can parse test outputs without error.
Closes#9894
Co-authored-by: Tristan Partin <tristan@partin.io>
This fixes regression caused by
3162b901ca
that changes the order in which libraries are put on the link command.
In addition, that commit was wrong because libraries from dependencies
were processed before process_compiler() is called, which that commit
wanted to avoid.
This reverts commit 904b47085f.
This is not a real bottleneck, and we want to create it thrice -- once
before the backend is generated. The final install data needs to be
created fresh.
Update unittest to demonstrate the issue.
Fixes https://bugs.gentoo.org/910050
* Capture all compile args from the first round of ninja backend generation for all languages used in building the targets so that these args, defines, and include paths can be applied to the .vcxproj's intellisense fields for all buildtypes/configurations.
Solution generation is now set up for mutiple build configurations (buildtypes) when using '--genvslite'.
All generated vcxprojs invoke the same high-level meson compile to build all targets; there's no selective target building (could add this later). Related to this, we skip pointlessly generating vcxprojs for targets that aren't buildable (BuildTarget-derived), which aren't of interest to the user anyway.
When using --genvslite, no longer inject '<ProjectReference ...>' dependencies on which a generated .vcxproj depends because that imposes a forced visual studio build dependency, which we don't want, since we're essentially bypassing VS's build in favour of running 'meson compile ...'.
When populating the vcxproj's shared intellisense defines, include paths, and compiler options fields, we choose the most frequent src file language, since this means more project src files can simply reference the project shared fields and fewer files of non-primary language types need to populate their full set of intellisense fields. This makes for smaller .vcxproj files.
Paths for generated source/header/etc files, left alone, would be added to solution projects relative to the '..._vs' build directory, where they're never generated; they're generated under the respective '..._[debug/opt/release]' ninja build directories that correspond to the solution build configuration. Although VS doesn't allow conditional src/header listings in vcxprojs (at least not in a simple way that I'm aware of), we can ensure these generated sources get adjusted to at least reference locations under one of the concrete build directories (I've chosen '..._debug') under which they will be generated.
Testing with --genvslite has revealed that, in some cases, the presence of 'c:\windows\system32;c:\windows' on the 'Path' environment variable (via the make-style project's ExecutablePath element) is critical to getting the 'meson compile ...' build to succeed. Not sure whether this is some 'find and guess' implicit defaults behaviour within meson or within the MSVC compiler that some projects may rely on. Feels weird but not sure of a better solution than forcibly adding these to the Path environment variable (the Executable Path property of the project).
Added a new windows-only test to windowstests.py ('test_genvslite') to exercise the --genvslite option along with checking that the 'msbuild' command invokes the 'meson compile ...' of the build-type-appropriate-suffixed temporary build dir and checks expected program output.
Check and report error if user specifies a non-ninja backend with a 'genvslite' setup, since that conflicts with the stated behaviour of genvslite. Also added this test case to 'WindowsTests.test_genvslite'
I had problems tracking down some problematic environment variable behaviour, which appears to need a work-around. See further notes on VSINSTALLDIR, in windowstests.py, test_genvslite.
'meson setup --help' clearly states that positional arguments are ... [builddir] [sourcedir]. However, BasePlatformTests.init(...) was passing these in the order [sourcedir] [builddir]. This was producing failures, saying, "ERROR: Neither directory contains a build file meson.build." but when using the correct ordering, setup now succeeds.
Changed regen, run_tests, and run_install utility projects to be simpler makefile projects instead, with commands to invoke the appropriate '...meson.py --internal regencheck ...' (or install/test) on the '[builddir]_[buildtype]' as appropriate for the curent VS configuration. Also, since the 'regen.vcxproj' utility didn't work correctly with '--genvslite' setup build dirs, and getting it to fully work would require more non-trivial intrusion into new parts of meson (i.e. '--internal regencheck', '--internal regenerate', and perhaps also 'setup --reconfigure'), for now, the REGEN project is replaced with a simpler, lighter-weight RECONFIGURE utility proj, which is unlinked from any solution build dependencies and which simply runs 'meson setup --reconfigure [builddir]_[buildtype] [srcdir]' on each of the ninja-backend build dirs for each buildtype.
Yes, although this will enable the building/compiling to be correctly configured, it can leave the solution/vcxprojs stale and out-of-date, it's simple for the user to 'meson setup --genvslite ...' to fully regenerate an updated, correct solution again. However, I've noted this down as a 'fixme' to consider implementing the full regen behaviour for the genvslite case.
* Review feedback changes -
- Avoid use of 'captured_compile_args_per_buildtype_and_target' as an 'out' param.
- Factored a little msetup.py, 'run(...)' macro/looping setup steps, for genvslite, out into a 'run_genvslite_setup' func.
* Review feedback: Fixed missing spaces between multi-line strings.
* 'backend_name' assignment gets immediately overwritten in 'genvslite' case so moved it into else/non-genvslite block.
* Had to bump up 'test cases/unit/113 genvslites/...' up to 114; it collided with a newly added test dir again.
* Changed validation of 'capture' and 'captured_compile_args_...' to use MesonBugException instead of MesonException.
* Changed some function param and closing brace indentation.
This reverts commit a2def550c5.
This results in a 2k line file being unconditionally imported at
startup, and transitively loading two more (for a total cost of 2759
lines of code), and it's not clear it was ever needed to begin with...
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc.
We don't need a CMakeInterpreter until and unless we actually attempt to
use a cmake subproject via the cmake module.
Minus 10 files and 3679 lines of code imported at startup.
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
We expose detect.py as the mesonbuild.dependencies entrypoint and import
it upfront everywhere. But unless the `dependency()` function is
actually invoked, we don't need *any* of the private implementations for
this.
Avoid doing so until, as part of actual dependency lookup, we attempt
that specific dependency method. This avoids importing big modules if
`method:` is specified, and in most cases hopefully pkg-config works and
we can avoid importing the cmake implementation particularly.
Actually avoiding most of these imports requires more refactoring. But
even so, the garden path no longer needs to import the dub dependency
impl.
Case 1:
- Prog links to static lib A
- A link_whole to static lib B
- B link to static lib C
- Prog dependencies should be A and C but not B which is already
included in A.
Case 2:
- Same as case 1, but with A being installed.
- To be useful, A must also include all objects from C that is not
installed.
- Prog only need to link on A.
This was added in f774609 to only change the access time of the
coredata file if the coredata struct actually changed. However,
this doesn't work as pickle serializations aren't guaranteed to
be stable. Instead, let's manually check if options have changed
values and skip the save if they haven't changed.
We also extend the associated unit test to cover all the option
types and to ensure that configure does get executed if one of the
options changes value.
These are necessary for projects outside Meson itself that want to
extend the 'meson install' functionality as meson-python does to
assemble Python package wheels from Meson projects.
Fixes#11426.
We do not need the python module's find_installation() for this, as this
does various things to set up building and installing python modules
(pure python and C-API). This functionality is already tested in the
python tests.
Elsewhere, when we just need an interpreter capable of running python
scripts in order to guarantee a useful scripting language for custom
commands, it suffices to use find_program(), which does not run an
introspection script or do module imports, and is thus faster and
a bit cleaner.
Either way, both methods are guaranteed to find the python3 interpreter,
deferring to mesonlib.python_command for that guarantee.
test "71 summary" can sometimes return the python command with the
".exe" part all uppercased for mysterious Windows reasons. Smooth this
over with ExternalProgram.
This method allows meson.build to introspect on the changed options.
It works by merely exposing the same set of data that is logged by
MesonApp._generate.
Fixes#10898
It is often more useful to generate shell script than dumping to stdout.
It is also important to be able to select the shell format.
Formats currently implemented:
- sh: Basic VAR=prepend_value:$VAR
- export: Same as 'sh', but also export VAR
- vscode: Same as 'sh', but without substitutions because they don't
seems to work. To be used in launch.json's envFile.
Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
It was only trying to guess install tag, and log missing tags, for files
installed by install_data(). Do it also for all other files, especially
custom_taget() that commonly installs generated headers.
Currently, if we run "meson configure -Doption=value", meson will
do a reconfigure when running "ninja build" afterwards, even if
the new value is the same one that was already configured previously.
To avoid this unnecessary reconfigure, let's use replace_if_different()
instead of unconditionally replacing the conf file in coredata's save()
function.
The check for whether or not a file is allowed to be accessed from a
subproject fails if the subproject is accessed via a symlink. Use the
absolute path of the subproject without resolving symlinks to fix the
check.
Extend unit test 106 to check for this in the future.
When a subproject is disabled on the initial configuration we should not
add it into self.coredata.initialized_subprojects because that will
prevent calling self.coredata.init_builtins() on a reconfigure if the
subproject gets enabled.
Fixes: #10225.
There are a couple issues that combine to make the current handling a
bit confusing.
- we call it "install_dir_name" but it is only ever the class default
- CustomTarget always has it set to None, and then we check if it is
None then create a different variable with a safe fallback. The if is
useless -- it cannot fail, but if it did we'd get an undefined
variable error when we tried to use `dir_name`
Remove the special handling for CustomTarget. Instead, just always
accept None as a possible value of outdir_name when constructing install
data, and, if it is None, fall back to {prefix}/outdir regardless of
what type it used to be.
Fix "Tried to grab file outside current (sub)project" error when subproject exists within
a source tree but it is used through a symlink. Using subprojects as symlinks is very useful
feature when migrating an existing codebase to meson that all sources do not need to be
immediately moved to subprojects folder.
Older versions are not supported by the cmake module since 0.62.
This avoids having to hard-code the linux-bionic-gcc CI job as being
unable to run these tests, which leaves other older environments like
Debian 10 still trying to run them (and failing).
Signed-off-by: Simon McVittie <smcv@collabora.com>
dep.get_variable() only supports string values for pkg-config and
config-tool, because those interfaces use text communication, and
internal variables (from declare_dependency) operate the same way.
CMake had an oddity, where get_variable doesn't document that it allows
list values but apparently it miiiiiight work? Actually getting that
kind of result would be dangerously inconsistent though. Also, CMake
does not support lists so it's a lie. Strings that are *treated* as
lists with `;` splitting don't count...
We could do two things here:
- raise an error
- treat it as a string and return a string
It's not clear what the use case of get_variable() on a maybe-list is,
and should probably be a hard error. But that's controversial, so
instead we just return the original `;`-delimited string. It is probably
the wrong thing, but users are welcome to cope with that somehow on
their own.
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
Tristan Partin