[CMake] Problem with include directory ordering in wxWidgets_INCLUDE_DIRS
Roger James
roger at beardandsandals.co.uk
Tue Aug 10 16:58:18 EDT 2010
Please can someone with access to the bug database raise this as a problem.
The CMake module FindwxWidgets.cmake sets up an a variable called
wxWidgets_INCLUDE_DIRS which is intended to be used as the source of
additional include directories to be searched by various build tools.
The code that sets this up looks like this.
# Set wxWidgets main include directory.
IF(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
SET(wxWidgets_INCLUDE_DIRS ${WX_ROOT_DIR}/include)
ELSE(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
DBG_MSG("wxWidgets_FOUND FALSE because
WX_ROOT_DIR=${WX_ROOT_DIR} has no ${WX_ROOT_DIR}/include/wx/wx.h")
SET(wxWidgets_FOUND FALSE)
ENDIF(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
# Set wxWidgets lib setup include directory.
IF(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
LIST(APPEND wxWidgets_INCLUDE_DIRS
${WX_LIB_DIR}/${wxWidgets_CONFIGURATION})
ELSE(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
DBG_MSG("WXWIDGET_FOUND FALSE because
${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h does not exists.")
SET(wxWidgets_FOUND FALSE)
ENDIF(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
This results in the configuration specific (unicode/non-unicode) include
directories being placed after the generic include directory in the
list. This needs to be the other way round and can cause "duplicate
manifest resource" problems when linking applications on windows visual
studio platforms. This is caused by the fact that the file "rcdefs.h"
exists in both the configuration specific include dir and in the generic
include dir. However the version of rcdefs.h in the generic include dir
is only intended to be used if configuration specific ones are not found.
The gory details are that the generic rcdefs.h does not contain a
definition for WX_MSC_FULL_VER which is used to stop wxWidgets trying to
link in its own manifest resource when newer versions of the of the
Microsoft Compiler that provide their own manifests are being used.
I suggest that the two pieces of CMake code are swapped round and the
SET and LIST commands modified as appropriate.
Having the include dirs in the current order may well cause other
obscure problems as well.
Cheers,
Roger
More information about the CMake
mailing list