Can ceedling use pre-generated mocks

[silabs-theophilel]

Ceedling generate for each modules (ceedling test:all) mocks at build time, while this may be a good design for local work, in a CI this could increase job time for large projects.

Is there a configuration to make use of mocks generated once or use a cache mecanism?

1. Let's say we generate them manually, we put them somewhere and configure ceedling to use these mocks once and for all not generating them. Is that possible?

2. Is it possible to configure Ceedling to generate mocks only once if run multiple time in chain? I figure that this may not be a solution in CI jobs because each jobs start from scratch, pull the sources, rebuild the project, etc ... so mocks won't be generated there in the unit-test stage. But at least if it is possible to do it locally to decrease the build/test time when running the test:all command.

[Letme]

Why dont you just copy the build/test/mocks folder among the jobs as cache or artifacts? Ceedling will see that files are there and should not regenerated them.

[Letme]

Strange. Can you check timestamps of the files if they are really regenerated and not that just messages as printed? Because I had problems in the past that I needed to use clobber few times when re-building with some strange changes.

[silabs-theophilel]

Indeed the timestamp of mocks match the last run time of the build:

❯ date
Ven 17 jan 2025 12:04:14 CET

ls -la build/test/mocks
-rw-r--r--   1 xxxxxx  xxxxxx     493 17 jan 12:04 mock_FreeRTOS.c
...

[silabs-theophilel]

Maybe I am missing a config in yml file?

here is my yml file

---
:project:
  :use_mocks: TRUE
  :compile_threads: :auto
  :test_threads: :auto
  :use_exceptions: FALSE
  :use_test_preprocessor: :all
  :use_auxiliary_dependencies: TRUE
  :use_backtrace: :simple
  :build_root: build
#  :release_build: TRUE
  :test_file_prefix: test_
  :which_ceedling: gem
  :ceedling_version: 1.0.0
  :default_tasks:
    - test:all
  :use_decorators: :none
  :verbosity: 1

:test_build:
  :use_assembly: TRUE

#:release_build:
#  :output: MyApp.out
#  :use_assembly: FALSE

:environment:

:extension:
  :executable: .out

:paths:
  :test:
    - +:test/**
    - -:test/support
  :source:
    - ../../src/**
  :include:
    # here ... include list ..
  :support:
    - test/support
  :libraries: []

:defines:
  # in order to add common defines:
  #  1) remove the trailing [] from the :common: section
  #  2) add entries to the :common: section (e.g. :test: has TEST defined)
  :common: &common_defines []
  :test:
    - *common_defines
    - TEST
    - ZGM230SB27HGN
  :test_preprocess:
    - *common_defines
    - TEST

:cmock:
  :mock_prefix: mock_
  :when_no_prototypes: :warn
  :enforce_strict_ordering: TRUE
  :plugins:
    - :ignore
    - :ignore_arg
    - :return_thru_ptr
    - :callback
    - :expect
    - :expect_any_args
  :includes:
    - sl_sleeptimer.h

# Add -gcov to the plugins list to make sure of the gcov plugin
# You will need to have gcov and gcovr both installed to make it work.
# For more information on these options, see docs in plugins/gcov
:gcov:
  :reports:
    - HtmlDetailed
  :gcovr:
    :html_medium_threshold: 75
    :html_high_threshold: 90

#:tools:
# Ceedling defaults to using gcc for compiling, linking, etc.
# As [:tools] is blank, gcc will be used (so long as it's in your system path)
# See documentation to configure a given toolchain for use

# LIBRARIES
# These libraries are automatically injected into the build process. Those specified as
# common will be used in all types of builds. Otherwise, libraries can be injected in just
# tests or releases. These options are MERGED with the options in supplemental yaml files.
:libraries:
  :placement: :end
  :flag: "-l${1}"
  :path_flag: "-L ${1}"
  :system: []    # for example, you might list 'm' to grab the math library
  :test: []
  :release: []

:plugins:
  :load_paths: []
  :enabled:
    - report_tests_pretty_stdout
    - module_generator
...

[Letme]

No, this should be default behavior of build system, so I am more concerned that it might be a regression in 1.0.0 version. As by design it should not regenerate or recompile if the dependencies are unchanged.

[silabs-theophilel]

I am happy to report a bug if needed. Let me know if you have the same behavior ot not ?
Oh and yes, I am indeed using v1.0.0 release