>________________________________________ >From: Chris Johns [chr...@rtems.org] >Sent: Wednesday, July 24, 2013 11:48 AM >To: Claus, Ric >Cc: Gedare Bloom; Rempel, Cynthia; rtems-devel@rtems.org >Subject: Re: [PATCH 1/2] libmm score and stubs > >Claus, Ric wrote: >> There is already so much output generated during building that it slows a >> developer down to go through the output to determine what things must be >> paid attention to, what things can be ignored and what things are simply >> informational. My vote is for a solution that doesn't add to that burden. >> Most of the output is just distracting, but then on the other hand one does >> want to get some sense that the build is making progress. It would be >> really nice, I think, to get just one over-printed line that shows what >> directory is being worked on and that newlines are generated only by error, >> warning, and perhaps informational messages. >> >> Perhaps a possibility is to introduce --enable-mm on the configure line and >> then to print the compile-time warning only when there is a disagreement >> between the flag and the ability, i.e., --enable-mm is present, but mm >> support isn't, and --enable-mm is not present, but mm support is. In the >> "normal" case (--enable-mm is present and mm is supported, and --enable-mm >> is not present and mm support isn't) the build system would stay quiet. >>
>I do not like new configure options because it becomes just another >untested path in the build system. We have so many now that are not >tested and that it is a concern. If mm support for a bsp isn't there could we just give a message saying it's not supported and have configure switch the option to --disable-mm? That would eliminate a the path to test... >Chris _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
