Support dry run option

[swaldhoer]

I think, it would be very nice to have a dry run option, to see what commands ceedling would run.

[swaldhoer]

As rake supports a --dry-run command, I presume, that this should be relatively easy to implement. All one needs to do, is to pass ceedling blabla --dry-run to the rake tasks that ceedling creates.

I will grep througt the sources, and if I comprehend how ceedling internally works, I will open a pull request.

[mvandervoord]

I'm not following what the point would be? If it's not going to run any commands, it's only going to tell you the command it would run for dependency checking. Is that valuable somehow?

[mvandervoord]

In your exploration, I'd recommend starting on the test/ceedling_0_32_rc branch (it's soon to be the next official release)

[swaldhoer]

I'm not following what the point would be? If it's not going to run any commands, it's only going to tell you the command it would run for dependency checking. Is that valuable somehow?

I want to be able to run

$ ceedling verbosity[4] test:all

and see very detailed what commands ceedling would run, without having to wait e.g., 30 minutes in some of my projects.

$ ceedling verbosity[4] test:all --dry-run

So basically I want to faster acivive faster what I asked in #735

---

In your exploration, I'd recommend starting on the test/ceedling_0_32_rc branch (it's soon to be the next official release)

How soon, is this soon 😅 ?

[mvandervoord]

:) the tricky part is that many of the steps require the previous step to be run before we know what is to be run for that step. For example, knowing which files to compile requires generating dependencies, and generating dependencies might require the preprocessor to be run first.

I'm not against the idea... I'm just trying to figure out at what level it's useful. Clearly some things need to actually run, even though we're calling it a dry run... but maybe we only run the pipeline up to the point where it's figured out what is required for each test executable, and then it just tells you about the compilation, linking, and running steps without doing so?

As a side note: the 30-minute test suite times should be much faster with the next release. There are is a lot of happy threading happening to make it more efficient. On my system with my configuration, most test times have been cut to roughly 1/15th of their original time.

Side note 2: the time until release depends on how much feedback I get on the PR. My hope is to release it next week. Historically there is a flurry of activity when people see that there is a release about to happen. ;)

[swaldhoer]

:) the tricky part is that many of the steps require the previous step to be run before we know what is to be run for that step. For example, knowing which files to compile requires generating dependencies, and generating dependencies might require the preprocessor to be run first.

Ah ok, didn't think of that. Just to make sure that I get you right: The problem is, we don't know a priori what needs to be mocked etc, and so we can not really know all files that need to be compiled and linked.

I'm not against the idea... I'm just trying to figure out at what level it's useful. Clearly some things need to actually run, even though we're calling it a dry run... but maybe we only run the pipeline up to the point where it's figured out what is required for each test executable, and then it just tells you about the compilation, linking, and running steps without doing so?

I can think of two scenarios:

1. not so good approach: The mock files are ignored, and we just get the command lines for compiling and linking for the file(s) under test and the linking (which of course then missing some objects). So the learnings from this are quite low, but performance should be good.

2. may be better approach: ceedling just figures out

   • which files need to be mock
   • all files that need to be compiled
   • what needs to be done for linking

   and then we could have the real command lines, without having the generate-mock-files-, compile- and link time. Performance is of course worse than the first approach, but then you really know what ceedling would do.

As a side note: the 30-minute test suite times should be much faster with the next release. There are is a lot of happy threading happening to make it more efficient. On my system with my configuration, most test times have been cut to roughly 1/15th of their original time.

That's super nice. We still need to run the real ceedling for the testing :) A short explanation why we need this feature: We need to additionally replicate the unit test build, i.e., the ceedling build, to be able to pass the test source code and its build commands to the compiler of the SPA tool, so that we can run an SPA on the test sources. Having to wait quiiiite some time, to see what ceedling does, then fixing the stuff in the SPA build is kind of tiring to say the least. If you are interested in the details, I can explain more detailed.

Side note 2: the time until release depends on how much feedback I get on the PR. My hope is to release it next week. Historically there is a flurry of activity when people see that there is a release about to happen. ;)

I look yesterday quite some time through the code, but now coming from ruby and never having look in this code base, I must admit, it doesn't look that straight forward anymore 😅