ceedling 1.0.0 release candidate #739
Conversation
|
@mvandervoord will you actively ask for feedback before merging this/creating a release? I would be interested to provide feedback once this pull request reaches a good stability from your point of view. |
|
My purpose of labeling this branching so obviously was to solicit feedback. Let it roll in anytime :) |
There was a problem hiding this comment.
Hi @mvandervoord ,
I investigated why tests are failing on CI and mostly looks like the changes applied in project.yml used under test break them. I added small fix in my comments, have hope that it will help you.
|
Hi! |
I updated to c98953e of this branch and see some strange behavior:
And this is strange, as I did not change the project structure, the Any idea, what might introduce this? |
|
@swaldhoer -- thanks for doing some testing! First, for future reference, when posting a block of code on a github discussion like this, you can put the block of code (or command prompt response, in this case) between lines that contain nothing but three backticks like "```". This will make a block that preserves all the whitespace, unlike the single backticks you were using above. :) On to the real topics! First, do I understand correctly that you originally created your project to install to the vendor folder? How did you install the latest test release? Did you just download and copy over the vendor directory? This is going to make a weird little mix where you're doing your command parsing with the old version of ceedling, but using the new version in the guts. It should mostly work, but might create some quirks. This problem is my fault. I should create a gem for you to be able to test with. I'll do so soon and post it for people to try. Then, once the new gem is installed, you can do Finally, once we have you running a full new version, if you run into problems, if you could use Thanks again! I should have a gem posted soon. |
|
@mvandervoord can you put the gem creation in the CI, so that we can simply download it here? Should be much easier and requires you not to push it anywhere. |
|
@Letme -- that's a great idea. I'll see if Github Actions has that option :) |
I installed the required gems from the commit c98953e. And then updated our ceedling copy.
So we basically use the vendor approach, but some paths are tweaked to match our project setup. If you are interested I can further explain.
Ok, Then I will wait for a new gem and test again. I could overcome the include issue by adding I will only be able to run the next try on thursday (2023-02-16), but I will do for sure and post an update. |
|
@swaldhoer -- There's a prerelease gem posted in releases: https://github.com/ThrowTheSwitch/Ceedling/releases/download/0.32.0-665b570/ceedling-0.32.0-665b570.gem @Letme -- Thanks for the excellent idea. I'm liking automatic prereleases. |
Sorry this is just a memory dump from friday. I used the gem you linked and then updated the vendored files using the cli arguments.
Edit: regarding the step 2: what has been changed in the way ceedling looks for unity etc. headers? |
|
Hi @swaldhoer , Do you know maybe which header file is causing mentioned by you problem? As mostly I had similar issue in the past as you. It was connected with multiple of the pre-processor statements. Finding this file and sharing project.yml will help to investigate what change cause this issue. |
Unfortunately the answer is simple: all header files that are vendores by ceedling. I will share the project yaml later/tomorrow. |
|
Here is the project configuration. Imporant:
project.yml:project:
:use_exceptions: TRUE
:use_test_preprocessor: TRUE
:use_mocks: TRUE
:use_auxiliary_dependencies: TRUE
:build_root: .
:test_file_prefix: test_
:which_ceedling: ../../tools/vendor/ceedling
:ceedling_version: 0.31.1
:default_tasks:
- test:all
:environment: []
:extension:
:executable: .out
:paths:
:test:
- +:../../tests/unit/**
- -:../../tests/unit/support
:source:
- ../../src/app/**
- ../../src/opt/**
:include:
- +:./include/**
- +:../../src/**
- -:../../src/app/**
- -:../../src/opt/**
:support:
- ../../tests/unit/support/**
:defines:
:common: &common_defines
- UNITY_INCLUDE_EXEC_TIME
:test:
- *common_defines
:test_preprocess:
- *common_defines
- INC_FREERTOS_H
:cmock:
:when_no_prototypes: :warn
:enforce_strict_ordering: TRUE
:mock_prefix: Mock
:weak: ""
:strippables:
[
"(.FREERTOS_SYSTEM_CALL)",
"(.PRIVILEGED_FUNCTION)",
"(portDONT_DISCARD)",
]
:includes:
- "FreeRTOSConfig.h"
- "FreeRTOS.h"
- "portmacro.h"
- "mpu_wrappers.h"
- "portable.h"
- "task.h"
- "queue.h"
- "semphr.h"
- "stream_buffer.h"
- "event_groups.h"
- "string.h"
:plugins:
- :ignore
- :callback
- :ignore_arg
- :return_thru_ptr
:treat_externs: :include
:treat_as:
uint8: HEX8
uint16: HEX16
uint32: UINT32
int8: INT8
bool: UINT8
:tools_test_linker:
:arguments:
- -lm
- -flto
:tools_gcov_linker:
:arguments:
- -lm
- -flto
:gcov:
:utilities:
- gcovr
:reports:
- HtmlDetailed
- Text
- Cobertura
:abort_on_uncovered: true
:gcovr:
:report_root: "../../"
:report_exclude: ".*vendor.*|.*build.*|.*test.*|.*tests.*|.*lib.*|.*Test.*|.*src.hal.*|.*src.os.*"
:exclude_directories: ".*tests.*|.*src.os.*|.*build.*"
:sort_percentage: true
:sort_uncovered: false
:html_medium_threshold: 60
:html_high_threshold: 85
:print_summary: true
:num_parallel_threads: 4
:keep: false
:junit_tests_report:
:artifact_filename: report_junit.xml
:plugins:
:load_paths:
- ../../tools/vendor/ceedling/plugins
:enabled:
- gcov
- stdout_pretty_tests_report
- module_generator
- xml_tests_report
- junit_tests_report |
|
@swaldhoer -- it sounds like the new automatic generation of the gem isn't adding the submodules (unity, cmock, etc) to the gem. I'll figure out what's going on with that. More concerning are the other failures. It's looking like something with the updated preprocessor calls isn't happy? Can you do a quick test where you disable the preprocessor and As a side note, feel free to add the following two lines to your project section: This should help speed things up. :) |
|
@swaldhoer -- Hm. I've done some digging into issue 2 in your list above (where the dependency headers weren't being found). Interesting enough, it appears that the generated gem file is correct. I'm wondering if it's the upgrade process itself. Ceedling's self-upgrade feature is minimalist at this point (particularly compared to where we want it). Did the gem correctly update the contents of |
|
I did not use the update mechanism. I created a new project and then copied everything. This is how we did it (1 or 2 times before I guess) and it worked. |
really rake or did you mean ceedling?
I think I did it like this. I will test tomorrow again and come back. |
|
Hahaha... you are correct. I meant Your upgrade method should be fine. That suggests I have something wrong in the way ceedling is finding its subprojects when not using the gem. Thanks for the help! I should be able to find this error. :) |
|
I am updating to newer version (because github default dockers now use Ruby 3.2) and just hit the following problem when using this branch. I have following And the error I get after running command: Any ideas what is wrong? |
|
Have you tried what is stated here? PROJECT_CEEDLING_ROOT = "tools/ceedling"
load "#{PROJECT_CEEDLING_ROOT}/lib/ceedling.rb"
Ceedling.load_project
task :default => %w[ test:all release ] |
|
@Letme are you calling |
Yes, I am. Because I do not install ceedling, i use it as submodule. I guess i need to call ./tools/ceedling/bin/ceedling then... (or something- sorry am on mobile) |
|
OK, if I change I also ran File is: https://github.com/melexis/mlx90632-library/blob/master/test/TestDSP.c |
Updated preprocessing related to `TEST_SOURCE_FILE()`, `TEST_INCLUDE_PATH()`, `TEST_CASE()`, and `TEST_RANGE()`
The order of revised defaults and automatic configuration settings handling left the possiblilty of trying to set a value in Unity and CMock configuration that was incomplete. A user’s configuration might create a partial configuration block that automatic settings tried to fill out but would encounter nil references dpeending on the accompanying logic. The fix was to reorder how user config, defaults, and auto configuration values are processed.
A previous refactoring provided a better wrapper method to access line-at-a-time code cleaning.
Shenanigans around unspecified versions in Gemfile and old versions in .gemspec were causing Github Action build failures
Matches Windows task name changes
…processor). This is primarily to handle situations where mocks need includes further down the include chain.
- Clarified how to install a Ceedilng .gem file downloaded from the Github repo - Called out the the project configuration cheat sheet in the Release Notes
- Deep preprocessor config setting is validated (and limited to `:none` and `:mocks`) - Project configuration is inspected for problematic / unsupported configuration combos and generates logging warnings explaining these problems
TODO: Update the fff snapshot to version 0.2.0 (issue #954)
- Added latest Ruby 3.4 - Bumped release build to use Ruby 3.3
…itch/Ceedling into test/ceedling_0_32_rc
…ch/Ceedling into test/ceedling_0_32_rc
I'm going to start building the 0.32 release candidate here. It might be a bit early for a PR, but this makes it easier to test on Actions.
Comments, help, and thoughts are welcome.