On Fri, 2014-10-31 at 20:34 +0100, Luis R. Rodriguez wrote: > > 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. Agree, but it's going to be a nightmare from the merge point of view, and also the CPTCFG_ is nicer to replace back and forth between backports-based development and the kernel, due to this: > > 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? I don't see why it'd be maintaining two approaches? Right now we have scripting to replace CONFIG_ with CPTCFG_, so couldn't we just add more scripting to replace CPTCFG_ with CONFIG_BACKPORT_ ? That also makes me think of something else - we currently use BACKPORT_ as a prefix for some of the other stuff under compat/Kconfig, and in fact rename some things (like CONFIG_BACKPORT_AVERAGE) so maybe also using CONFIG_BACKPORT_ here isn't a great idea? Might want to use something else, say CONFIG_BPT_ or so. johannes -- 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