On Sat, Feb 15, 2020 at 7:16 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Sat, Feb 15, 2020, 2:38 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 15/02/2020 05:22, Gedare Bloom wrote: >> >> > This makes sense. Is there any reason for the ordering? >> It should be alphabetically sorted. >> > >> > If possible, I think grouping by obsoleted version or alphabetical >> > ordering would be a good idea. >> >> Maybe I should add a comment like this to the top of the list: >> >> /* >> * Please keep the list of obsolete configuration options >> alphabetically sorted. >> * >> * Use #warning for renamed options and define the new option >> accordingly. >> * >> * Use #warning for obsolete options which are now superfluous, e.g. >> because >> * the objects are now self-contained. >> * >> * Use #error for options which require now a different configuration >> approach, >> * e.g. options for an own configuration table. >> * >> > > And note when perhaps with a version when an option was deemed obsolete. > You might be able to get that from git blame in the future but for now we > just destroyed all that info for blame by creating a new file. > +1 the internal documentation should explicitly say that. It looks like the existing warnings do spit out the version of obsolescence. Some of the macros are out-of-order. I noticed that there is N -> M -> L that are backwards. > >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
