On Fri, Oct 31, 2014 at 08:41:13AM +0100, Johannes Berg wrote: > On Wed, 2014-10-29 at 01:21 -0700, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx> > > > > In order to support built-in kernel integration we want to use > > a more generic approach to defining symbols, CPTCFG was nice as > > it was short and relied on the fact that kconfig can work with > > a getenv(CONFIG_) but for kernel integration this doesn't work > > so well. Instead let's just stick to the regular CONFIG_ > > namespace and add the BACKPORT prefix to it. > > > > Apart from these expected changes: > > > > for i in $(find ./ | grep -v "\.git"); do perl -pi -e'$_ =~ s|CPTCFG|CONFIG_BACKPORT|gs;' $i; done > > I really think you need to make this optional for the in-tree > generation, otherwise it will complicate things a lot for anyone who's > already using backports in a way that doesn't have it regenerated all > the time. Logistically I do agree this will implicate tons of merge conflicts if a git tree was used for development based on backports, however functionally I don't expect this this to create divergence. > Additionally, CPTCFG_ had the advantage of having the same length as > CONFIG_, so code style wise it was nicer to replace. > > Please make this a post-process step that runs on everything, including > the backport stuff, rather than running only on the source and assuming > the backport stuff already uses this convention. I want to but lets consider the amount of work to maintain the two separate approaches, is it worth it? Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
