pkg/50214: devel/cmake USE_NCURSES considered harmful

[davshao%gmail.com@localhost]

>Number:         50214
>Category:       pkg
>Synopsis:       devel/cmake USE_NCURSES considered harmful
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 07 02:30:00 +0000 2015
>Originator:     David Shao
>Release:        pkgsrc current
>Organization:
>Environment:
DragonFly  4.3-DEVELOPMENT DragonFly v4.3.1.453.gc87aec-DEVELOPMENT #8: Sun Sep  6 15:15:50 PDT 2015     xxxxxx@:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64

>Description:
devel/cmake has
USE_NCURSES
in its Makefile.  Anyone building say xfce4 through pkgsrc source could well pull in devel/ncurses through a dependency chain similar to

graphics/openjpeg has USE_CMAKE
print/poppler depends on graphics/openjpeg
print/poppler-glib depends on print/poppler
xfce4-tumbler has suggested option pdf which pulls in poppler-glib

Installing cmake with USE_NCURSES sets in place a time bomb that will sooner or later break someone like this trying to keep pkgsrc up-to-date through source.  The reason is that probably something similar to

devel/gettext-tools

was installed earlier before the attempt to install xfce4, before pkgsrc ncurses was installed.  This version of gettext-tools will link against a perfectly usable curses / ncurses base library.  Sometime later, but maybe a long time later, it comes time to update gettext-tools.  Now pkgsrc ncurses is installed, and gettext-tools seems to like to pick up this version of pkgsrc ncurses over base curses / ncurses.  This instantly breaks a whole lot of useful parts of a gui such as xfce4-terminal, gvim, other things.  

At this point it is not clear that rebuilding everything is the answer.  Does one really want to replace every previous usage of base curses / ncurses with pkgsrc ncurses?

There is a good reason for USE_NCURSES in devel/cmake, but only from what I have seen on NetBSD.  There is an include file in various bases
/usr/include/form.h
that defines a struct FORM.  cmake defines its own version of FORM.  But is also includes a simple
#include <form.h>
The FORM that cmake expects has a field curcol that NetBSD's base FORM does not.  There are probably a lot more inconsistencies that magically go away when pkgsrc ncurses is installed.

This problem does not exist from what I can tell on OSes such as relatively recent DragonFly and FreeBSD, probably a lot more that have a base equivalent to ncurses.  There is absolutely zero need for these platforms installing say xfce4 to use pkgsrc ncurses at all.



>How-To-Repeat:

>Fix:
The following patch is for DragonFly and FreeBSD.  If the problem is just NetBSD, the test can be flipped to test for NetBSD.

diff -Nurb cmake.orig/CVS/Entries.Log cmake/CVS/Entries.Log
--- cmake.orig/CVS/Entries.Log	2015-09-06 17:48:04.899568000 -0700
+++ cmake/CVS/Entries.Log	1969-12-31 16:00:00.000000000 -0800
@@ -1 +0,0 @@
-A D/patches////
diff -Nurb cmake.orig/Makefile cmake/Makefile
--- cmake.orig/Makefile	2015-08-20 04:35:33.000000000 -0700
+++ cmake/Makefile	2015-08-28 22:16:39.608277000 -0700
@@ -13,7 +13,6 @@
 
 USE_TOOLS+=		gmake
 USE_LANGUAGES=		c c++
-USE_NCURSES=		yes
 HAS_CONFIGURE=		yes
 CONFIGURE_SCRIPT=	bootstrap
 
@@ -31,6 +30,10 @@
 
 .include "../../mk/bsd.prefs.mk"
 
+.if ${OPSYS} != "FreeBSD" && ${OPSYS} != "DragonFly"
+USE_NCURSES=		yes
+.endif
+
 .if !empty(MAKE_JOBS)
 CONFIGURE_ARGS+=	--parallel=${MAKE_JOBS:Q}
 .endif