After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747917 - common: simplify build of static recipes
common: simplify build of static recipes
Status: RESOLVED DUPLICATE of bug 779344
Product: GStreamer
Classification: Platform
Component: common
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-15 13:49 UTC by Andoni Morales
Modified: 2017-03-12 16:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-configure-support-changing-the-plugins-install-direc.patch (2.23 KB, patch)
2015-04-15 13:49 UTC, Andoni Morales
none Details | Review
0001-gstreamer-static-simplify-static-recipes-build.patch (3.84 KB, patch)
2015-04-15 14:46 UTC, Andoni Morales
none Details | Review
common: generate static/shared plugins (4.24 KB, patch)
2015-08-03 10:29 UTC, Matthew Waters (ystreet00)
none Details | Review

Description Andoni Morales 2015-04-15 13:49:31 UTC
Created attachment 301634 [details] [review]
0001-configure-support-changing-the-plugins-install-direc.patch

First step to simplify build of static plugins in cerbero.

This patch adds support for changing the default installation directory for GStreamer plugins through a new configure option:
--with-gstpluginsdir=/usr/local/lib/gstreamer-1.0/static
Comment 1 Andoni Morales 2015-04-15 14:46:54 UTC
Created attachment 301645 [details] [review]
0001-gstreamer-static-simplify-static-recipes-build.patch

This second patch is for the cerbero part and it's untested
Comment 2 Matthew Waters (ystreet00) 2015-07-31 05:19:13 UTC
I like this.  It means we don't have to perform the make DESTDIR=blah install dance oneself when manually building -static recipes for android (and presumably iOS).

Is it possible to make the default change to gstreamer-API_VERSION/static automatically when --enable-static-plugins is passed?
Comment 3 Nicolas Dufresne (ndufresne) 2015-07-31 12:32:43 UTC
Can't we just integrate static build entirely within GStreamer build system instead ?
Comment 4 Matthew Waters (ystreet00) 2015-08-03 10:29:25 UTC
Created attachment 308659 [details] [review]
common: generate static/shared plugins

That's seems to be a hard problem with autotools without reinventing a lot of things.

Need to build some part of the plugins twice with/without -DGST_PLUGIN_BUILD_STATIC (specifically the GST_PLUGIN_DEFINE declaration) in order to create the necessary gst_plugin_{name}_register (static) and gst_plugin_desc (shared) definitions so that the plugins can be loaded and registered properly in both environments.

Attempted Solution:
libtool conveniencs libraries for plugins that are linked to the two separate shared and static libraries.

automake doesn't do shell substitution in variable definitions. Only autoconf provided substitution is provided through @VAR@ which is not finegrained enough or involves running a configure in each. plugin. directory. which if gettext's build system is anything to go by, is dog slow.  More so on windows.

Attempted Solution:
Generate some Makefile.am that can be included by plugin Makefile.am's to generate the necessary static and shared libraries.

automake runs before configure is run so we need to generate these Makefile's before automake in order to perform the include.  Currently done in gst-autogen.sh.

Then we need some way of signalling the plugin library so the generated Makefile.am can build the correct libraries.  Currently uses a plugin_name file in each plugin directory.
Comment 5 Sebastian Dröge (slomo) 2015-08-07 14:08:38 UTC
Comment on attachment 308659 [details] [review]
common: generate static/shared plugins

It should be possible to create a m4 macro or include Makefile for these static_lib / shared_lib parts of the Makefile.am. Things like gtk-doc and gconf have automake m4 macros IIRC that do complicated things, which might be used here. For include Makefiles, the ones from common/glib-mkenums.mk might be a good starting point, or the GI ones.

So that in the end in your Makefile.am you only have to provide the plugin name, CFLAGS, CXXFLAGS, LIBS, etc and the source files, and then the autogeneration stuff does everything needed.


That would of course require to change all the plugin Makefile.am, but I don't think we'll get around that.


It shouldn't be required to do anything in autogen.sh
Comment 6 Matthew Waters (ystreet00) 2015-08-07 14:24:56 UTC
(In reply to Sebastian Dröge (slomo) from comment #5)
> It should be possible to create a m4 macro or include Makefile for these
> static_lib / shared_lib parts of the Makefile.am. Things like gtk-doc and
> gconf have automake m4 macros IIRC that do complicated things, which might
> be used here. For include Makefiles, the ones from common/glib-mkenums.mk
> might be a good starting point, or the GI ones.

That's exactly what this attempts to do however the only substitution available in automake is at configure time via @VAR@ as mentioned above.

> So that in the end in your Makefile.am you only have to provide the plugin
> name, CFLAGS, CXXFLAGS, LIBS, etc and the source files, and then the
> autogeneration stuff does everything needed.

Precisely what's attempted.

> That would of course require to change all the plugin Makefile.am, but I
> don't think we'll get around that.
> 
> It shouldn't be required to do anything in autogen.sh

Unfortunately I don't think that is possible.  To reiterate:
1. To generate the automake snippets for the shared/static libraries, we need to substitute some library name.
2. automake only substitutes at configure time (Makefile.in -> Makefile)
3. automake include files must exist.  No includes to nonexistent files.
4. Only possible to include other Makefile.am like files.
5. Need automake to link the libtool  convenience libraries and to avoid writing custom compilation rules.
Comment 7 Nicolas Dufresne (ndufresne) 2017-03-12 16:03:56 UTC
I've implemented a solution that isn't build system specific in bug 779344. Considering we have Meson to maintain too, I think we can keep moving without this bug.

*** This bug has been marked as a duplicate of bug 779344 ***