Hi Wayne,

On Fri, Jun 17, 2016 at 02:28:26PM +0100, Wayne Keenan wrote:
> 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.

> > 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.

As you suspected, those are your only two options at the moment.  The
design of newt favors the approach where you break your app into several
packages, since newt's "fundamental unit" is the package, rather than
the directory or file.

After removing the bluetooth-dependent parts of your app and putting
them in separate packages, there are two ways to conditionally include
them in your project:

1. #ifdefs
    * A newt "feature" gets defined if your app will be using bluetooth
      (e.g., BLE).

    * The bluetooth-dependent library only get included as
      a dependency if the bluetooth feature is defined, e.g.,

        pkg.deps.BLE: <ble-depedencent-pkg>

    * A preprocessor symbol gets defined if the BLE feature is defined,
      e.g.,

        pkg.cflags.BLE: -DBLE_PRESENT

    * All calls into the BLE-dependent library are enclosed in ifdefs,
      e.g.,

        #ifdef BLE_PRESENT
        initialize_ble();
        #endif

2. Stub library
    * You create two packages: my_ble_pkg and my_ble_stub.  Both of
      these packages expose the same interface via identically-named
      header files.

    * The app chooses which package it depends on based on the presence
      of a feature:

        pkg.deps.BLE: my_ble_pkg
        pkg.deps.NO_BLE: my_ble_stub

    * The my_ble_pkg contains a real implementation.  The stub package
      just contains function stubs which return not-supported error
      codes or similar.

    * The BSP defines of the BLE or NO_BLE features.

The advantage of the stub library approach is that you don't need to
litter your app code with ifdefs.  However, it may not be practical to
design the app so that it is entirely ignorant of whether BLE is
supported.

I think there is some room for improvement in this area of newt, but I
don't know what the right fix would be.  I think as people build Mynewt
projects we will start to see what functionality is missing.  Any
thoughts you may have on the subject are very welcome, of course.

Thanks,
Chris

Reply via email to