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 658556 - RFC: non recursive build for plugin dirs
RFC: non recursive build for plugin dirs
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: dont know
unspecified
Other Linux
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-08 13:23 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2016-06-02 06:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
use non recursive make in gst-plugins-ugly/gst (4.44 KB, patch)
2011-09-08 13:23 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
needs-work Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2011-09-08 13:23:10 UTC
I changed gst-plugin-ugly/gst to build non-recursively. Below are some figures (before and after). If we decide to go for it, we need to hack AG_GST_CHECK_PLUGIN to built a list of lib<pluginname>.la in addition

pro:
- faster (especially "make install")
- less makefiles to manage
- easier to apply flags globally
- we can kill parallel-subdirs.mak, make -jn works naturally

cons:
- per directory makefiles are getting bigger, but still less than the sum of subdirs

cd gst

xtime make clean all
15.43u 1.98s 13.26r 230512kB make clean all
17.58u 2.17s 13.35r 230880kB make clean all
17.61u 2.10s 13.80r 230912kB make clean all

15.71u 1.95s 12.49r 230928kB make clean all
16.22u 1.99s 13.14r 230752kB make clean all
15.15u 1.96s 12.17r 230784kB make clean all


xtime sudo make install
1.14u 0.17s 0.94r 16912kB sudo make install
1.08u 0.10s 0.87r 16912kB sudo make install
0.96u 0.30s 0.92r 16912kB sudo make install

0.25u 0.06s 0.21r 16928kB sudo make install
0.30u 0.02s 0.24r 16928kB sudo make install
0.25u 0.11s 0.23r 16928kB sudo make install


make clean; xtime make -j2 all
13.76u 1.47s 6.90r 230784kB make -j2 all
13.27u 1.69s 6.68r 230736kB make -j2 all

12.48u 1.49s 6.30r 230944kB make -j2 all
12.49u 1.43s 6.25r 230912kB make -j2 all


make clean; xtime make -r -j2 all CFLAGS=-O0
9.04u 1.64s 4.47r 144688kB make -r -j2 all CFLAGS=-O0
9.34u 1.32s 4.39r 144832kB make -r -j2 all CFLAGS=-O0

8.68u 1.30s 4.14r 144720kB make -r -j2 all CFLAGS=-O0
8.67u 1.53s 4.23r 144720kB make -r -j2 all CFLAGS=-O0
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2011-09-08 13:23:53 UTC
Created attachment 195983 [details] [review]
use non recursive make in gst-plugins-ugly/gst
Comment 2 David Schleef 2011-09-17 18:19:08 UTC
I agree that this would be great.  However, I don't think we should move the contents of gst/*/Makefile.am up a level -- that removes a lot of the nice compartmentalization we currently have.  Is it possible to use 'include'?
Comment 3 Edward Hervey 2013-07-18 06:07:44 UTC
Anyone motivated to work on this ? Is it possible to use include ?
Comment 4 Sebastian Dröge (slomo) 2013-07-18 09:17:15 UTC
Is it still that useful? We allow the subdirectories to build independently already, so -j5 would e.g. build 5 plugins under ext/ at once.
Comment 5 Sebastian Dröge (slomo) 2013-07-18 09:17:38 UTC
Also I don't like putting everything in gst/Makefile.am, if anything include should be used.
Comment 6 Sebastian Dröge (slomo) 2013-07-18 09:18:28 UTC
include will probably require some changes btw, noinst_HEADERS is currently defined by each of the Makefile.am for example.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2013-07-18 10:43:00 UTC
Yes we can and should use include. And indeed we need to init a few vars before including. I can try this for ugly again.
Comment 8 Sebastian Dröge (slomo) 2013-12-23 14:17:19 UTC
Any progress here?
Comment 9 Tim-Philipp Müller 2016-06-02 00:10:01 UTC
I think we should just WONTFIX this, it'll no longer be a problem once we move to or add support for a build system where this is no longer a concern :)
Comment 10 Stefan Sauer (gstreamer, gtkdoc dev) 2016-06-02 06:55:22 UTC
Tim, do we have such a plan? I still think non recursive make could be helpful in the short-term. But such a change is more suitable to be done it a hackfest, where it can be finalized.