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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
