Building CEGUI 0.8 with MSVC. dllimport problems

[frarees]

I'm getting that error:
System.cpp (99): CEGUI::System::d_defaultXMLParserName is not a function

EDIT: See below, I know I was damn lazy writing this reply.

[CrazyEddie]

Congratulations!

But seriously, posting a single line like that is about as useless a post as it is possible to make, and all it serves to do is to waste the time of whichever poor soul decides to answer, and to annoy. I don't know what the project you're working on is, but if a user gave the information that you did as a diagnostic report, what would you say to them?

Please read this: viewtopic.php?f=10&t=3351 and this: viewtopic.php?f=1&t=5479

CE.

[frarees]

Quite right. I felt so lazy. My excuses.

I'm using the cmake snippet I've posted before. Compiling on MSVC. CMAKE_BUILD_TYPE is Debug for both dependencies and CEGUI. I'm using dependencies beta5. Latest CEGUI dev branch (including your latest changes).

I'm getting the error described before.

The line described was:
String System::d_defaultXMLParserName(STRINGIZE(CEGUI_DEFAULT_XMLPARSER));

I think it's not working properly. I can't see where STRINGIZE macro is defined, but I can guess what it does (in case is defined somewhere else). And I suspect CEGUI_DEFAULT_XMLPARSER is retrieved via cmake (configure_file in fact).

Looking at CMakeCache of CEGUI, those are OFF:

CEGUI_BUILD_XMLPARSER_EXPAT
CEGUI_BUILD_XMLPARSER_LIBXML2
CEGUI_BUILD_XMLPARSER_RAPIDXML
CEGUI_BUILD_XMLPARSER_TINYXML
CEGUI_BUILD_XMLPARSER_XERCES

So that might explain the problem: it's not detecting the dependencies properly yet, so that's why the system decides not to compile them.
In fact, no CEGUI_DEFAULT_XMLPARSER is defined (as far as I could search).

Do I still have to gerenate both D&R configurations for dependencies when building just debug conf. of CEGUI?

I hope this explains a bit clearer the problem.

[CrazyEddie]

You are almost certainly correct that the issue is generated because that CEGUI_DEFAULT_XMLPARSER value is not set correctly because none of the XML parsers is set to be built - which should have generated a CMake warning, but, of course, ideally if the warning is not acted upon, we should still try and prevent build errors, so I will address that in order to make the build more robust (although then any issue may not become apparent until runtime).

I ran preliminary tests before pushing those last changes and, for me at least, the detection appeared to do the right thing when faced with various configurations (so, in the case of a Debug only build, it should now detect and work correctly if only the debug dependency libs are present. There does exist a cache related issue that manifests if you change some setting that affects the dependencies we would require, there is no validation that those dependency requirements are met).

However I have intentionally made the more accurate dependency requirements somewhat dependent upon the generator used - since, in my test, if you specify CMAKE_BUILD_TYPE=Debug and use, for example, the "Visual Studio 10" as the generator, the generated MSVC++ projects still contain the various Release configurations - so for this reason, when using such a generator, the dependency checking does require both versions of the dependencies to exist, so that the user is able to build any of the configurations contained in the project. Any of the "* Makefiles" generators should, however, only require the dependencies relevant for the config and set up requesting (if we ignore the cache related issue mentioned).

In your project(s) are you specifying CMAKE_CONFIGURATION_TYPES at all? If so, we could make use of that to further correctly detect which dependency versions to require based on the configs that the generated projects will contain.

CE.

[frarees]

Yes, I'm using CMAKE_CONFIGURATION_TYPES.

However, I just noticed that it doesn't even finds the dependencies on OSX (but still builds, due to OSX's preinstalled deps, that are found on the system).

I saw your set of videos compiling on Mac. I see that the only possible difference (I can notice) is that you don't use a CMAKE_PREFIX_PATH to determine where dependencies are. Can it be a problem because it's not interpreting properly that property?

