Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directory structure adr #15

Merged
merged 6 commits into from
Dec 11, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions doc/adr/0003-directory-structure.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
# 3. Define directory structure

Date: 2020-12-01

## Status

Accepted

## Context

There will be many services contributed by multiple people. We need a common way of structuring the services
so it's easy for the user to pick up any one service.

pan- marked this conversation as resolved.
Show resolved Hide resolved
Some services might want to share some common code. We want to have that code structured so that include path shouldn't
change if these extensions are included into Mbed OS.

## Decision

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can split the Decision in several parts: services and extensions. Maybe we could mention test that goes into tests. I don't think there is a need to detail it at the moment.

For extensions, what do you think of having them in an extensions folder organized like Mbed OS BLE ?

  • extensions/include/ble/gatt
  • extensions/include/ble/gap
  • extensions/include/ble/common
  • extensions/source/...

That way, include path shouldn't change if these extensions are included into Mbed OS.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good, might as well put this into this adr

### Services

Each service will be its own library. All services will be in the services directory.
Each service will contain at least an include folder and a mbed_lib.json.

An example service called `example` would look like this:

```
services/example/include/ble-service-example/example.h
pan- marked this conversation as resolved.
Show resolved Hide resolved
services/example/source/example.cpp
services/example/mbed_lib.json
```

and the mbed_lib.json would contain at least:

```
{
"name": "ble-service-example"
pan- marked this conversation as resolved.
Show resolved Hide resolved
}
```

This way a user can clone the repo and include an individual service without getting unwanted includes.

AGlass0fMilk marked this conversation as resolved.
Show resolved Hide resolved
### Extensions

If a service needs to share some common code between multiple services this code can be made into an extension.

Extensions are common code, extending the mbed-os ble feature. They are libraries of their own and each service that
wants to use them needs a `requires` section that pulls it in as a dependency.

And `example` extension library:

```
extensions/example/include/ble/gatt
extensions/example/include/ble/gap
extensions/example/include/ble/common
extensions/example/source/...
extensions/example/mbed_lib.json
```

and the extension mbed_lib.json would contain at least:

```
{
"name": "ble-extension-example"
}
```

and the service needs it's mbed_lib.json expanded with a

```
requires: ["ble-extension-example"]
```

### Tests

Unit tests and integration tests go into the tests directory:

```
tests/UNITTESTS
tests/TESTS
```

`TESTS` and `UNITTESTS` are automatically ignored by mbed tools when not building tests. Any other files or directories in
the tests folder need to be added to `.mbedignore` in order to avoid compilation when the repo is included with the
intention to use one of the services.

## Consequences

All PRs amended to follow the structure. All future PRs comply with the structure.