Can't just #include them and use them directly in unity builds. Inline
assembly is a thing, but it's not trivial and is deprecated with some
compilers. Just build them separately and link them in. Ideally the user
would then use LTO to ensure the same result.
Also C++ compilers can build .S assembly files. This wasn't noticed
earlier because most people were also using C compilers in their C++
projects and we would fall back to using the C compiler for building the
assembly files. Now we have a test for this.
This was trivial to add; except that we needed a new LLVM IR rule
because the compiler emits warnings if you pass any special arguments to
it such as include arguments or dependency arguments.
Closes#1089
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
The method takes a dictionary with defines names as keys and the defines
values as values. From it, we assemble the gcc version, using 0 as a
default value if the define we want is not defined.
Seems better to do this since the behaviour is compiler-specific. Would
be easier to extend this later too in case we want to do more
compiler-specific things.
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. We only
need to resolve relative paths as the current working directory may
get changed before re-launching the script, and using `realpath()` for
that saves us the trouble of manually resolving links and getting caught
in endless loops.
This also mean that `meson_script_file` no longer necessarily point to a
absolute file, so rename it to `_launcher` which hopefully would be less
prone to inducing false assumptions.
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.
After c01b183e5, the mtime of coredata.dat is always newer than all the
other build files, which made regen_checker think that they always had
to be regenerated. Now we set the mtime of the file to a value before
the build files are generated and that makes everything behave as it did
earlier.
The Meson script is not always in $scriptdir/../../ -- for instance if
installed with pip on Windows, the scriptdir is in:
C:/Python35/Lib/site-packages/meson-0.33.0.dev1-py3.5.egg/mesonbuild/scripts
and the meson.py script is in:
C:/Python35/Scripts
So, let's save the path available as Environment().meson_script_file
into the coredata.dat private file and use that to invoke Meson when
doing regen.
Also, let's fetch the backend that was used from the coredata too
instead of hard-coding vs2010.
Both these were causing a hard failure while doing regen with msbuild or
visual studio.
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.
Jussi Pakkanen
Nirbheek Chauhan
Paulo Antonio Alvarez
Emanuele Aina
Elliott Sales de Andrade
Matthias Klumpp
Nirbheek Chauhan
Noam Meltzer
Minijackson
Nicolas Schneider
Hemmo Nieminen