| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
File "data/data3/meson.build" makes Meson create a target
that contains a path separator.
|
|
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>
|
|
|
|
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
|
|
Performance optimize the install part generation
|
|
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.
|
|
Use a single ArgumentParser for all subcommands
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
meson_exe (meson --internal exe)
|
|
|
|
Determine the type of the Windows resource compiler by looking at its output, not its name
|
|
Fixes #3563
|
|
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.
|
|
Xcode does not include configured files in its header search path
|
|
dependencies/llvm: Make llvm-config handling more robust
|
|
D: Add conditional debug compilation flags
|
|
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.
|
|
It turns out we have bugs.
|
|
Factor out determination of the windows resource compiler as
_find_resource_compiler(). Cache the result, so the work is only done once.
|
|
MSVC doesn't support that option, and warns about ignoring an unknown
option.
|
|
With GCC, Clang, or ICC, and for C++
Fixes #2628
|
|
headers can be included/imported in sources
|
|
|
|
|
|
|
|
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
```
|
|
WIP RFC gnome.py cross improvements
|
|
Closes https://github.com/mesonbuild/meson/issues/1977
|
|
Having a period at the end of sentences in messages is confusing when
a file or path is being outputted, and is inconsistent when not.
This is part of an ongoing effort to fix this inconsistency across the
message outputs everywhere in Meson.
|
|
Using the -pthread argument is not needed with clang when compiling for
darwin, and it results in the warning:
warning: argument unused during compilation: '-pthread'
|
|
When cross-compiling we shouldn't be passing the native c_args/c_link_args to
g-ir-scanner.
|
|
When cross-compiling the gtk-doc calls were missing the configured c_args and
c_link_args.
|
|
Instead of showing just the command invoked, it's useful when debugging to also
show all of the arguments.
|
|
|
|
|
