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.
c++1y is deprecated in GCC 5 (see -std option in man page). Not sure about
Clang since the documentation is a bit more sparse. But it is probably a
good idea to keep them in sync and also to prefer c++14 over c++1y since
c++1y was only temporary until the standard was done.
Jussi Pakkanen
Nirbheek Chauhan
Martin Ejdestig
Thibault Saunier
Marko Raatikainen