On Fri, Jun 13, 2014 at 5:06 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote: >> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <s...@linux.intel.com> wrote: >> > This recipe will create 1 package for config files, we could optionally add >> > a bbclass file to ensure consistency with RRECOMMENDS_ = =conf >> > >> > This is a work in progress, the do_install might even beable to >> > automagically >> > generated. We don't want to create a bbclass for these since it will cause >> > the actual recipe/packaging to become machine specific, using this recipe >> > will >> > ioslate that. >> > >> > [YOCTO #4011] >> > >> > Signed-off-by: Saul Wold <s...@linux.intel.com> >> >> I think the configuration file, nowadays, already made those machine >> specific in every BSP which has those overriden so I don't see why use >> a single recipe to provide several configuration files. >> >> I think it will be confusing and this recipe will fast grow. > > There are a few good reasons to do this. > > Machine customisation is spread around a whole load of different recipes > at the moment and its hard to obtain a good view of what files are > available and which ones a BSP author may need to provide. > > Its rather ugly to have to provide and maintain multiple bbappend files > with rather ugly syntax within them. Its also rather inefficient from a > build process standpoint to have 15-20 recipes just packaging > configuration files. > > The intent isn't to mandate *every* config file should be in this > recipe, you will as now be able to add additional ones. Where we see the > same files being added in many layers, adding something common and > shared makes sense though. > > It should in some cases also allow the "core" recipe to stop being > machine specific and shared, improving build efficiency. There is little > point in a recipe becomming machine specific over a config file. > > So I'd consider this move a consolation which we can improve over time. > For new users I'd suggest that one more common place for the majority of > machine specific files would be more understandable too.
I understand and mostly agree. However I don't want to have a recipe with 20 configuration files where I'd need just two. So I think we'd need to have a way to 'enable/disable' each configuration override. Does it makes sense? -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
