Fixes Issue #4323.
The check to see if a call to configure_file() overwrites the output of
a preceding call should perform the substitution for the output file
before doing the check.
Added tests to ensure the proper behaviour.
using state.subdir will cause / or \ to be inserted into the target name.
Replace them with @ to future-proof it.
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
It's much better to directly query the machine in question rather than
do some roundabout "is_cross" thing. This is the first step for much
natve- and cross- code path deduplication.
For existing use cases, pointer equality sufficies, but structural is
much better going forward: these are intended to be immutable
descriptors of the machines.
Instead of just putting these together in the interpreter, put them
together in `environment.py` so Meson's implementation can also better
take advantage of them.
Meson 0.48.0 some validation for using compiled binaries in custom
targets and generators, which is nice. It didn't take into account
though that as long as the OS is the same, some architectures support
running a related architecture natively (x86_64 can run x86 natively,
for example).
Fortunately we already have a method for covering this case available
through the Environment class.
Fixes#4254
meson.add_dist_script, introduced in #3906, did not accept any arguments
other than script name. Since all other meson.add_*_script methods
do accept args, this makes the dist script accept them as well.
This has the adventage that "meson --help" shows a list of all commands,
making them discoverable. This also reduce the manual parsing of
arguments to the strict minimum needed for backward compatibility.
In get_library_dirs() we are trusting the compiler to return a correct
list of directories to search for libraries, based on whether or not
we are compiling 64-bit or 32-bit. Unfortunately, this is often not the
case, as 64-bit libraries often are returned when compiling with -m32 on
a 64-bit OS.
Since system directories do not contain a mix of libraries, the solution
here is to check each directory, by picking a .so file in the directory
and checking whether its 64-bit or 32-bit. If we can't determine if we
want 32-bit or 64-bit, just skip the checks and assume the directory is
good.
Autotools will add endianess to the name of the architecture in some
cases (such as ppc64le vs ppc64) meson doesn't do this. It's worth
noting this in the documentation.
Determine the type of the Windows resource compiler by looking at its
output, not its name.
Also log the name and version of the resource compiler we are using.
Before, the mappings has been created over all the links, while it
actaully only used the Shared or Static Targets. This structure now is
tree like structured and cached, thus the results can be computed a lot
faster.
The generator step generate_install is now for EFL from 6 sec. down to
0.3s. Which improves the overall build time from ~20 sec. to ~14 sec.
there is a huge amount of isinstance calls, this reduces the amount of
these calls while splitting up a rather big function. It also assosiates
every target type with theire default install directory.
Instead of trying to hardcode which versions of which OSes are
misconfiguring llvm-config, lets try to use a generic mechanism that
catches most of the broken cases.
If a dynamic lib is built but the tools are linked staticly
(LLVM_BUILD_LLVM_DYLIB=true and LLVM_LINK_LLVM_DYLIB=false) and you
don't enabled shared libs (LLVM_BUILD_SHARED_LIBS=false, which should be
false), then llvm-config will mistakenly return a each static library
with .(so|dll|dylib) appended, instead of -lLLVM-x.y.z. if
LLVM_LINK_LLVM_DYlIB is true this works fine. There's been a bug opened
in upstream since 2014 about this with no responses[1].
So, this patches looks at --shared-mode (which tells us whether
llvm-config was linked staticly or dynamicly), then if the shared-mode
is static it will check and see what it gets. If it gets valid results
then it will go with those, if it doesn't then it will try to build a
set of valid link arguments to link with libLLVM.(so|dll|dylib).
[1] https://bugs.llvm.org/show_bug.cgi?id=19937
The versions of LLVM provided by brew have the same configuration problem that
dragonflyBSD and FreeBSD do, which means that they produce wrong results for
shared linking.
When passing static libraries to gtkdoc, they are also appended as
shared libraries to ldflags, which makes the process to fail.
This has been changed to only append shared libraries to ldflags.
Fixes#3935
Otherwise if we for some reason get '/usr/lib/../lib' in there
we end up saying it is not a system path.
And for some reason here I got:
```
$ pkg-config --libs libffi 148 ST 117 hotdoc
-L/usr/lib/../lib -lffi
```
Mohammed Amer Khalidi
Christoph Behle
Masanori Kakura
Marty E. Plummer
John Ericson
Xavier Claessens
Jussi Pakkanen
John Ericson
Dylan Baker
Jan Tojnar
Mike Gilbert
dx-mon
Nirbheek Chauhan
Patrick Griffis
Bruce Richardson
Jon Turney
Marcel Hollerbach
Martin Storsjö
Guillermo Ignacio Enriquez Gutierrez
Kostiantyn Ponomarenko
Iñigo Martínez
Salamandar
Xavier RENE-CORAIL
Thibault Saunier