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.
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.
/FS forces .pdb file writing to be serialized through MSPDBSRV.EXE,
which is supposed to solve concurrency issues (esp. with anti-viruses),
but it doesn't actually always work. It also isn't needed anymore since
we don't use a shared vcXXX.pdb temporary file for pdb writing and use
/Fd to explicitly set a per-target pdb filename instead.
Not serializing the PDB writing will make a large difference on fast
disks when linking multiple libraries and executables simultaneously.
* Add a new compiler object method: has_members
Identical to 'cc.has_member', except that this takes multiple members
and all of them must exist else it returns false.
This is useful when you want to verify that a structure has all of
a given set of fields. Individually checking each member is horrifying.
* Fix typo in exceptions for has_member(s)
D allows programmers to define their tests alongside the actual code in
a unittest scope[1].
When compiled with a special flag, the compiler will build a binary
containing the tests instead of the actual application.
This is a strightforward and easy way to run tests and works well with
Mesons test() command.
Since using just one flag name to enable unittest mode would be too
boring, compiler developers invented multiple ones.
Adding this helper method makes it easy for people writing Meson build
descriptions for D projects to enable unittestmode.
[1]: https://dlang.org/spec/unittest.html
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.
This causes intermittent build failures in the MSVC CI because of a race
with the default anti-virus that ships with Windows while writing the
.pdb file: https://ci.appveyor.com/project/jpakkane/meson/build/1.0.58
There's a separate fix for that in the works that will fix this in the
general case, but for compiler tests we don't need to generate the pdb
file at all. So, just fetch the CRT flag (/MDd) if needed instead.
This has the side-effect of making compiler tests that use self.links
and self.run faster.
This allows the user to specify custom arguments to the compiler to be used
while performing cross-compiler checks. For example, passing a GCC specs file as
c_link_args so that a "prefix" filled with libraries that are to be compiled
against can be found with cc.find_library, or an `-mcpu` c_arg that is required
for compilation.
Also ensure that unix_link_flags_to_native() and unix_compile_flags_to_native()
always return a copy of the original arguments and not a reference to the
original arguments. We never want to modify the original arguments.
This is required for checking for compiler checks that involve linking
to a static library with MSVC. Without this, MSVC errors out since no
CRT is specified.
limits.h is a requirement of the C language and is available with all compilers
and platforms from the last two decades. If limits.h is not available, the
compiler only supports an ancient dialect of C and lots of other things will
break too.
Consolidate the C/C++ compiler sanity checks since the test code is almost
exactly the same, and then use that for the MSVC C/C++ compilers as well. All
these sanity checks had diverged because of the code duplication.
This also fixes an intermittent sanity check failure that I was seeing with
MSVC.
Note: The ObjC/C++ compilers can also probably use the same implementation.
With the change to cc.links to translate unix link flags, this is no
longer needed and is wrong because it hasn't kept-up with the improved
default cc.find_library implementation.
Without any -O options, gcc does not generate properly debuggable code.
> With no -O option at all, some compiler passes that collect information useful
> for debugging do not run at all
gcc recommends -Og, but that isn't supported by clang, so we use -O0
See https://github.com/mesonbuild/meson/pull/509 for more discussion
We now use .links() to detect if a C compiler function is available
or not, that way the user doesn't need to specify all the possible
includes for the check, which simplifies things considerably.
Also detect glibc stub functions that will never work and return
false for them.
Closes#437
On MSVC, shared libraries only export symbols that have been explicitly exported
either as part of the symbol prototype or via a module definitions file.
On compilers other than MSVC, all symbols are exported in the shared library by
default and the format for the list of symbols to export is different, so this
is only used with the VisualStudio compiler.
The module defs file path can either be relative to the current source directory
or an absolute path using meson.source_root() + '/some/path'
MSVC requires import libraries called foo.lib for linking to foo.dll, so
translate -lfoo to that. If foo.lib doesn't exist, linking will fail as
expected.
-Weverything is not a good match for behavior of other compilers at warning
level 3. Align flags with what Meson passes to GCC instead.
The warnings generated are often conflicting with what the user most
probably wants. E.g.:
* -Wc++98-compat does not make sense when building code that uses -std= to
set a later standard.
* -Wpadding warns when compiler pads classes and structs for better
performance, probably something the user wants.
These warnings, and maybe a couple of others, can of course be disabled by
Meson with -Wno-* but it is not future proof (other warnings that makes
sense to disable by default may be added which means Meson will probably
have to pass different flags depending on the Clang version).
It is also problematic to compile many system and library headers with
-Weverything. For instance:
* stdio.h and sigaction.h on Linux makes use of recursive macros
(-Wdisabled-macro-expansion).
* Many library headers make use of deprecated functionality (-Wdeprecated).
* Many library (e.g. GTK+ and Qt) headers trigger Clang's Doxygen warnings
(-Wdocumentation-unknown-command and -Wdocumentation).
There are a couple of more warnings that need to be disabled when building
files that use GTK+ and Qt. GTest is also problematic.
Maybe it would make sense to add a higher level, where -Weverything would
be passed to Clang, that aligns with the original intent of -Weverything.
See http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20121029/067071.html .
GCC does not have a similar flag though. I do not know about other
compilers (MSVC etc).
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.
On Windows, the advantages of PIC are provided by the runtime DLL loader. /LD is
also only valid as an argument to cl.exe, and the linker link.exe just barfs
when it sees it.
The code assumes that the compiler is the same as the linker which caused this
problem to occur.
Elliott Sales de Andrade