[PATCH 1/2] libmm score and stubs

[Chris Johns]

Rempel, Cynthia wrote:
>> ________________________________________
>> From: Chris Johns [chrisj at rtems.org]
>> Sent: Wednesday, July 24, 2013 11:48 AM
>> To: Claus, Ric
>> Cc: Gedare Bloom; Rempel, Cynthia; rtems-devel at 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...

I still see no reason for an option. Why would I use --enable-mm on a 
BSP that has no support and what would it mean if I did ? Like wise if a 
BSP has MM support why would I use --disable-mm ? Having a BSP select 
the configuration based on an architecture is fine with me.

You can also just cause a fatal runtime error if any call is used on an 
architecture with no support. That tends to get the developers attention.

Chris