Re: PLIST issue with cmake and ncurses

[David Brownlee <abs%absd.org@localhost>]

On 31 July 2018 at 15:33, Ian D. Leroux <idleroux%fastmail.fm@localhost> wrote:
> On Tue, 31 Jul 2018, at 10:07, David Brownlee wrote:
>> Would it make sense to add an options.mk with ccmake feature,
>> defaulting to off, so people can get whichever behaviour they need?
>>
>> On that front I'd be inclined to add an explicit --{no-,}ccmake entry
>> to the bootstrap configure script analogous to --{no-,}qt-gui
>
> In this particular case, I'd say not.  I haven't heard anyone object to
> ccmake itself, we're just objecting to 'make package' failing
> (sometimes).  If we add the option, we still have to figure out how to
> build the package reliably when the ccmake feature is enabled, and at
> that point one may as well just build ccmake all the time (avoiding
> surprises for people who use binary packages).  The only reason I
> suggested omitting ccmake was to avoid having to fix CMake's
> autodetection logic.
>
> Short version: I don't know of any reason to omit ccmake other than to
> simplify package maintenance, and making ccmake optional does not
> simplify package maintenance.

It will pull in and build ncurses as an extra dependency on some
systems where that was previously unnecessary, and ccmake does not
appear to have ever been needed in the cmake package to build anything
in pkgsrc.

However, given that pkgsrc has always tended to default binary
packages to the most complete reasonable set of functionality, I'm
happy with the idea that if someone wants to avoid that in future they
can field adding an option.mk then :)

Thanks

David