On Thursday 14 July 2011, Alexander Neundorf wrote: > On Thursday 14 July 2011, Sune Vuorela wrote: > > On Thursday 14 July 2011 03:42:01 Michael Jansen wrote: > > > On Thursday 14 July 2011 10:49:50 Ian Wadham wrote: > > > > On 14/07/2011, at 5:16 AM, Alexander Neundorf wrote: > > > > > What do you think of this ? > > > > > More wishes ? > > > > > Should it do it in a different way ? > > > > > > > > Very nice. I especially like the PURPOSE concept. > > > > > > > > As we discussed before, in connection with use of OpenAL sound > > > > in some games, could it be possible to have grades of requirement > > > > in between REQUIRED and OPTIONAL? They would not bomb out > > > > the cmake run, but should issue some stronger message that the > > > > requirement was not met than just saying it was "optional". > > > > > > I would suggest RECOMMENDED. Like it works without but we think its > > > really less useful then. > > > > > > OPTIONAL would be stuff then that enabled additional functionality that > > > is not really needed for all of us. like something that add iphone > > > support. not everyone has one. > > > > Several packaging systems has 3 levels of relations. > > stuff that must be there. > > > > RPM-language: Requires. Deb-language: Depends. > > > > optional stuff that should be there by default on normal systems > > > > RPM-language: Recommends. Deb-language: Recommends > > > > Optional stuff that gives something extra > > > > RPM-language: Suggests. Deb-language: Suggests. > > > > Maybe we could be inspired by that? > > > > Note that on debian systems, apt and aptitude installs Depends and > > Recommends by default, and allows Recommends to be removed without > > removing other package. > > Yum don't know about Recommends nor Suggests and just installs Required > > packages. > > Thanks for the feedback :-) > So, levels would be: > * REQUIRED > * RECOMMENDED > * OPTIONAL > > Should the output be > > Missing REQUIRED packages: > * A > * B > * C > > Missing RECOMMENDED packages: > * E > * F > * G > > or would > > Missing packages: > * A (REQUIRED) > * B (REQUIRED) > * C (REQUIRED) > * E (RECOMMENDED) > * F (RECOMMENDED) > * G (RECOMMENDED) > > be also ok ? > I guess the first option is easier to read (for humans), while the second > would be easier to parse (for a program). > > Now, anybody feels like giving this a shot ? > I'm maintaining that file currently in cmake, so I can simply commit/push > it, and I'd happily hand maintainership over :-)
Ok, this is now in cmake git master. Please give it a try, so it will have everything we need in the next cmake release (2.8.6). Alex