[PATCH 1/2] libmm score and stubs

[Rempel, Cynthia]

>>>> 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