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.
It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
Original commit message from CVS:
* gst-libs/gst/audio/.cvsignore:
Ignore generated file.
* gst-libs/gst/audio/Makefile.am:
Do not install example filter.
Original commit message from CVS:
* gst-libs/gst/audio/Makefile.am:
Add gstaudiofiltertemplate.c and building of gstaudiofilterexample.c
from the template.
* gst-libs/gst/audio/gstaudiofilter.c:
* gst-libs/gst/audio/gstaudiofilter.h:
Add bytes_per_sample and size and n_samples calculation.
* gst-libs/gst/audio/gstaudiofilterexample.c:
Remove, now autogenerated.
* gst-libs/gst/audio/gstaudiofiltertemplate.c:
Moved from gstaudiofilterexample, object name changed, code added
so that it actually works.
* gst-libs/gst/audio/make_filter:
Script to build an audiofilter subclass from the template.
* gst/colorspace/Makefile.am:
* gst/colorspace/yuv2yuv.c:
Remove file, since it's GPL, and we don't use it.
Original commit message from CVS:
* actually recurse into sndfile if we are able
* big ladspa cleanups, mainly to comply with the buffer-frames caps property, but also general
cleanups
- the samplerate prop is gone, if you want to set it explicitly (as in for get-based plugins)
you need to use a filtered connection, just like with buffer-frames
* big float2int and int2float changes for buffer-frames compatibility - I think it's quite a bit
simpler
* make the ossclock general, add it to gstaudio, and use it in sndfile as well
i need to update mimetypes, but that's coming soon. there are some other plugins that don't
support buffer-frames, i guess i need to get around to fixing them as well.
Original commit message from CVS:
Updated autogen.sh/configure.ac and various Makefiles to make the
configure script set up all gcc specific compiler arguments, rather
than hardcoding them in the Makefile.am files
Original commit message from CVS:
* removal of //-style comments
* don't link plugins to core libs -- the versioning is done internally to the plugins with the plugin_info struct,
and symbol resolution is lazy, so we can always know if a plugin can be loaded by the plugin_info data. in theory.
Original commit message from CVS:
s/@GST_PLUGIN_LDFLAGS@/$(GST_PLUGIN_LDFLAGS)/
@-substitued variables variables are defined as make variables automagically,
and this gives the user the freedom to say make GST_PLUGIN_LDFLAGS=-myflag
Original commit message from CVS:
moving and renaming
we put the libs in the source in gst-libs/gst/(dir)
the headers get installed in prefix/include/gst/(dir)
the libs are installed in prefix/lib/gst
with a libgst prefix
the sources should be without the gst prefix
as per irc agreement
please comment if this sounds like a bad idea ;)
