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.
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
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
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.
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.
When passing more than one -Dc_args it should override the value
instead of appending. This is how all other options works.
Value should be split on spaces using shlex just like it does with
CFLAGS environment variable.
Fixes#3473.
To maintain backward compatibility we cannot add recursive objects by
default. Print a warning when there are recursive objects to be pulled
and the argument is not set. After a while we'll do pull recursive
objects by default.
And, with that, update the test cases that checked that preserving the
original permissions worked to set install_umask=preserve explicitly in
those projects' default_options.
Tested: ./run_tests.py
This adds a new method, partial_dependency to all dependencies. These
sub dependencies are copies of the original dependency, but with one or
more of the attributes replaced with an empty list. This allows creating
a sub dependency that has only cflags or drops link_arguments, for
example.
Otherwise we can't do the following workflow:
if not find_program('foo', required : false).found()
subproject('provides-foo')
endif
Where 'provides-foo' has a meson.override_find_program() on
a configure_file() or similar.
Previously pkg-config files generated by the pkgconfig modules for static libraries
with dependencies could only be used in a dependencies with `static: true`.
This was caused by the dependencies only appearing in Libs.private even
if they are needed in the default linking mode. But a user of a
dependency should not have to know if the default linking mode is static
or dynamic; A dependency('somelib') call should always pull in all
needed pieces into the build.
Now for meson build static libraries passed via `libraries` to the generate
method automatically promote dependencies to public.
The added format argument for configure_file allows to specify the kind of
file that is treated. It defaults to 'meson', but can also have the 'cmake'
or 'cmake@' value to treat config.h.in files in the cmake format with #cmakedefine
statements.
Copy the algorithm used by autoconf.
It computes the upper and lower limits by starting at [-1,1] and
multiply by 2 at each iteration. This is even faster for small numbers
(the common case), for example it finds value 0 in just 2 compilations
where old algorithm would check for 1024, 512, ..., 0.
This is due to incorrect creation of dependency files:
both compilers do not escape spaces in paths.
As of version 1.21.22 of lcc, it is announced that
this bug will be corrected in future versions.
Test 132 was a template for such idea; it has been also
extended to react not only to icc, but to lcc too.
Further info (if I'm correct):
https://software.intel.com/en-us/forums/intel-c-compiler/topic/283156