#556 Initial Cmake Module definition.

[phelter]

Support for CMake and compilation with strictest definitions for GNU/Clang.

Description

Added support for CMake compile of the source code.

• Excludes some Ports at the moment - due to lack of testing infrastructure.
• Excludes integrating/changing unit-tests and compiling:
  • test/Coverity
  • test/cbmc
  • test/unit-tests
  • Reason is these are projects of their own and do not know the interworkings of these - could integrate later.
• Includes build of the Various Build-configurations for testing - including a CUSTOM for externally defined configuration.
  • DEFAULT_CONF, ENABLE_ALL, DISABLE_ALL

Test Steps

• Updated CI - but tested locally with:
  • Ubuntu 18.04 with Clang 13 - ran all 3 build configuration tests
  • Ubuntu 18.04 with GNU 7.5 - ran all 3 build configuration tests

Related Issue

• [Feature Request] Support for CMake #556 - Support for CMake.
• Note there are several Clang warnings that should be addressed in various files. These will be fixed in subsequent PR's.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[AniruddhaKanhere]

@phelter, thank you for raising the issue and creating this PR!
We are looking into it and will get back to you with changes (if any).

Thanks for your patience!

[phelter]

@AniruddhaKanhere - Thanks for reviewing. I hope it is along the lines of how you want FreeRTOS-Plus-TCP to be integrated into projects. Feel free to ask why certain things are done a certain way as I know CMake isn't well used in the embedded firmware realm too much and is an unknown beast.

It would be great if some of the ports could be done by others following the same CMakeLists.txt format/guidelines as the other ports and then I can review those as needed.

[htibosch]

CMake isn't well used in the embedded firmware
realm too much and is an unknown beast

That is probably why I know nothing about how to use cmake. I'm a GNU make user.

Like I just commented to your PR #35, would you mind to write a few lines that explain how things can be tested?

And can you also update this PR with the main branch?

Also it needs formatting: you can start that to write a 1-line comment with the contents:
/bot run uncrustify
that should start reformatting. Don't forget to pull to your local branch after doing that.
Thanks

[phelter]

/bot run uncrustify

[phelter]

@htibosch

• For how things are tested:
  Please see the changes to the ci.yml file here: https://github.com/phelter/FreeRTOS-Plus-TCP/blob/cf5aa7ff657ba650a6e62f30aa45a58a60173397/.github/workflows/ci.yml#L110
  These are also described in: test/build-combination/README.md

The cmake file now not only compiles just for these tests, but also provides the static libraries for others to include in their builds.

The user can also use these test builds to confirm that their specific FreeRTOSConfig.h and FreeRTOSIPConfig.h are also valid for the current versions of the Kernel and Plus-TCP components.
This is done by changing the cmake variable FREERTOS_PLUS_TCP_TEST_CONFIGURATION=CUSTOM.

If you would rather just look at the results the last runs are here:
https://github.com/phelter/FreeRTOS-Plus-TCP/actions/runs/3308880906/jobs/5461579784

• And can you also update this PR with the main branch?
  Done

• Formatting
  Done but bot run did not occur - so i did it manually locally on the changed test directory.

[phelter]

@AniruddhaKanhere & @htibosch

I believe I've provided all of the requested info about this PR. Would it be possible to add a few eyes on this PR in the near future?

Thanks

[phelter]

@paulbartell , @AniruddhaKanhere , @archigup :

Any progress on this? - would like to not rely on my forks of FreeRTOS/* for projects that I am working on.

[AniruddhaKanhere]

Just a small NIT pick

[phelter]

@paulbartell , @AniruddhaKanhere , @archigup :

Just a FYI,

This is the last post and update you will get from me for these changes.

I am no longer going to maintain this. Please feel free to add or abandon these changes.

I am moving my efforts on the opensource community away from FreeRTOS as the turnaround times for changes and PR's is in excess of 5 months and it looks as though there is little effort in maintaining this code base.

I am assuming Amazon is winding down it's support for FreeRTOS since there has been a shift/migration to Zephyr .

[AniruddhaKanhere]

Hello @phelter,

I am moving my efforts on the opensource community away from FreeRTOS as the turnaround times for changes and PR's is in excess of 5 months

I am sorry to hear that and sincerely apologize for the delay. We did not use CMake in +TCP and the FreeRTOS-Kernel before and had many discussions about which way is the best to avoid rework and make the repository easier to use for our users. This led to all the discussions and comments we had on your PR.
Regardless, I share your view that the turnaround time on this PR was quite large. To fix that and to ensure that this is not repeated with any other PR, we are working on a mechanism which should help us focus on pending PRs amongst other things.

and it looks as though there is little effort in maintaining this code base.

This is not accurate. We were focused on adding and refactoring the changes in the IPv6 branch. IPv6 functionality is quite sought after and thus we were prioritizing that.

I am assuming Amazon is winding down it's support for FreeRTOS

This is also not accurate. If anything, we are adding more and more to the FreeRTOS ecosystem.

Sincerely,
Aniruddha

[AniruddhaKanhere]

Thank you for this PR @phelter!

I am approving this PR. Once we have a second approval, we can merge it mainline

Thanks

[phelter]

Thanks @AniruddhaKanhere for the review.

Please note I believe this repo has similar issues to the ones mentioned in this issue:
aws/ota-for-aws-iot-embedded-sdk#465

And this was mentioned in this issue here - #570 (comment)

It looks as though there is a fundamental misunderstanding in the requirements for making a module and it's API task/thread safe and robust in the various aws opensource projects. I'd suggest adding a similar issue to this repo as well regarding a State Access Audit.

And to ensure these type of issues don't pop up with future modifications, consider incorporating both Address and Thread Sanitizer runtime unit tests. Where the unit tests stimulates the module as a black/gray-box (with all of the appropriate various threads and timers running in the typical threading organization). These type of unit-tests can then also act as confirmation that the examples you provide are operational as they are more like example code rather than low-level unit-tests.

Why do I believe this is an issue in this repo?

I've been seeing various issues with FreeRTOS-Plus-TCP hanging when using the FTP server functionality. It passes when it is compiled Debug mode, but when compiled for Release mode, the pings stop processing. In my experience, these types of bugs are typically seen when there are issues with State Access between threads/tasks (or between ISR and thread contexts). There were too many potential locations to list out for this particular repo and I was unable to convince @htibosch of the need to do this level of scrutiny without a specific error case that explicitly exposed this type of failure.

[cobusve]

@phelter for what it is worth I believe you are right about the State Access Audit. We have already done a lot of work on this and will continue with doing that. If you have more suggestions I would love to hear them.