View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015011CMake(No Category)public2014-07-09 07:142015-05-04 09:05
ReporterFritz H 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformSPARCOSSolarisOS Version10
Product VersionCMake 3.0 
Target VersionCMake 3.1Fixed in VersionCMake 3.1 
Summary0015011: problem to find non-standard ncurses.h location
Descriptioni have installed gnu ncurses (and several other libraries) under separate location; os: solaris10, compiler: sunstudio 12.2

building cmake 2.8.x worked using

env \
  CC=cc \
  CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \
  CXX=CC \
  CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \
  LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' \
  CPPFLAGS=-I/var/imb/include \
    ./bootstrap --prefix=/var/imb; gmake

with cmake 3.0, the "gmake" step fails:

cmake-3.0.0/Source/CursesDialog/form/form.h", line 46: cannot find include file: <ncurses/ncurses.h>

and -I/var/imb/include must be explicitly added to CFLAGS / CXXFLAGS for ncurses.h to be found, i.e., i have to use

env \
  CC=cc \
  CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \
  CXX=CC \
  CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \
  LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' \
  CPPFLAGS=-I/var/imb/include \
    ./bootstrap --prefix=/var/imb; gmake

imho, the value of CPPFLAGS should be honoured here
TagsNo tags attached.
Attached Files

 Relationships
related to 0015166closed cc: acomp failed for Source/CursesDialog/form/fld_arg.c 

  Notes
(0036331)
Brad King (manager)
2014-07-09 09:27

 Changes to FindCurses.cmake between 2.8.12 and 3.0 include:

 FindCurses: Honor CURSES_NEED_NCURSES when curses is found
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e4a2c7e [^]

 FindCurses: Detect and satisfy ncurses dependency on tinfo
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f646c6c [^]

Does reverting either or both of these resolve the issue?
(0036336)
Brad King (manager)
2014-07-10 10:09

 Copying an email-sent comment from the mailing list: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10447/focus=10461 [^]

On 07/10/2014 12:10 AM, Greg Jung wrote:
> The CMake module scripting is weak regarding the variable that should be taking care of this,
> CMAKE_SYSTEM_PREFIX_PATH (i.e., /usr; /opt) will be used in find_path (after appending /include)
> and for find_library(after appending /lib) - according to cmake.html documentation. For my mingw/msys
> builds I set this and the /include, /lib mostly located in platform/MingW.cmake:
> ----------------
> if(MSYS)
> # enhance the system prefix path. (picks up /Mingw/lib)
> find_path( MINGWPATH msys
> PATH ${CMAKE_USR_PATH}/../../
> NO_DEFAULT_PATH)
> list(APPENDCMAKE_SYSTEM_PREFIX_PATH ${MINGWPATH} )
> list(APPEND CMAKE_SYSTEM_INCLUDE_PATH ${MINGWPATH}/include )
> list(APPEND CMAKE_SYSTEM_LIBRARY_PATH ${MINGWPATH}/lib )
> -------
> then LDFLAGS is inspected:
> ____
> set(LDFLAGS "$ENV{LDFLAGS}")
> if(LDFLAGS)
> message(STATUS "\n"
> " <Platform/Mingw> inspecting LDFLAGS: ${LDFLAGS}")
> string( REGEX MATCHALL "-L([^\" ]+)" librarylist
> "${LDFLAGS}")
> foreach(element IN LISTS librarylist)# LDFLAGS is more specific.
> ------------ etc., leading to
> message(STATUS
> "<Platform/Mingw> adding system library path: ${library}")
> list(INSERT CMAKE_SYSTEM_LIBRARY_PATH 0 ${library})
> list(INSERT CMAKE_SYSTEM_INCLUDE_PATH 0 ${library}/../include )
> -------------------------------------------------------
(0036338)
Brad King (manager)
2014-07-10 10:25

 > imho, the value of CPPFLAGS should be honoured here

CPPFLAGS has no defined behavior for CMake. See 0012928.
(0036341)
Fritz H (reporter)
2014-07-10 11:15

 reverting this one:
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e4a2c7e [^]
results in previous behaviour, i.e., bootstrap/gmake succeed, specifying -I... with CPPFLAGS, and -L/-R... with LDFLAGS

but taking a closer look reveals that "previous behaviour" is actually: ignore ncurses completely. otoh, libidn and libiconv, also installed below /var/imb/..., are found and used as expected.

activating patch 0e4a2c7e results in using libncurses from /var/imb/lib but
searching ncurses.h in /usr/include which clearly does not work.

looking at FindCurses.cmake, the following changes worked for me
@@ -104,9 +104,9 @@
   find_file(CURSES_HAVE_CURSES_H curses.h
     HINTS "${_cursesParentDir}/include")
 
