MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013198CMakeModulespublic2012-05-06 13:512016-06-10 14:31
ReporterModestas Vainius 
Assigned ToRichard Shaw 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
Platformamd64OSDebian GNU/LinuxOS Versionsid
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013198: FindFLTK cannot be called multiple times
DescriptionHello,

original bug has originally been reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671746 [^]

----------------------
FLTK cannot be found more than once:

% cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)

find_package(FLTK)
find_package(FLTK)
% cmake .
CMake Error at /usr/share/cmake-2.8/Modules/FindFLTK.cmake:134 (IF):
  if given arguments:

    "EXISTS" "/usr/lib/fltk" "/usr/include/FLTKConfig.cmake"

  Unknown arguments specified
Call Stack (most recent call first):
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
------------------------

The problem is that FLTK_INCLUDE_DIR is a list when FindFLTK is called the second time. The list was created by:

LIST(APPEND FLTK_LIBRARIES ${FLTK_GL_LIBRARY} ${OPENGL_gl_LIBRARY})

However, FLTK_DIR is expected to be a single variable:

IF(FLTK_INCLUDE_DIR)
  SET(FLTK_DIR ${FLTK_INCLUDE_DIR})
ENDIF(FLTK_INCLUDE_DIR)
....
IF(EXISTS ${FLTK_DIR}/FLTKConfig.cmake)
    SET(FLTK_BUILT_WITH_CMAKE 1)
ENDIF(EXISTS ${FLTK_DIR}/FLTKConfig.cmake)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-06 13:51Modestas VainiusNew Issue
2012-05-07 08:31Brad KingNote Added: 0029411
2012-05-07 08:31Brad KingStatusnew => backlog
2014-09-03 09:25Richard ShawNote Added: 0036709
2014-09-03 09:48Brad KingAssigned To => Richard Shaw
2014-09-03 09:48Brad KingStatusbacklog => assigned
2014-09-03 09:49Brad KingNote Added: 0036710
2014-09-03 10:02Richard ShawNote Added: 0036712
2014-09-03 10:17Brad KingNote Added: 0036715
2014-09-03 16:10Richard ShawNote Added: 0036728
2016-06-10 14:28Kitware RobotNote Added: 0042042
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029411)
Brad King   
2012-05-07 08:31   
This module has no maintainer:

 http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

Moving to backlog awaiting a volunteer.
(0036709)
Richard Shaw   
2014-09-03 09:25   
I can't reproduce this error so I believe it is fixed.

I've got another issue with the module so I guess I'll take this one over.
(0036710)
Brad King   
2014-09-03 09:49   
Re 0013198:0036709: Thanks. The description explains why the failure occurs. Please check that changes since 2.8.8 have indeed eliminated that problem.
(0036712)
Richard Shaw   
2014-09-03 10:02   
Ok, I think the reporter pasted the wrong line... I think he meant:

    list(APPEND FLTK_INCLUDE_DIR ${OPENGL_INCLUDE_DIR})
    list(REMOVE_DUPLICATES FLTK_INCLUDE_DIR)

Which if the OpenGL include dir wasn't the same as FLTK then it would become a list.

The module doesn't set FLTK_INCLUDE_DIRS which I believe it's supposed to, corret?

The solution may be something like:
    set(FLTK_INCLUDE_DIRS ${FLTK_INCLUDE_DIR} ${OPENGL_INCLUDE_DIR})
    list(REMOVE_DUPLICATES FLTK_INCLUDE_DIRS)

That way FLTK_INCLUDE_DIR stays a single string, not a list, but is it proper to add the opengl include dirs to the plural form for FindPackageHandleStandardArg?
(0036715)
Brad King   
2014-09-03 10:17   
Re 0013198:0036712: Yes, except that we have to remain compatible with projects that just do

 find_package(FLTK)
 ...
 include_directories(${FLTK_INCLUDE_DIR}) # previously the only available variable
 ...

The logic to choose FLTK_DIR should be reworked to avoid ever getting a list.
(0036728)
Richard Shaw   
2014-09-03 16:10   
Ok, I'm really confused (by the orignal author). Under what conditions would you possibly want to set FLTK_INCLUDE_DIR to FLTK_DIR or vise verse?

Which surprisingly it does both... I can't see how on any system they should be the same. At worst the FLTK's cmake files should be put in /usr/share, but really, they contain arch dependent stuff so on Fedora they go into /usr/lib64/FLTK-1.3

From their own cmake config:
if(WIN32 AND NOT CMAKE_CROSSCOMPILING)
   set(DEFAULT_CONFIG "${CMAKE_INSTALL_PREFIX}/CMake")
elseif(APPLE)
   set(DEFAULT_CONFIG "${CMAKE_INSTALL_PREFIX}/FLTK/.framework/Resources/CMake")
else()
   set(DEFAULT_CONFIG "${CMAKE_INSTALL_PREFIX}/lib/FLTK-${FLTK_VERSION}")
endif(WIN32)

I added the "CMAKE_CROSSCOMPILING" there since for Fedora MinGW they go in standard *nix locations. I'll send that upstream. But once again, I can't see any situation where FLTK_INCLUDE_DIR and FLTK_DIR should be the same.

Then later in FindFLTK I see this:
# if FLTK was not built using CMake
# Find fluid executable.
find_program(FLTK_FLUID_EXECUTABLE fluid ${FLTK_INCLUDE_DIR}/fluid)

Huh? We're going to look in the (mis)defined include directory for a binary?

The only thing I can figure out is maybe this works for pointing to an in-tree build, not an installation, which makes sense because if it finds the fluid executable in ${FLTK_DIR}/fluid/ then it looks for libraries in "../lib" which is only the static libs. The shared libraries are in ${FLTK_DIR}.

Are we expected to support building against an in-tree build?

What a mess... I'm going to remove setting either FLTK_DIR to FLTK_INCLUDE_DIR or the other way around. If we want to support an in-tree build, then perhaps it could be used as a HINT, but nothing more.
(0042042)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.