GNOME Bugzilla – Bug 765852
Implement more detailed control of what is getting build
Last modified: 2016-10-31 16:00:00 UTC
Cerbero is awesome tool, but it's easy to notice that it contains certain hardcoded things. The most important issue for me is that it by default builds most of GStreamer plugins while I am building an 100% audio apps, so all video-related stuff is unnecessary. I am aware I can strip unnecessary files during packaging but that approach a) leads to duplicating information about what depends on what b) keeps build times high I've made initial test and amount of recipes to be built can be decreased almost by half if I need only the audio part. If you don't mind I would like to add more fine-grained control on what is getting built using variants, but I would prefer to agree on certain pattern before I start implementing this. Any ideas how it should be done properly? I would say that it should be as detailed as it is possible, so effectively each plugin-related feature switch passed to ./configure in gst-plugins-* should be configurable via variants.
Is your goal to avoid to build, or to avoid to package stuff ?
Both.
My worry, and I hope you'll share, is to make the build system too complex. I don't want to recreate Gentoo style system, were you never know if a certain setup will work or fail. It remains that I agree it would be nice to have a method to make the build slimmer (without having to visit every recipe, like I do and probably most of you do when needed). In the end, some stuff will be built without being included. I doubt it's not worth adding an massive amount of new configure option and ifdef for small amount of "un-needed" code. What I believe is best, is that for what that cannot be separated, we could at least have a clear separation in the recipes. E.g. we could have some recipes split between video-libs and audio-libs instead of just libs like we do now (and maybe create groups like libs that include both audio and video, so we don't break all existing packages). Variants are more for across the board things, like X11, and should be kept this way (e.g. some plugins may be build with or without some deps all across GST, variants are meant to let you select that). The split between video/audio/text/etc. is something that a package should be able to select, though sometimes it does not make sense to add ifdef and a configure flag to avoid what you won't be selecting. Please share you plan, this way we'll be in better position to help you draw the line.
I was going to say the same thing, I don't think we want to create (and support) a mini-gentoo. Maybe some more options make sense, or maybe we should just tell people to maintain their own customised cerbero fork since realistically no amount of general options will get to 100%, at best it will minimise the diff to maintain.
Hello. I didn't meant making mini gentoo at any point or modifying existing code to support more configure flags than GStreamer already supports. I would like to just map these existing flags and checks into Cerbero. Both mini gentoo and current approach are IMO slightly overkill. First is unpredictable, latter leads to building and shipping tons of unnecessary code. Maintaining fork is a pain every time when GStreamer gets updated and it means that enhancements that are made within the fork are rarely contributed back to the Cerbero master which is against open source philosophy. That's why I suggest improving Cerbero. If you think that using more variants is a good approach - fine. If you think that making smaller recipes is better - fine. Anything else - fine. That's why I wanted to start this discussion. If at the end you will decide that you don't want to modify Cerbero - well, I'll maintain my fork as I would have no other option :) Please let me know what you think about that.
I would maybe start with splitting gst-plugins-* into gst-plugins-*-audio, gst-plugins-*-video, gst-plugins-*-other, ok? That would not modify general Cerbero's structure but will be step towards more building only what's necessary.