<br><br>On Thursday, 19 February 2015, Andoni Morales <<a href="mailto:ylatuya@gmail.com">ylatuya@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2015-02-18 20:21 GMT+01:00 Nirbheek Chauhan <<a href="javascript:;" onclick="_e(event, 'cvml', 'nirbheek.chauhan@gmail.com')">nirbheek.chauhan@gmail.com</a>>:<br>
> On Wed, Feb 18, 2015 at 5:23 PM, Sebastian Dröge<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'sebastian@centricular.com')">sebastian@centricular.com</a>> wrote:<br>
>> On Di, 2015-02-17 at 16:59 +0000, Luis de Bethencourt wrote:<br>
>>> GStreamer is going to apply for Google Summer of Code 2015. But we need<br>
>>> your help!<br>
>>><br>
>>> We would really appreciate if you suggested proposals, volunteered for<br>
>>> mentoring, or added content to the proposals.<br>
>>><br>
>>> Current list of proposals is here:<br>
>>> <a href="http://gstreamer.freedesktop.org/GSOC/socprojects.html" target="_blank">http://gstreamer.freedesktop.org/GSOC/socprojects.html</a><br>
>><br>
>> Does anybody have any other ideas, or would like to be added as a<br>
>> potential mentor for any of these projects? Would be great to get some<br>
>> more ideas and potential mentors so we can properly handle all<br>
>> projects :)<br>
>><br>
><br>
> It might be useful to have a project to improve Cerbero.<br>
><br>
> Cerbero's main use-case right now is to build binaries<br>
> tarballs/packages from upstream sources. It's quite difficult to use<br>
> it for other uses such as local development; which is a shame because<br>
> it's currently our best way of doing cross-compilation.<br>
><br>
> List of deficiencies (Incomplete):<br>
> ==================================<br>
> 1) Local development is hard; current best way is to push to a custom<br>
> remote/branch<br>
<br>
For local development using cerbero to rebuild changes in a project is<br>
not the best approach to use. What I usually do is jumping into the<br>
development shell and use a repository checkout different from the one<br>
created by cerbero (eg: ~/git/gst-plugins-bad), configured with the<br>
same configure options, specially for the prefix. Than the development<br>
is make && make install as you would do with other setups, very<br>
similar to what is done with gst-uninstalled except that you need the<br>
extra make install step.</blockquote><div><br></div><div>What about developing and building for platforms that are not the host platform?</div><div><br></div><div>Best regards,</div><div>Rob</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 2) Difficult to maintain multiple checkouts of Cerbero (gst 1.4,<br>
> master, custom, etc)<br>
<br>
Multiple checkouts can be maintained easilly with different<br>
configuration files that change the default paths used for the cache<br>
files, the installation prefix and the build dirs. So each build is<br>
built and installed in a different prefix using different cache files:<br>
<br>
home_dir = os.path.expanduser('~/cerbero-builds/gstreamer-master)<br>
cache_file = 'gstreamer-master-%s-%s' % (target_platform, target_arch)<br>
<br>
So end up having several config files that you can easilly change to<br>
target different builds:<br>
./cerbero-uninstalled -c gstreamer-master.cbc<br>
./cerbero-uninstalled -c gstreamer-1.4.cbc</blockquote><div><br></div><div>You can't chain cbc files, right? So then you have to do this for every platform cbc. Cool that you can though. :)</div><div><br></div><div>Rob</div><div><br></div><div><br></div><div><br></div><div><span></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But the lack of documentation is definitively a problem, since most of<br>
the useful scenarios for developing and other features like<br>
applications bundling and packaging are completely undocumented.<br>
<br>
I can also help mentoring in this project if it's needed.<br>
<br>
Andoni<br>
<br>
> 3) Downloaded-sources management is suboptimal (no checksums, etc)<br>
> 4) Built-sources management is supoptimal (mtime is compared, which is<br>
> often misleading)<br>
> 5) No way to "uninstall"/"wipeone" a recipe; need to wipe everything<br>
> 6) Essentially no documentation about how to use it<br>
> 7) More![1]<br>
><br>
> A subset or a superset of these problems can be turned into a GSoC<br>
> project. The aim is not to turn Cerbero into a full-fledged package<br>
> management system, but something that at least fulfills basic<br>
> development requirements such as "don't arbitrarily rebuild everything<br>
> ffs". :)<br>
><br>
> I volunteer myself to mentor/co-mentor this project[2] if we think<br>
> it's worth doing.<br>
><br>
> Cheers,<br>
> Nirbheek<br>
><br>
> 1. I'm sure Alessandro has many choice expletives he would love to<br>
> share with us on the matter<br>
> 2. I have experience being a GSoC student and a mentor with the Gentoo project<br>
><br>
> --<br>
> ~Nirbheek Chauhan<br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'gstreamer-devel@lists.freedesktop.org')">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
<br>
--<br>
Andoni Morales Alastruey<br>
<br>
LongoMatch:The Digital Coach<br>
<a href="http://www.longomatch.ylatuya.es" target="_blank">http://www.longomatch.ylatuya.es</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'gstreamer-devel@lists.freedesktop.org')">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote>