According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
Currently, we only consider the build depends of the Executable being
run when serializing custom targets. However, this is not always
sufficient, for example if the executable loads modules at runtime or if
the executable is actually a python script that loads a built module.
For these cases, we need to set PATH on Windows correctly or the custom
target will fail to run at build time complaining about missing DLLs.
We can now specify the library type we want to search for, and whether
we want to prefer static libraries over shared ones or the other way
around. This functionality is not exposed to build files yet.
Currently, run_target does not get namespaced for each subproject,
unlike executable and others. This means that two subprojects sharing
the same run_target name cause meson to crash.
Fix this by moving the subproject namespacing logic from the BuildTarget
class to the Target class.
With executable(), if the link_with argument has a string as one of it's
elements, meson ends up throwing an AttributeError exception:
...
File "/home/lyudess/Projects/meson/mesonbuild/build.py", line 868, in link
if not t.is_linkable_target():
AttributeError: 'str' object has no attribute 'is_linkable_target'
Which is not very helpful in figuring out where exactly the project is
trying to link against a string instead of an actual link target. So,
fix this by verifying in BuildTarget.link() that each given target is
actually a Target object and not something else.
Additionally, add a simple test case for this in failing tests. At the
moment, this test case just passes unconditionally due to meson throwing
the AttributeError exception and failing as expected. However, this test
case will be useful eventually if we ever end up making failing tests
more strict about failing gracefully (per advice of QuLogic).
This allows a CustomTarget to be indexed, and the resulting indexed
value (a CustomTargetIndex type), to be used as a source in other
targets. This will confer a dependency on the original target, but only
inserts the source file returning by index the original target's
outputs. This can allow a CustomTarget that creates both a header and a
code file to have it's outputs split, for example.
Fixes#1470
Currently sources, generated sources, or objects are considered to be
sources for a target, but link_whole should also fulfill the sources
requirement.
Fixes#2180
Currently meson only considers what compiler/linker were used by a
Target's immediate sources or objects, not the sources of libraries it's
linked with by the link_with and link_while keywords. This means that if
given 3 libraries: libA which is C++, libB which is C, and libC which is
also C, and libC links with libB which links with libA then linking libC
will be attempted with the C linker, and will fail.
This patch corrects that by adding the compilers used by sub libraries
to the collection of compilers considered by meson when picking a
linker.
This adds a new process_compilers_late method to the BuildTarget class,
which is evaluated after process_kwargs is called. This is needed
because some D options need to be evaluated after compilers are
selected, while for C-like languages we need to check the link* targets
for language requirements, and link* targets are passed by kwargs.
This implementation is recursive, since each Target adds it's parent's
dependencies.
Currently if a target uses link_whole, and one of those archives is a
C++, but the files for the target are C linking will fail when the C
linker attempts to link the C++ files. This patches add
link_whole_targets to the list of languages in the target so the correct
linker will be selected.
Add a boolean 'implib' kwarg to executable(). If true, it is permitted to
use the returned build target object in link_with:
On platforms where this makes sense (e.g. Windows), an implib is generated
for the executable and used when linking. Otherwise, it has no effect.
(Rather than checking if it is a StaticLibrary or SharedLibary, BuildTarget
subclasses gain the is_linkable_target method to test if they can appear in
link_with:)
Also install any executable implib in a similar way to a shared library
implib, i.e. placing the implib in the appropriate place
Add tests of:
- a shared_module containing a reference to a symbol which is known (at link
time) to be provided by the executable
- trying to link with non-implib executables (should fail)
- installing the implib
(This last one needs a little enhancement of the installed file checking as
this is the first install test we have which needs to work with either
MSVC-style or GCC-style implib filenames)
- Adds a `crate_type` kwarg to library targets, allowing the different
types of Rust [linkage][1].
- Shared libraries use the `dylib` crate type by default, but can also
be `cdylib`
- Static libraries use the `rlib` crate type by default, but can also
be `staticlib`
- If any Rust target has shared library dependencies, add the
appropriate linker arguments, including rpath for the sysroot of the
Rust compiler
[1]: https://doc.rust-lang.org/reference/linkage.html
This class now consolidates a lot of the logic that each external
dependency was duplicating in its class definition.
All external dependencies now set:
* self.version
* self.compile_args and self.link_args
* self.is_found (if found)
* self.sources
* etc
And the abstract ExternalDependency class defines the methods that
will fetch those properties. Some classes still override that for
various reasons, but those should also be migrated to properties as
far as possible.
Next step is to consolidate and standardize the way in which we call
'configuration binaries' such as sdl2-config, llvm-config, pkg-config,
etc. Currently each class has to duplicate code involved with that
even though the format is very similar.
Currently only pkg-config supports multiple version requirements, and
some classes don't even properly check the version requirement. That
will also become easier now.
Robert Bragg