This task entails:

• Create a CMake option to enable coverage reporting and pass the appropriate flags to the compiler
• Generating coverage reports
• Register the project in codecov
• Upload coverage report to codecov
• Add checks to patch and project coverage
• Add coverage badge to README.md

Operating System
Ubuntu 20.04, although it will happen everywhere.

GNSS Interface version
https://github.com/EduPonz/gnss_interface/tree/7508819a324624fd045b725b7bf7f4dc13506f60

CMake options
Default

Describe the bug

Currently, there is a bug in which closing down an serial connection which is not receiving data by calling GnssInterface::close() results in a deadlock. This is because:

1. On the one hand, GnssInterfaceImpl::close() only calls to SerialInterface::close() once the reading thread has joined.
2. On the other hand, the reading thread is blocked in asio::serial_port::read_some() (waiting for one character to arrive).
   Since the sender is not sending anything over the serial line, asio::serial_port::read_some() will block indefinitely, thus causing the reading thread in GnssInterfaceImpl to never join, and therefore the call to GnssInterface::close() will never return.

The call to asio::serial_port::read_some() can be unlocked by calling asio::serial_port::close(), which GnssInterfaceImpl::close() already does here, right after the thread joins 😖. Calling asio::serial_port::close() while blocked on asio::serial_port::read_some() returns in the latter returning with and error code, so something must be done to differentiate the case in which the call returns with an error because asio::serial_port::close() was called from the one in which an actual error ocurred.

1. This could be done by simply calling to asio::serial_port::is_open() whenever asio::serial_port::read_some() returns an error.
2. Alternatively, it could be done by setting a SerialInterface::open_ flag to true when SerialInterface::open() is called, and to false whenever SerialInterface::close() is called. This way, SerialInterface::read_line() could differentiate between unlocked due to closing or error, maybe even better so, since the error could have been an untriggered close of the port.

However, this will not solve the deadlock completely, as the reading thread calls to GnssInterfaceImpl::close() whenever SerialInterface::read_line() returns false. This call will try to lock on GnssInterfaceImpl::mutex_ which is already taken by the application call to GnssInterfaceImpl::close(), which is waiting on the reading thread to join.
This can be solved by either one of:

1. Creating a GnssInterfaceImpl::closing_ flag which is set to true only while GnssInterfaceImpl::close() is executing. Then, if another thread calls to GnssInterfaceImpl::close(), the function can simply return ReturnCode::RETURN_CODE_ILLEGAL_OPERATION.
2. There could a std::mutex GnssInterfaceImpl::mutex_closing_ that GnssInterfaceImpl::close() tries to lock with std::mutex::try_lock(). If the mutex can be locked, then no one else is closing so the thread can proceed; else, GnssInterfaceImpl::close() was previously called from somewhere else, so the call should return ReturnCode::RETURN_CODE_ILLEGAL_OPERATION.

According to std::mutex::try_lock documentation, This function is allowed to fail spuriously and return false even if the mutex is not currently locked by any other thread. so this second approach should be discarded in favor of the first one.

To Reproduce
On one terminal, run:

socat pty,rawer,link=$HOME/dev/testrecv pty,rawer,link=$HOME/dev/testsend

On a second terminal, run:

<path_to_example>/gpgga_example -p /home/eduponz/dev/testrecv

Then, press CTRL-C in the second terminal.

Expected behavior
The example should exit cleanly

Perform the necessary modifications so that the library can build and run GTest test suites.

• 100% line coverage

Ticket to track the progress of adding templates for issues and pull requests

• Bug report template -> #32
• Feature request template -> #33
• Pull request template -> #34

Ticket to track the progress of adding a versioning policy document

• 100% line coverage

• Create a dedicated class NMEA0183Parser as a header only for handling the parsing of the sentences. This is useful cause in the future I'll most likely create a NMEA 0183 Parser library from which EasyNMEA will depend. Having it as a header only would ease things. As the parser will most likely be full static, this should not be a problem.
• NMEA0183Parser design documentation
• NMEA0183Parser tests
• NMEA0183Parser integration with GnssInterfaceImpl

• Add link to CODE_OF_CONDUCT.md to README.md
• Add link to CODE_OF_CONDUCT.md to documentation
• Add link to CONTRIBUTING.md to README.md
• Add link to CONTRIBUTING.md to documentation
• Cleanup README.md, since most of its content is already covered in the RTD documentation

It'd be nice if FixedSizeQueue was thread safe, meaning it should have an internal mutex used to protect all API calls. This entails overriding all the base class API to that the mutex is always lock.

Operating System
Any

GNSS Interface version
main branch

Describe the bug
The coverage badge points to master instead of main, which results in no percentage shown

To Reproduce
Check README.md in GitHbub

Expected behavior
The badge should show the coverage from https://app.codecov.io/gh/EduPonz/gnss_interface

• 100% line coverage

• 100% line coverage

• Create a collection of system tests

Ticket to track the progress of adding contributing guidelines

• 100% Line coverage

This ticket tracks the quality of service settings that it'd be cool to have for v0.2.0. The list might get longer before v0.2.0

• NMEA0183 data queue sizes should be configurable
• Default timeout for API calls. Zero would mean no timeout (unless specified in the call itself)

Is your feature request related to a problem? Please describe.

I'd like to have some Docker image that it is easy to build/deploy/download and can be used to:

1. Quickly demonstrate the capabilities of the library
2. Get more visibility for the project
3. Verify that everything works on a clean environment

Describe the solution you'd like

I'd like to include a Dockerfile that derives directly from ubuntu:20.04 or ubuntu:latest which installs all the dependencies and building tools, and which builds the library with examples, tests, and documentation.
This can be then used to just plug the GNSS module into a computer and directly read data from it using the examples.
Furthermore, it can be used for development.

I'd like to have an automated job which uploads this image to DockerHub with:

1. Every push to main
2. Every new tag
   The images should be tagged accordingly, so that users can do something like:

docker run -it gnss-interface:latest bash
docker run -it gnss-interface:v0.1.0 bash

Describe alternatives you've considered

It'd be cool to also upload the image to GitHub packages, but DockerHub is far more spread, so I think GitHub packages can wait for now.

Correctly export API symbols so Windows applications can dynamically link with GNSS Interface when using the DLL

• 100% line coverage

Is your feature request related to a problem? Please describe.
GitHub offers a code quality static analysis (CodeQL) that we should run with every contribution (see this)

Describe the solution you'd like
Create a codeql-analysis.yaml

Having a timeout for API blocking calls (mainly wait_for_data and take_next, but also open and close, and to a lesser degree is_open) would increase the real time capabilities of GNSS Interface. This would entail:

• Having an intermediate class for handling the timers
• Using Asio asynchronous timers functionality
• Tests
• Documentation

Ticket to track the progress of a code of conduct description

Operating System
Read The Docks build

GNSS Interface version
main branch

Describe the bug
Read The Docs documentation does not show PlantUML diagrams claiming

b'ERROR\n6\nSyntax Error?\nSome diagram description contains errors\n'

Locally I can see the diagrams.

To Reproduce
In this build, look for plantuml

Expected behavior
Read The Docs should show the UML diagrams