On Tue, Jun 5, 2018, 10:21 PM Chris Johns <chr...@rtems.org> wrote: > 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. >
Good enough. Think on it. > > > 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? > Don't think so > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