- find_path(CURSES_NCURSES_INCLUDE_PATH ncurses.h ncurses/ncurses.h
+ find_path(CURSES_NCURSES_INCLUDE_PATH ncurses/ncurses.h ncurses.h
     ncurses/curses.h)
- find_path(CURSES_NCURSES_INCLUDE_PATH curses.h
+ find_path(CURSES_CURSES_INCLUDE_PATH curses.h
     HINTS "${_cursesParentDir}/include")
 
   # for compatibility with older FindCurses.cmake this has to be in the cache

though in my opinion both changes fix an error / misconception, i can not really judge all the consequences of what i did here :-)
(0036345)
Brad King (manager)
2014-07-10 14:22

 Re 0015011:0036341: It looks like things are getting confused by having both ncurses.h and ncurses/ncurses.h available in different places.

FindCurses is one of the oldest find modules because it was created for ccmake originally. Projects should never have to switch between #include <ncurses.h> and #include <ncurses/ncurses.h> and instead should just have the -I option specify the path to include/ncurses if necessary. I've overhauled the module to take advantage of that simplification:

 FindCurses: Overhaul Curses and NCurses search logic
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fcca1eb9 [^]

You can download the updated module from here:

 http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Modules/FindCurses.cmake;hb=fcca1eb9 [^]

and try replacing the version in your 3.0 build locally.
(0036355)
Fritz H (reporter)
2014-07-11 08:47

 trying to build cmake-3.0.0 using FindCurses.cmake from fcca1eb9 does not work for me, compilation of the files in Source/CursesDialog/form/ fails due to non-found include files

ncurses include files, at least recent versions, get installed below __includepath__/ncurses/, and expect to be included via #include <ncurses/something.h>

without further measures you even don't get a __includepath__/ncurses.h when compiling/installing recent ncurses from source (e.g., on suse, a sym link ncurses.h -> ncurses/ncurses.h is added to the ncurses package)

so, find_path really should look for ncurses/ncurses.h

looking additionally for ncurses.h after ncurses/ncurses.h shouldn't hurt as find_path returns after the first match (doesn't it?) -- i don't remember the history of the ncurses software right now, so i can't tell whether old versions only installed __includepath__/ncurses.h
(0036361)
Brad King (manager)
2014-07-14 09:16

 Re 0015011:0036355: Thanks for testing.

Ugh, my entire rewrite was based on the incorrect assumption that the ncurses/ layout was an artifact of the early find module design and not an actual requirement of the headers. The modern ncurses.h on my Debian system does not do that.

I've reverted the change linked in 0015011:0036345 from 'next'. It was never merged to 'master'. I'll revise with the ncurses/ layout in mind.
(0036373)
Brad King (manager)
2014-07-14 11:27

 Re 0015011:0036361: Revised here:

 FindCurses: Overhaul Curses and NCurses search logic
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c8364e6 [^]

Direct link:

 http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Modules/FindCurses.cmake;hb=6c8364e6 [^]
(0036376)
Fritz H (reporter)
2014-07-14 13:37

 very nice, building cmake-3.0.0 using FindCurses.cmake from 6c8364e6 works now

(and make test also works after applying the patches described in http://public.kitware.com/Bug/view.php?id=14989 [^] :-)

thanks for your efforts
(0036380)
Brad King (manager)
2014-07-14 15:11

 Re 0015011:0036376: Thanks for testing. The rewrite of FindCurses is too big a change to put in a patch release (e.g. 3.0.1) but this can go in 3.1. It should still be possible to build CMake 3.0 without the change by manually setting the find results correctly with -D... options.
(0038711)
Robert Maynard (manager)
2015-05-04 09:05

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-07-09 07:14 Fritz H New Issue
2014-07-09 09:27 Brad King Note Added: 0036331
2014-07-10 10:09 Brad King Note Added: 0036336
2014-07-10 10:25 Brad King Note Added: 0036338
2014-07-10 11:15 Fritz H Note Added: 0036341
2014-07-10 14:22 Brad King Note Added: 0036345
2014-07-11 08:47 Fritz H Note Added: 0036355
2014-07-14 09:16 Brad King Note Added: 0036361
2014-07-14 11:27 Brad King Note Added: 0036373
2014-07-14 13:37 Fritz H Note Added: 0036376
2014-07-14 15:11 Brad King Note Added: 0036380
2014-07-14 15:11 Brad King Assigned To => Brad King
2014-07-14 15:11 Brad King Status new => assigned
2014-07-14 15:11 Brad King Target Version => CMake 3.1
2014-07-15 09:25 Brad King Status assigned => resolved
2014-07-15 09:25 Brad King Resolution open => fixed
2014-07-15 09:25 Brad King Fixed in Version => CMake 3.1
2014-12-23 10:33 Brad King Relationship added related to 0015166
2015-05-04 09:05 Robert Maynard Note Added: 0038711
2015-05-04 09:05 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team