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.
When the BuildTarget (executable, shared-library, static-library, etc)
is created, process the source list and assign compilers to this target.
This allows us to do compiler-specific file-naming without resorting to
ugly hacks.
This is one step towards consolidating all the 'what language does this
target use' checks and the 'this target should only have $lang files as
sources' checks we have all over the codebase. All those checks should
be done only when the target is created.
Fixes https://github.com/mesonbuild/meson/issues/526
Also removes useless and incorrect mesonlib.is_32bit() function. We
cannot trust that the architecture that Python is built for is the same
as the one we're targetting.
Allowing the object tree to be generated.
We need to add options to allow copying the ncesseary sources and
assets so the HTML generator can work with them (everything is
relative so we need to copy them in the build directory).
Until now the documentation was not generated from the user provided
main sgml file but it was using a generated one, which lead to a broken
documentation. Starting using it revealed the other bugs fixed in that
commit.
Because we were iterating over all generated sources of a target in one
go, we weren't adding the correct header_deps for generated source
compiles. We need to aggregate the header_deps first before generating
source compile targets for generated source files.
It is extremely common to need to know within a given dependency if
a given header, symbol, member, function, etc exists that cannot be
determined from the version number alone.
Without passing dependency objects to the various compiler/linker
checks and with many libraries headers/libraries being located in
their own subdirs of the standard prefix, the check for the library
would not find the header/function/symbol/etc.
This commit allows passing dependency objects to the compiler checks so
that the test program can be compiled/linked/run with the necessary
compilation and/or linking flags for that library.
It's a terrible user experience to force people building 32-bit
applications on 64-bit Windows to use a cross-info file when every other
tool treats it as a 'native' compilation -- it satisfies all the
requirements for a native compile.
This commit also fixes the platform detection on Windows which would
cause the 'native cpu' to be detected as 32-bit if you installed 32-bit
Python on 64-bit Windows, or if you were building with a 32-bit
toolchain on 64-bit Windows.
Doesn't support MinGW yet -- the next commits will add that since the
changes required for that are more involved.
Instead of spreading it across the entire file and re-implementing
can_compile for each compiler, consolidate it in one dictionary which
the base compiler class can refer to based on self.language set by the
child class.
This has fixed a number of hidden and unreported bugs due to bitrotten
can_compiler implementations.
In autotools POTFILES is generated at configure time from POTFILES.in,
but Meson only looks for a po/POTFILES in the source directory, which
is awkward when trying to maintain both build systems in parallel.
Instead just use POTFILES.in as fallback if it exists but POTFILES
does not. Also print an error if neither exists.
Fixes#818
Add support for passing a description to configuration data
setter methods via a 'description' kwarg. The description
string will be used when meson generates the entire configure
file without a template, autoconf-style.
Elliott Sales de Andrade
Jussi Pakkanen
Franz Zapata
Nirbheek Chauhan
Thibault Saunier
Matthew Waters
Tim-Philipp Müller
Nirbheek Chauhan
TingPing
Tim-Philipp Müller
Sam Thursfield
Thibault Saunier