My CMAKE_PREFIX_PATH (for CEGUI subproject) is set to dependencies (that contains both dynamic and static folders inside lib), where CEGUI-DEPS are built (/Users/frarees/Documents/test/intermediate/CEGUIDEPS_DEB-prefix/src/CEGUIDEPS_DEB-build/dependencies in my case). I've checked that variable in the CMake cache, and it's the one meant to be. Of course I've checked the folders and the builds are inside.

Some of the results I get:

Code: Select all

    [cmake] -- Could NOT find DIRECTFB (missing:  DIRECTFB_LIB DIRECTFB_LIB_DBG DIRECTFB_H_PATH)
    [cmake] -- Could NOT find OPENGLES (missing:  OPENGLES_LIB OPENGLES_H_PATH)
    [cmake] -- Could NOT find EXPAT (missing:  EXPAT_LIB_DBG)
    [cmake] -- Could NOT find XERCESC (missing:  XERCESC_LIB XERCESC_LIB_DBG XERCESC_H_PATH)
    [cmake] -- Found LibXml2: /usr/lib/libxml2.dylib
    [cmake] -- Could NOT find TINYXML (missing:  TINYXML_LIB)
    [cmake] -- Could NOT find RAPIDXML (missing:  RAPIDXML_H_PATH)
    [cmake] -- Could NOT find IL (missing:  IL_LIB IL_LIB_DBG IL_H_PATH)
    [cmake] -- Could NOT find ILU (missing:  ILU_LIB ILU_LIB_DBG)
    [cmake] -- Could NOT find FREEIMAGE (missing:  FREEIMAGE_LIB)
    [cmake] -- Could NOT find SILLY (missing:  SILLY_LIB SILLY_LIB_DBG SILLY_H_PATH)
    [cmake] -- Could NOT find CORONA (missing:  CORONA_LIB CORONA_LIB_DBG CORONA_H_PATH)
    [cmake] -- Could NOT find PVRTOOLS (missing:  PVRTOOLS_LIB PVRTOOLS_H_PATH)
    [cmake] -- Could NOT find LUA51 (missing:  LUA_LIB)
    [cmake] -- Could NOT find TOLUAPP (missing:  TOLUAPP_LIB)
    [cmake] -- Found PythonInterp: /usr/bin/python (found version "2.7.1")
    [cmake] -- Found PythonLibs: /usr/lib/libpython2.7.dylib
    [cmake] -- Could NOT find Boost
    [cmake] -- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)

Remember that I'm building a Debug config. Look at those system wide libs it's finding. As I'm in debug (and looking at how your "finders" are meant to work), it shouldn't find those "not _d" libraries. So that could explain the problem I'm facing with the CMAKE_BUILD_POSTFIX workaround I've talked about before.

[CrazyEddie]

The system libraries found are supposed to be found in that way; those libs are not part of the dependency pack and so are not subjected to the same constraints. As an aside, for OS X, it was originally the intention to fall back to release version libs from the dependency pack if the _d versions (or static versions, etc) were not found - this changed when the last changes were made with regards to dependency detection, and now you must have the "right" versions available - at least that will be the case when it works correctly...

You may be right about an issue with CMAKE_PREFIX_PATH. I will investigate it and apply fixes depending on what I find (expect this and the check for CMAKE_CONFIGURATION_TYPES over the next couple of days or so - it definitely will not happen today).

CE.

PS. With regards to your earlier mention of linking issues with static libs, I'm not surprised as it's not been tested for a while - I wanted to finalise the dependencies before fixing that up again.

[frarees]

Ok now I'm quite sure what's going on:

Analyzing some code on a random dep finder:

Code: Select all

include(FindPackageHandleStandardArgs)

find_path(FREEIMAGE_H_PATH NAMES FreeImage.h)
find_library(FREEIMAGE_LIB NAMES freeimage libfreeimage FreeImage libFreeImage PATH_SUFFIXES dynamic)
find_library(FREEIMAGE_LIB_DBG NAMES freeimaged libfreeimaged FreeImage_d libFreeImage_d PATH_SUFFIXES dynamic)
mark_as_advanced(FREEIMAGE_H_PATH FREEIMAGE_LIB FREEIMAGE_LIB_DBG)

