RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake
neundorf at kde.org
Thu Jul 14 19:48:30 BST 2011
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
Thanks for the feedback :-)
So, levels would be:
Should the output be
Missing REQUIRED packages:
Missing RECOMMENDED 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 :-)
More information about the kde-core-devel