Otherwise they are built regardless of whether they are actually used by
anything else. Only build them if they're going to be installed or
always-built.
Ideally, we should also do this with all BuildTargets, and provide
a mechanism for people to specify which targets they want built with
'all', and a way for people to add them to custom targets.. Without
this, things like tests and examples are *always* built with no way to
turn that off.
For now, we just do this because it also with tests that check for
dependency issues. Including all CustomTargets in `all` results in
dangling targets to also be built, which hides the problem and makes it
racy.
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.
When installing Meson distutils may choose to put shim scripts in the
PATH that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that __file__ points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using argv[0] avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable.
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
Jussi Pakkanen
Nirbheek Chauhan
Sam Thursfield
Emanuele Aina
Elliott Sales de Andrade
Franz Zapata
Thibault Saunier
Matthew Waters
Tim-Philipp Müller
Nirbheek Chauhan