Examples | Configure against a coverage-enabled BSP fails (#2)

[Chris Johns (@chris)]

Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems-examples/-/issues/2#note_135020


Is the code generated with coverage instrumented to handle sampling or is the generated code same as the code without the option present? If it is different I can see a situation where a user is building RTEMS for coverage testing and that setting is accidentally merged and production code is not what it should be. At the moment there is a clear indication coverage is enabled, a linker error. I think it is right to look for a solution and fixing this situation however we should address in some way how a user can see the build is not a production standard build. If we capture and hold the build state somewhere it then becomes the user's responsibility to deal with managing that data.

I am also looking ahead a little to RTEMS dependent libraries, for example an external HAL package. In this case there will be a library that needs to flow through transparently to user builds. May be we can avoid a fragmented approach.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems-examples/-/issues/2#note_135020
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20251015/affaf3a2/attachment-0001.htm>