or perhaps I'll break up my app into parts that can be independently included as dependencies in the pkg.deps section of pkg.yml.
All the best Wayne On 17 June 2016 at 09:41, Wayne Keenan <[email protected]> wrote: > 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. >> >> >> > >> > >
