I try to run cmake 2.8.12.2 with visual studio 2013 ,wrong

[wenwu20082001]

the par is :
cmake_configuration_types: Debug;Release;MinSizeRel;RelWithDebInfo
cmake_install_prefix: C:/Program Files (x86)/Cesium Terrain Builder

the out information is :
The C compiler identification is MSVC 18.0.21005.1
The CXX compiler identification is MSVC 18.0.21005.1
Check for working C compiler using: Visual Studio 12
Check for working C compiler using: Visual Studio 12 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 12
Check for working CXX compiler using: Visual Studio 12 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Performing Test COMPILER_SUPPORTS_CXX11
Performing Test COMPILER_SUPPORTS_CXX11 - Failed
Performing Test COMPILER_SUPPORTS_CXX0X
Performing Test COMPILER_SUPPORTS_CXX0X - Failed
CMake Error at CMakeLists.txt:20 (message):
The compiler D:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/cl.exe has no C++11 support. Please use a different C++,
compiler.
can tou tell me ,Which compiler I have to choose? gcc or something else ,my os is windows
best wishes!

[MiniSongSong]

you should first find the depends of c++11 and gdal2.0, then comment them.
Second use cmake to generate visual studio 2010 project, then open it with visual studio 2013.
That is what i done before.

[wenwu20082001]

thank you for attention,It's useful. but I have a new problem,I can't get gdal 2.0 from http://www.gdal.org/ the heighest version I can find on ftp is 1.9.2, can you tell me where I can get gdal 2.0,,or you can send it to my email wenwu20082001@gmail.com,thank you very much,best wishes!

[homme]

@wenwu20082001 I'm afraid I don't use windows so can't help much, but as stated in the documentation GDAL 2.0 is a development branch and not yet released: you probably need to compile this yourself from source, although this page may help. Good luck and let us know if you succeed in getting it working!

[wenwu20082001]

I got gdal 2.0 source from http://trac.osgeo.org/gdal/changeset/27920/trunk?old_path=%2F&format=zip
, in the version file it's 2.0.0 . I build it successed ,but in CMake, error happened again
Found GDAL: C:\gdalout\lib
Looking for GDALOpenEx in gdal
Looking for GDALOpenEx in gdal - not found
CMake Error at src/CMakeLists.txt:13 (message):
The GDAL version must be one that implements RFC 46 (GDAL/OGR unification)
i.e. >= 2.0.0

but I can find GDALOpenEx in gdal.h

[homme]

Your downloaded GDAL version should be fine. From the error message it looks like cmake is not finding this new GDAL 2.0 version: cmake looks for the function GDALOpenEx in the gdal.h file (see here). Is your new GDAL installed in C:\gdalout\lib because that is where cmake is finding GDAL? If so, it may be worth removing any older versions of GDAL from your system.

[wenwu20082001]

the error happened in check_library_exists(gdal GDALOpenEx "gdal.h" HAVE_UNIFIED_GDAL),I debug the script,it has the right $GDAL_LIBRARY and $GDAL_INCLUDE_DIRS,in the GDAL_INCLUDE_DIRS \gdal.h,it has the method GDALOpenEx also.

[homme]

It sounds like this may be a problem with cmake on Windows in that case. If you are sure cmake has found the correct version of GDAL, you can try commenting out lines 10 to 14 inclusive in src/CMakeLists.txt and rebuilding.

[wenwu20082001]

I commenting the lines ,but too much error happened. I debug the cmakelists.txt again,found CHECK_INCLUDE_FILE(gdal.h HAVE_NET_INET_IN_H) return false.I think there is some problem seriously. I ' trying . I will let you know if there is news.thank you for your attention!

[homme]

Yes, it seems like there's either an issue specific to your environment or it is a deeper cmake issue. Either way you may find more help on the cmake users mailing list.

[Jule-]

Hi, I have same issue. It seems that there is issues with the class exports between projects. I don't know so much about cmake but clearly for a Visual Studio compilation you need to add manually export macro somewhere in ctb project :

#ifdef CTB_EXPORTS
   #define CTB_EXPORT __declspec(dllexport)
#else
   #define CTB_EXPORT __declspec(dllimport)
#endif

Then add CTB_EXPORT on classe declarations which need it, like :

class CTB_EXPORT ctb::GlobalGeodetic :
...

Another solution would be to define .def file for the exports.

I have just finished compilation, the program seems to work, just need to set correct environment variables and/or copy dependency libraries.

HTH

[homme]

