Hi, I went through the same though process, and ended in same place :)
We can avoid code duplication by having a version of slinky that has #if directives for NFFS vs FCB specific pieces. And then have other apps that includes this slinky, while selecting between the 2 options. And then specifying target you could pick one of these. But I’m not keen on that one either, because I feel it would make it harder to understand what exactly it is that you’re building. And like you say, this is only problem for these sample apps of ours, which we’ve tried to make as generic as possible. > On Apr 7, 2016, at 11:25 AM, Christopher Collins <[email protected]> wrote: > > Upon reflection, this idea has problems of its own. The app still > needs to initialize the specific flash storage package being used. So, > sorry for posting before thinking! The idea could be salvaged with the > use of some #if directives in the app code, but I am not sure this is > any better than duplicating the entire app. > > I think the problem you described won't be applicable to most apps. The > example apps are affected by this because they are meant to be as > generic as possible. > > Chris > > On Thu, Apr 07, 2016 at 11:03:07AM -0700, Christopher Collins wrote: >> That mostly sounds good to me, though I agree that the need to duplicate >> app code is not ideal. >> >> Here is an alternative idea: >> * Both fs and fcb export a suitable API (e.g., "bootapi"). >> * By default, apps depend on nffs. >> * If a particular feature is set in the target, the app depends on >> fcb instead. >> >> Something like: >> >> pkg.deps.base: >> - libs/os >> - sys/log >> - libs/newtmgr >> - libs/console/full >> - libs/shell >> >> pkg.deps: [pkg.deps.base, fs/nffs] >> pkg.deps.FCB_BOOT.OVERWRITE: [pkg.deps.base, sys/config, sys/fcb] >> >> I may have gotten the yaml syntax wrong, but I think the concept works. >> >> Chris
