>>>> 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
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
