Cache the absolute dir that the script is searched in and the name of
the script. These are the only two things that change.
Update the test to test for both #1235 and the case when a script of the
same name is in a different directory (which also covers the subproject
case).
Closes#1235
./mesonbuild/scripts/regen_checker.py:35:5: F841 local variable 'scriptdir' is assigned to but never used
scriptdir = os.path.split(__file__)[0]
^
./mesonbuild/scripts/yelphelper.py:84:13: F841 local variable 'symfile' is assigned to but never used
symfile = os.path.join(install_dir, m)
^
./mesonbuild/backend/backends.py:164:13: F841 local variable 'lang' is assigned to but never used
lang = comp.get_language()
^
./mesonbuild/backend/ninjabackend.py:1286:9: F841 local variable 'scriptdir' is assigned to but never used
scriptdir = self.environment.get_script_dir()
^
./mesonbuild/backend/vs2010backend.py:736:9: F841 local variable 'additional_options_set' is assigned to but never used
additional_options_set = True
^
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
The script will manually delete all custom_target outputs that are
directories instead of files. This is needed because on platforms other
than Windows, Ninja only deletes directories while cleaning if they are
empty.
Closes#1220
Without this, the user has to both compile the resource with
gnome.compile_resources, pass that to the target sources, and also
pass --gresources=/path/to/gres.xml to vala_args in the target.
With this, we will do that automatically.
This greatly improves the logic for determining the linker. Previously,
we would completely break if a target contained only extracted objects
and we were using more than one compiler in our project.
This also fixes determination of the linker if our target only contains
generated objc++ sources, and other funky combinations.
This avoids us having no compilers at all for targets that are composed
entirely of objects with no sources.
Now we will always have a compiler for a target even if it is composed
entirely of objects generated with custom targets unless it has
completely unknown sources.
Instead of using a whitelist, use a blacklist. Also print a more useful
error if the regex fails to match.
Use an underscore in the gir test to trigger this.
Fixes#436
Make so both executable() targets that are marked as native and
external programs (which are usually build tools compiled for the
host machine) are not supposed to be run with the exe wrapper.
Not only does extract_all_objects() now work properly again,
extract_objects() also works if you specify a subset of sources all of
which have been compiled into a single unified object.
So, for instance, this allows you to extract all the objects
corresponding to the C sources compiled into a target consisting of
C and C++ sources.
Pre-calculate the output directory for GeneratedList and CustomTarget so
we can directly use the same code for both while compiling C/C++ files
and headers.
There is no reason to have separate branches for GeneratedList and
CustomTarget since both can be used in almost exactly the same way for
generating sources.
This is going to used next for adding generated sources support to Vala.
get_filename() made no sense for CustomTarget since it can have multiple
outputs. Also use get_outputs() for GeneratedList since it has the same
meaning and remove unused set_generated().
As a side-effect, we now install all the outputs of a CustomTarget.
This is done by adding a new compiler method called 'no_warn_args' which
returns the argument(s) required for the compiler to emit no warnings
for that compilation.
This take care of not disabling warnings for C code compiled into the
BuildTarget. Also includes tests for ensuring all this.
https://github.com/mesonbuild/meson/issues/864
With C/C++, on Windows you don't need to pass any arguments for a static
library to be PIC. On UNIX platforms you need to pass -fPIC.
Other languages such as D have compiler-specific PIC arguments required
for PIC support in static libraries on UNIX platforms.
This kwarg allows people to specify which static libraries should be
built with PIC support. This is usually used for static libraries that
will be linked into shared libraries.
self.dep_rules is not set anywhere by anything, so this code always
results in a no-op. If it didn't result in a no-op, it would need to be
seriously rewritten because it has bitrotten and makes no sense anymore.
This is definitely more correct since it takes into account the
cross-compilation status. We also now do the Java and CSharp sanity
checks on the BuildTarget level instead of in the Ninja backend.
For commands that always output to stdout and don't have a "-o" or
"--output" or some other similar option, this 'capture' setting allows
the build to capture the result and place it in the output file.
This allows us to output either the relative or absolute path as
requested. Fixes usage of configure_file inside CustomTarget commands
with the VS backends.
This commit contains several changes to the naming and versioning of
shared and static libraries. The details are documented at:
https://github.com/mesonbuild/meson/pull/417
Here's a brief summary:
* The results of binary and compiler detection via environment functions
are now cached so that they can be called repeatedly without
performance penalty. This is necessary because every
build.SharedLibrary object has to know whether the compiler is MSVC or
not (output filenames depend on that), and so the compiler detection
has to be called for each object instantiation.
* Linux shared libraries don't always have a library version. Sometimes
only soversions are specified (and vice-versa), so support both.
* Don't use versioned filenames when generating DLLs, DLLs are never
versioned using the suffix in the way that .so libraries are. Hence,
they don't use "aliases". Only Linux shared libraries use those.
* OS X dylibs do not use filename aliases at all. They only use the
soversion in the dylib name (libfoo.X.dylib), and that's it. If
there's no soversion specified, the dylib is called libfoo.dylib.
Further versioning in dylibs is supposed to be done with the
-current_version argument to clang, but this is TBD.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23
* Install DLLs into bindir and import libraries into libdir
* Static libraries are now always called libfoo.a, even with MSVC
* .lib import libraries are always generated when building with MSVC
* .dll.a import libraries are always generated when building with
MinGW/GCC or MinGW/clang
* TODO: Use dlltool if available to generate .dll.a when .lib is
generated and vice-versa.
* Library and executable suffix/prefixes are now always correctly
overriden by the values of the 'name_prefix' and 'name_suffix' keyword
arguments.
Instead, return the values of the test and benchmark setup data files so
that the ninja/osx/vs backends can use those filenames instead of
hard-coding them.
When a CustomTarget is run with a command that is an executable built
by the project which also has a DLL built in the same project as a
dependency, the EXE can't run on Windows because the DLL can't be found.
On UNIX-like systems, we set the RPATH using the linker so these
dependencies can be found, but on Windows the only way is to set the
PATH environment variable.
The same problem exists for tests, so we reuse that infrastructure by
creating a new meson_exe.py script that can be used as a wrapper to run
CustomTarget commands on Windows. This can later also be extended to add
support for setting an environment while calling the command needed to
generate a CustomTarget: https://github.com/mesonbuild/meson/issues/266
1. Dependencies must be set up with the target's id instead of its
basename.
2. Extracted object output file names must not include the directory
prefix, because MSBuild puts all object files into the same directory
and names them srcfilename.obj instead of dir/filename.obj or
dir_filename.obj.
Noticed when trying to pass custom optimization flags, and hence setting
buildtype to plain, that warnings for different levels were not passed to
compiler.
This was a bit confusing since mesonconf still displayed "warning_level=3"
and -Werror was passed correctly due to "werror=true". So this change
aligns warning_level behavior with werror. That is, heed what is in
project() in meson.build but user can still override if necessary.
This is very useful to prevent compiler noise about invalid cflags; particularly
for the -mms-bitfields cflag which most libraries send to the mingw-gcc
compiler. More can be added later.
Jussi Pakkanen