On 1/6/18 9:13 am, Joel Sherrill wrote: > Just chatted with Chris. The coverage BSP ini file was a temporary > measure as I thought.
I may have not understood the specific issue being discussed when we talked. I separated the INI files because this is what we do else where (see the leon3 example below). I consider options as a way to vary the default behavior so the less we have the better. A default run without extra options is preferred. You cannot add --coverage to all supported BSPs and get coverage and for this option to be useful this is what the option should do. To control coverage you need to know it can be supported so the question becomes simple, if you can do coverage why would you decide not too? In other words 'leon3-qemu-cov' should not need a --coverage option unless you wish to change the sets used and that is varying the default behavior. For example you can run leon3 with: leon3 leon3-qemu-cov leon3-qemu leon3-run leon3-sis leon3_tsim leon3_tsim-run leon3-tsim-cmds and we do not have options to manage any of these differences line 'tsim' so why is coverage being treated as something special? To me it is not. The separation was on purpose and for this reason and not temporary. The changes needed to have this happen may require some refactoring, I am not sure yet. > Make a list of all the ideas we have had for improvements. We want > the code to get onto master. > > The list should be converted to Trac tickets very soon. Then we can > decide which are critical for GSoC, which Chris or I will work on, and > which are part of your GSoC. Have these tickets been created? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