@Jule- Thank you for that insight. Your CTB_EXPORT define seems to perform the same function as the GDAL CPL_DLL define. For portability reasons it may be best to use CPL_DLL, probably with a #include cpl_port.h" where appropriate. GDAL is a core dependency anyway and CTB makes use of CPL code elsewhere so pulling in cpl_port.h shouldn't be a problem.

I'm afraid I don't have access to a windows compilation environment to test these changes but I am happy to accept a pull request.

[Jule-]

@homme I've done a fresh build from scratch with your recommendations. I'm afraid that this is a little bit more complicated than you thought. In fact setting CPL_DLL is almost the same thing as the macro fix I've post before except that CPL_DLL doesn't define __declspec(dllimport) for importing symbols. Well in most case it is enough. But obviously in our case it makes the difference especially for class static members. If you don't set __declspec(dllimport) linkage fails. You can find some discussions about that. Some complain that the GDAL import/export directives are incorrect.

In brief, from my new start, in order to make it work I have to:

• Comment following CMake block directives in CMakeLists.txt:

# if(COMPILER_SUPPORTS_CXX11)
#   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
# elseif(COMPILER_SUPPORTS_CXX0X)
#   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
# else()
#   message(FATAL_ERROR "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
# endif()

and

#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -Wall -Wextra --pedantic")

It seems that some directive are not compliant with Visual compiler.

• Execute CMake with variables rightly set:
  • GDAL_INCLUDE_DIR
  • GDAL_LIBRARY
  • ZLIB_INCLUDE_DIR
  • ZLIB_LIBRARY
• Import/Convert Cesium Terrain Builder.sln in Visual Studio 2013.
• Modify ceil usage in Grid.hpp by adding (float) cast:

i_tile tx = (i_tile) ceil((float)pixel.x / mTileSize),
      ty = (i_tile) ceil((float)pixel.y / mTileSize);

Tell me if I'm wrong but since they are integers we can just write:

i_tile tx = pixel.x / mTileSize,
      ty = pixel.y / mTileSize;

I don't want to mess up with the cross compilation so I've corrected with the first less optimized correction.

• Modify CPL_DLL definition block in cpl_port.h (I have no choice, a good way would be to bubble this issue to CPL developpers, it seems that GDAL developpers have reject the issue with a poor explanation, I think)

#ifndef CPL_DLL
#if defined(_MSC_VER) && !defined(CPL_DISABLE_DLL)
#  define CPL_DLL     __declspec(dllexport)
#else
#  if defined(USE_GCC_VISIBILITY_FLAG)
#    define CPL_DLL     __attribute__ ((visibility("default")))
#  else
#    if defined(_MSC_VER)
#      define CPL_DLL     __declspec(dllimport)
#    else
#      define CPL_DLL
#    endif
#  endif
#endif
#endif

• For executable projects ctb-export, ctb-extents, ctb-info and ctb-tile:
  • Add include path for GDAL includes, the same as GDAL_INCLUDE_DIR (I don't know why CMake doesn't set it).
  • Add preprocessor variable CPL_DISABLE_DLL in order to switch CPL_DLL definition to __declspec(dllimport).
• Compile and for me it works.

NB: For INSTALL project compilation you must start Visual Studio with admin rights since it try to create a folder in Program Files. Then set correctly your environment variables in order to reach all .dll needed or copy them next to the .exe in the bin directory.

@homme I don't know how to properly modify your project in order to send you a pull request since I had to modify cpl_port.h in my GDAL installation and I don't know so much about CMake for a proper project generation. I hope you can find a way to fix this, your project is great and its future sounds promising. :)

EDIT: For the record I use CMake 3.0.2 which is different from the original subject (2.8.12.2).

[Jule-]

Trying to produce my terrain, I issued some tile path shifting, then I realized that I missed one point...

I naturally correct your ceil method by a simple integer division then I realized that what I've traduced is a floor method... And in fact according to the heightmap-1.0 terrain format, I think it's what you want! Am I right?

If so the right code is:

i_tile tx = (i_tile) floor((float)pixel.x / mTileSize),
      ty = (i_tile) floor((float)pixel.y / mTileSize);

or more simply:

    i_tile tx = (i_tile) pixel.x / mTileSize,
      ty = (i_tile) pixel.y / mTileSize;

By the way, it seems that works for me and that mistake could explain #5.

[homme]

@Jule- Many thanks for your detailed analysis. I'll have to look at the compilation issues you mention in more detail next week, but thank you for the good catch with the integer division point in your last comment. I would be happy to take a separate pull request with your fix for that. It would be great if it also helps with issue #5.

[Jule-]

Well, it seems there are some issues with terrain generation. I have some error 404 on elevation tile loading and it mess up all elevation loading. It seems that some tile are not generated or some tile are wrongly tag with missing children.