Custom objects returned by modules must be subclass of ModuleObject and
have the state argument in its methods.
Add MutableModuleObject base class for objects that needs to be deep
copied on assignation.
The only advantage they have is they have the interpreter in arguments,
but it's already available as self.interpreter. We should discourage
usage of the interpreter API and rely on ModuleState object instead in
the future.
This also lift the restriction that a module method cannot add build
targets, but that was not enforced for snippet methods anyway (and some
modules were doing it) and it's really loose restriction as it should
check for many other things if we wanted to make it consistent.
We need to pass any generated sources down the CustomTarget
inititalizers so that they will generate a dependency correctly,
otherwise we get race conditions.
...Update 2, to be exact, since the Visual Studio linker only gained the
`/WHOLEARCHIVE:` feature since Visual Studio 2015 Update 2.
This checks whether we have the corresponding `cl.exe` which is
versioned at or after Visual Studio 2015 Update 2 before we try to apply
the `/WHOLEARCHIVE:xxx` linker flag. If we aren't, use built-in methods
in Meson to grab the object files of the dependent static lib's, along
with the objects that were `link_whole:`'ed into them, and feed this
list into the linker instead.
This would make `link_whole:` work on Visual Studio 2015 Update 1 and
earlier, including previous Visual Studio versions.
This partially reverts commit add502c648.
In 'linkshared' test, annotate cppfunc() as imported, so an indirection
through an import stub is generated, avoiding a relocation size error
when building using gcc for Cygwin with LTO on.
Align with the example of how to write this portably in [1].
The 'c' language part of that test already gets this right.
[1] http://gcc.gnu.org/wiki/Visibility
This is so dumb, we can just insert C for you without you having to know
that you're using C under the hood. This is nicer because:
1) Meson doesn't make the user add a language they're not explicitly
using
2) If there was ever an implementaiton of Vala that didn't use C as
it's assembly language, this wouldn't make any sense.
The build level shouldn't be deal with interpreter objects, by the time
they leave the intpreter they should be in the Meson middle layer
representaiton