Is it possible to use 'features' to include/exclude subdirectories of source and include under app/myapp/ ?
For example, I may have an app which *can* use bluetooth if available, but I may want to have a target with a hardware platform that doesn't have bluetooth so I don't want to compile any app code that depends on Nimble although "#ifdef'ing FEATURE_NAME" the whole contents of many .c/.h files out is possible I don't see it as desirable. All the best Wayne On 9 June 2016 at 22:36, Simon Ratner <[email protected]> wrote: > Great, I'll give features a try. Thanks! > > On Thu, Jun 9, 2016 at 10:33 AM, Sterling Hughes <[email protected]> > wrote: > > > Hi Simon, > > > > I agree with Will’s response, the problem you have with “inherit’ing” > > BSPs, at least at this stage, is that the APIs are changing, and > everything > > that inherits the BSP will have to change as we morph APIs. > > > > However, you shouldn’t have to maintain a different BSP for every > slightly > > different version of your own boards. If you use something called > > features, you can control these settings. > > > > A good example of this is the Arduino zero BSP, here: > > > > https://github.com/runtimeinc/mynewt_arduino_zero > > > > If you look at the pkg.yml in hw/bsp/arduino_zero ( > > > https://github.com/runtimeinc/mynewt_arduino_zero/tree/master/hw/bsp/arduino_zero > ), > > you’ll see the following lines: > > > > pkg.cflags.arduino_zero_pro: -DARDUINO_ZERO_PRO > > pkg.cflags.arduino_zero: -DARDUINO_ZERO > > > > This changes the values of the CFLAGS based upon which feature is set, > > either arduino_zero or arduino_zero_pro. This is to accommodate the fact > > that on the board, two pins are swapped depending on whether you get it > > from .cc or .org. The C code can then check this with #ifdefs. > > > > Features allow you to change dependencies, cflags, lflags and anything > > else, depending on which features are set in the build system. Features > > can be either specified as a package variable (pkg.features), or at the > > target level by doing > > > > $ newt target set your_target features=“feature1 feature2” > > > > Features are global to the build system, and everything will respect > them. > > > > sterling > > > > > > On 8 Jun 2016, at 12:43, Simon Ratner wrote: > > > > I would like to create a couple of custom bsps for boards which are > >> identical to nrf51dk but a few small tweaks (e.g. led pin, flash area > >> layout). > >> > >> From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h > and > >> os_bsp.c would do the trick, and it seems that's how mynewt itself > handles > >> this. However, I'd really prefer not to, so I can keep up with upstream > >> and > >> avoid duplicating fixes in multiple places (like > >> > >> > https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69 > >> ). > >> > >> > >> Any suggestions on how to best layer my tweaks on top of an existing > bsp? > >> Can I abuse the deps system somehow? > >> > >> Simon. > >> > > >
