I don't think we ever settled on this.
There were 3 proposals:
#1- Newt targets as packages
#2- Newt targets stored as text in a targets/ directory
#3- Newt targets having target specific header files
I am unreservedly a fan of #2. I think we should have a targets
directory, one-file per target, that contains the target definition.
I don't think I like #1 & #3, and this is why:
- Build targets should be cheap & easy to create. Having to create an
entire package structure when you want to create a build target seems
like overkill.
- Target specific header files begin to get confusing. You end up
having to have 100's of different copies of the same header file per
build target.
If you want to specify target specific defines, that's what the CFLAGS
setting is for. Or, as in the bletiny case below, the project can
decide how many connections to allocate based upon available memory, or
another BSP hint.
Sterling
On 2/12/16 10:09 AM, Christopher Collins wrote:
Regarding compile-time options, I was thinking of cases involving BLE
applications. Nimble is a complete BLE stack, and some applications may
not want the entire package to be compiled in to the end product. For
example, some devices are simple peripherals (slaves) that don't need
any of the central (master) functionality. These targets would need to
define the appropriate nimble macros to "compile out" unneeded
functionality. Similarly, an application may need to minimize the
amount of statically allocated memory. If an application/BSP combo
(i.e., target) only has enough RAM for a single concurrent connection,
the NIMBLE_OPT_MAX_CONNECTIONS setting needs to be set to 1.
There are a few solutions to the above problems that work today:
* Minimize the amount of code in each project, and create a separate
project for each target.
* Use identities to configure groups of settings at a time.
The first solution doesn't "feel right" to me; I dislike the idea of
having to create a separate main() function for each configuration.
The second solution works for coarse-grained configuration (e.g.,
central vs. peripheral vs. combined), but it is not ideal for more
precise configuration (setting a specific number of max monnections).
I have an actual use case for this: the bletiny project. bletiny is a
simple project which provides a shell interface to the nimble
host API. I want this project to be capable of running on a variety of
different hardware with different amounts of RAM. BSPs with 16kB RAM
might only support peripheral functionality with a single connection,
while other BSPs can support something more ambitious. It would be nice
if the same project could be used in both cases.
Chris
On Fri, Feb 12, 2016 at 05:42:15PM +0000, [email protected] wrote:
I think that is fantastic. Right now it feels a bit mysterious where the
come from and its a bit awkward to share them.
I was also thinking about target specific options. Some were compiler
options like debug or optimization that you may want to turn off for
simulation targets etc, but I think that current method would work ok for
these since they are limited. What kinds of target specific options were
you thinking of? Can you give some examples?
Paul
On 2/12/16, 9:31 AM, "will sanfilippo" <[email protected]> wrote:
+1 sounds great to me.
On Feb 11, 2016, at 11:05 PM, Christopher Collins <[email protected]>
wrote:
Hello all,
It occurs to me that in the newt world, there is one entity that is not
like the others: targets. Everything else--pacakges, projects, compiler
definitions--all share the same structure: a .yml file and some source
files
enclosed in a directory. Targets, on the other hand, are tables stored
in a sqlite database. I was wondering if it would be better if targets
had the same structure as everything else.
I am envisioning a directory called "targets". Each subdirectory in the
targets directory would contain an individual target definition. I
think this change would provide several benefits:
1. Targets could be shared and downloaded using the newt package
manager.
2. Target definitions would be stored as yml files. This would bestow a
simple means of reading, modifying, and copying targets, the ability
to add comments next to target variables, and all the other benefits
inherent in human-readable configuration files.
3. A target's directory could contain target-specific header files.
The last point is what spurred me to write this email. I was thinking
about the best way to allow compile-time configuration of packages.
Modifying settings at the project or package level is not precise enough
for some uses. There are some cases where settings need to be
configured at the target level. The newt tool allows you to specify
compiler flags for each target (via the "cflags" variable), but this
becomes unwieldy when you need to configure hundreds of settings.
Anyway, just a thought. Feel free to chime in with your own :).
Thanks,
Chris