if (WIN32 OR APPLE)
    find_library(FREEIMAGE_LIB_STATIC NAMES freeimage libfreeimage FreeImage libFreeImage PATH_SUFFIXES static)
    find_library(FREEIMAGE_LIB_STATIC_DBG NAMES freeimaged libfreeimaged FreeImage_d libFreeImage_d PATH_SUFFIXES static)
    set( FREEIMAGE_DEFINITIONS_STATIC "FREEIMAGE_LIB" CACHE STRING "preprocessor definitions" )
    mark_as_advanced(FREEIMAGE_DEFINITIONS_STATIC FREEIMAGE_LIB_STATIC FREEIMAGE_LIB_STATIC_DBG)
endif()

cegui_find_package_handle_standard_args(FREEIMAGE FREEIMAGE_LIB FREEIMAGE_H_PATH)

It search for bog _LIB and _LIB_DBG in both static and dynamic termes. But, you're handling only the dynamic release one (see cegui_find_package_handle_standard_args). That should change on every finder (IMO).

It's also true that you take them into consideration if the dynamic release ones are found.

However, I think this should change, and be able to perform a simple CEGUI debug + CEGUI-DEPS debug clean build.

[CrazyEddie]

You're completely wrong. cegui_find_package_handle_standard_args is a custom macro that will take the base variable name given and use it as the basis for generating variable names of the other lib configurations. These are then tested if they were "found" based on the options and config chosen.

Assuming that CMAKE_PREFIX_PATH is not being respected, once that fix is made, and the CMAKE_CONFIGURATION_TYPES change is made, it will be possible to make a debug build with only the debug dependency libs present.

CE

[frarees]

Ok I see, haven't checked what the macro did. I'm checking now and doing some tests.

[frarees]

Finally, I've found a working solution (despite it's not the most fortuite, it works):

That's my edit over CEGUIMacros.cmake. Haven't extensively tested it yet, but it manages to find every dep I've decided to use:

Code: Select all

macro (cegui_find_package_handle_standard_args _PKGNAME _LIBBASENAMEVAR)
    unset(_FPHSA_LIBS)
    set (_BUILDCFG ${CMAKE_BUILD_TYPE})

        if (CEGUI_BUILD_SHARED_LIBS_WITH_STATIC_DEPENDENCIES)
            if (_BUILDCFG STREQUAL Debug)
                list(APPEND _FPHSA_LIBS ${_LIBBASENAMEVAR}_STATIC_DBG)
            set(${_LIBBASENAMEVAR}_STATIC ${_LIBBASENAMEVAR}_STATIC_DBG)
         else()
                list(APPEND _FPHSA_LIBS ${_LIBBASENAMEVAR}_STATIC)
            endif()
        else()
            if (_BUILDCFG STREQUAL Debug)
                list(APPEND _FPHSA_LIBS ${_LIBBASENAMEVAR}_DBG)
            set(${_LIBBASENAMEVAR} ${_LIBBASENAMEVAR}_DBG)
         else()
                list(APPEND _FPHSA_LIBS ${_LIBBASENAMEVAR})
            endif()
            if (CEGUI_BUILD_STATIC_CONFIGURATION)
                if (_BUILDCFG STREQUAL Debug)
                    list(APPEND _FPHSA_LIBS ${_LIBBASENAMEVAR}_STATIC_DBG)
               set(${_LIBBASENAMEVAR}_STATIC ${_LIBBASENAMEVAR}_STATIC_DBG)
            else()
                    list(APPEND _FPHSA_LIBS ${_LIBBASENAMEVAR}_STATIC)
                endif()
            endif()
        endif()

    find_package_handle_standard_args(${_PKGNAME} DEFAULT_MSG ${_FPHSA_LIBS} ${ARGN})


[ledgarl]

I have the same error, how do I correct it?
I try to compile in Windows 7, MSVC 2010 64

[Kulik]

Don't be lazy, start your own thread, post all info. You are replying to an ancient thread of a completely different version of CEGUI than yours.