[PATCH 1/2] libmm score and stubs

[Gedare Bloom]

I'm happy with the current state, which will execute but not do
anything. For the libmm usage I think this is OK. I see no compelling
reason to change the stub implementation to anything other than a nop.
Turning it into a fatal error makes testing it harder, since it
becomes a "fatal test" for BSPs that do not have the functional
implementation. It also makes code that uses libmm less portable to
other platforms where the MM support is non-functional.

On Wed, Jul 24, 2013 at 4:48 PM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu> wrote:
>>>>> 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.
> Wow!  Less needing to be tested, AND we don't have to worry about misleading the user :) Could we do that?
>>Chris
>
>
>