For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
The g-i stuff for this helper lib was never usable from bindings
anyway and there are problems with the latest gobject-introspection,
so we might just as well remove the g-i integration entirely for
this lib.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
_stdint.h is generated by Autotools and we don't really need it.
stdint.h is now available on all supported platforms.
This really only makes a difference for MSVC, which has it starting from
Visual Studio 2015.
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
This reverts commit e39fbe6b7e.
Looks like we need to pass the full .la file after all in a setup
with libtool, or it might not find the library, e.g. like
ERROR: can't resolve libraries to shared libraries: gstfft-1.0
Conflicts:
gst-libs/gst/audio/Makefile.am
gst-libs/gst/pbutils/Makefile.am
Also see https://bugzilla.gnome.org/show_bug.cgi?id=603710
libgstfft doesn't actually use any symbols from libgstreamer, so when
compiling with -Wl,--as-needed it won't even link to it, which can
cause failures with older versions of g-i that ignore the --pkg
arguments.
Should fix PPA build failure on Ubuntu Maverick
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the
needed Android.mk files.
Androgenizer can be found here:
http://git.collabora.co.uk/?p=user/derek/androgenizer.git
Make sure to use the PKG_CONFIG_PATH set at configure time instead of
just relying on an env-var set one. This makes sure both g-ir-compiler
and g-ir-scanner use the same PKG_CONFIG_PATH for determining include
paths etc.
When calling gobject-introspection scanner, make sure our own
freshly-built libs within the source tree (well, build dir) come
first in the PKG_CONFIG_PATH. May or may not help to make sure
that it doesn't pick up older external plugins-base libs (or
.gir files) from outside the source tree / build directory as
dependencies of the introspected lib instead of using the
stuff we just built in a sibling directory.
https://bugzilla.gnome.org/show_bug.cgi?id=623698
Point g-ir-scanner to the .la file of our library, which hopefully
makes it find the right dependencies in all cases (ie. our locally
built libgstreamer and not the system-installed one). This is also
how it's done in Gtk+ and how it's documented in the wiki, see
http://live.gnome.org/GObjectIntrospection/AutotoolsIntegrationFixes#603710.
