Added method concatenate_string_literals to CCompiler. Will concatenate
string literals.
Added keyword argument 'concatenate_string_literals' to Compiler.get_define.
If used will apply concatenate_string_literals to its return value.
Because vala is not listed in clike_langs, is_source(fname) is returning False
for Vala source files. Therefore, extract_all_objects() is completely empty
for Vala programs.
Fixes#791
Input files can be in any file encoding, not just utf-8 or isolatin1. Meson
should not make assumptions here and allow for the user to specify the
encoding to use.
On Windows, if we are going to link with a shared module, we need the
implib.
Use case: The Xorg server builds some X protocol extensions as modules. The
implibs for these modules need to be shipped as part of the SDK, to enable
building of 3rd party extensions which reference symbols in (and hence on
Windows, need to be linked with) these modules.
Refine #3277
According to what I read on the internet, on OSX, both MH_BUNDLE (module)
and MH_DYLIB (shared library) can be dynamically loaded using dlopen(), but
it is not possible to link against MH_BUNDLE as if they were shared
libraries.
Metion this as an issue in the documentation.
Emitting a warning, and then going on to fail during the build with
mysterious errors in symbolextractor isn't very helpful, so make attempting
this an error on OSX.
Add a test for that.
See also:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htmhttps://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
This simplifies a lot of code, and centralize "key=value" parsing in a
single place.
Unknown command line options becomes an hard error instead of
merely printing warning message. It has been warning it would become an
hard error for a while now. This has exceptions though, any
unknown option starting with "<lang>_" or "b_" are ignored because they
depend on which languages gets added and which compiler gets selected.
Also any option for unknown subproject are ignored because they depend
on which subproject actually gets built.
Also write more command line parsing tests. "19 bad command line
options" is removed because bad cmd line option became hard error and
it's covered with new tests in "30 command line".
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
This is a simple test case, checking for installed_files.txt, which just
makes sure the syntax is accepted.
Manual tests confirmed the permissions were set correctly.
A follow up commit adds a unit test based on this directory.
Expose depend_files: from the custom_target this creates.
This is the change suggested in #2815, with tests and documentation added.
Fixes#2789 (duplicate #2830)
This checks not only for existence, but also for usability of the
header, which means it does a full compilation and not just
pre-processing or __has_include.
Fixes https://github.com/mesonbuild/meson/issues/2246
That syntax is invalid, since decimal numbers should never have a
leading zero and octal numbers use the `0o` prefix instead.
This matches Python 3 syntax which does not accept it:
$ python3
>>> 0123
File "<stdin>", line 1
0123
^
SyntaxError: invalid token
>>>
Add a "failing" test case to confirm this property is preserved and no
regressions are introduced in this area.
Simplify support for alternate bases using int(..., base=0) which
auto-detects it using the standard Python syntax for numbers.
Octal numbers are useful to specify permission bits and umasks.
Binary numbers are not super useful... But considering we get them for
free, let's allow them here too.
v2: Tweak the regex so it doesn't accept a decimal number with a leading
zero, which is invalid for int(..., base=0) and would raise a ValueError
if passed around.
This will copy the file to the build directory without trying to read
it or substitute values into it.
Also do this optimization if the configuration_data() object passed to
the `configuration:` kwarg is empty, and print a warning about it.
See also: https://github.com/mesonbuild/meson/issues/1542
* mesonbuild/compilers/c.py: Make the `find_library` method more generic by allowing the user to supply the `code` for compiling and linking.
* mesonbuild/compilers/fortran.py: Use the methods inherited from `Compiler` base class where appropriate. Also reuse `CComiler` methods where applicable. This should be sufficient to get various compiler/linker arguments as well as to compile and link Fortran programs. This was tested with `gfortran` compiler, and while the other compilers ought to work for simple cases, their methods are primarily inherited from the base `FortranCompiler` class.
* test cases/fortran/10 find library/gzip.f90: Fortran module with some basic Fortran wrapper interfaces to `gzopen`, `gzwrite`, and `gzclose` C `zlib` functions.
* test cases/fortran/10 find library/main.f90: Fortran program using the `gzip` Fortran interface module to write some data to a gzip file.
* test cases/fortran/10 find library/meson.build: Meson build file for this test case. This demonstrates the ability to link the Fortran program against an external library.
For now dicts are immutable, and do not expose any methods,
they however support "native" syntax such as [] lookup,
and foreach iterating, and can be printed.
To allow the javac -implicit:class behaviour to know where to find
generated .java files then the build directory for the target is also
added to the -sourcefile path.
Although only one file is passed to javac at a time, if your code has
any inter-file dependencies javac still needs to know how to find other
source files for its -implicit:class feature to work whereby it will
automatically also compile files that the given file depends on.
-implicit:class is the default, practical, behaviour of javac since
otherwise it would be necessary to declare the class dependencies
for parallel java builds to be feasible.
Passing "include_directory: include_directory('.')" to jar() causes
-souredir <path/to/top/of/java/src> to be passed to javac which then
enables your source code to have inter-file class dependencies -
assuming none of your source code is generated.
This ensures that '.' is included by default.
The -sourcepath option can't be passed multiple times to javac, since it
simply overrides prior arguments. Instead -sourcepath takes a colon (or
semi-colon on windows) separated list of paths.
It seems that some projects relied on the previously buggy
behaviour of accepting a 2-element list as the single argument
to configuration_data.set().
Special-case this behaviour, and emit a deprecation message.
We were setting it to a file list that would always be wrong, and
always out of date since it would never exist.
However, the output list is not predictable. It usually has a 1-1
relationship with the input XML files, but it may not.
This must be fixed later with API for users to provide the output
names.
See: https://github.com/mesonbuild/meson/pull/3539
If we pass a source files() object, we will look for it in the build
directory, which is wrong. If we pass a build files() object (from
configure_file()), we will find it in the build directory, and then
try to copy it on top of itself in gtkdochelper.py getting a
SameFileError.
Add a test for it, and also properly iterate custom target outputs
when adding to content files.
The new --body and --header args are broken because they do not allow
the use of --output-directory to set the correct `#include "foo.h"`
line in `foo.c`. The changes in the gdbus test case show this.
Disabled till this can be fixed in glib.
Closes https://github.com/mesonbuild/meson/issues/3488
Christoph Behle
Paolo Bonzini
Sander Sweers
Jon Turney
Xavier Claessens
Jussi Pakkanen
Aleksey Filippov
Mathieu Duponchelle
Filipe Brandenburger
Mathieu Duponchelle
Nirbheek Chauhan
Niklas Claesson
Andrei Alexeyev
Matthew Krupcale
Niclas Moeslund Overby
Robert Bragg