Yo Simon, On Wed, 18 Apr 2012, Simon Busch wrote:
> Heyho, > as some of you may know I am only some steps away from releasing a > snapshot version of all FSO components. Here comes the questions in how > we want to deal with this in SHR. > I am proposing the following for the future of shr-core and FSO: > * shr-core will use the tarballs of the FSO releases within it's build > process > * *_git.bb recipes will stay and can be used with adding fso-autorev.inc > to your local.conf (they will track the master branch as before) > * this is only for the following components: > * libfsosystem > * libfsobasics > * libfsoframework > * libfsotransport > * libfsoresource > * fsousaged > * fsodatad > * fsonetworkd > * fsotdld > * fsodeviced > * fsogsmd > * fso-specs > * libfso-glib > * libmsmhll > * libmsmcomm > * msmcomm-specs > * msmcommd > * libsamsung-ipc > * libgisi > * libgsm0710 > * libgsm0710mux > Using the release version of the FSO components gives us a hopefully > stable and ready for use situation in shr-core for the future. But this > means also, that if your adding some bug fixes or features to one of the > mentioned FSO components this will be available in shr-core only when a > new release of this component is done (which should happen more often in > the future). This sounds good to me. One thing I would like to be able to do is to just 'turn on' git for *single* projects. Say I'm working on libgisi... I would need to be able to build fsogsmd + libgisi from git. That should be no problem though with the correct magic incantations in local.conf I think. > If we decide to do it this way we have to refactor the recipe for each > component into a common one which can be used by it's git and tarball > version. > regards, > Simon Thanks for your good work :-) -- Klaus 'mrmoku' Kurzmann _______________________________________________ Shr-devel mailing list Shr-devel@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-devel
