This page has been imported from Launchpad and was written by Olivier Tournaire.

Here are some tips on compiling LidarFormat on Windows:

Tests made with Visual 2008 Express Edition

Boost

Boost build

To use boost autolink on windows, you have to build boost libs with the specific toolset associated with your compiler. For example, to build all configurations with Visual 2008 Express and install in default location (C:/Boost), use this command line: bjam toolset=msvc-9.0express --build-type=complete install

In addition, you can choose to exclude some not needed libraries for the build process with the '--without-LIBTOEXCLUDE' option. For more options, see http://www.boost.org/doc/libs/1_39_0/more/getting_started/windows.html.

Boost settings

You also need to add to the PATH environment variable where are located Boost DLLs. If you used a standard installation path, it might be C:\Boost\lib. If you do not do this, you may have execution problems (Unable to find boost_xxxxxxx_.dll)_

XSD

To use XSD binaries, add the path in Tools > Options > Projects and Solutions > VC++ directories > C:\Program Files\CodeSynthesis XSD 3.2\bin. Please note that this path must be in the top of the list to avoid conflict with Microsoft xsd.exe. For other issues, please consult http://wiki.codesynthesis.com/Using_XSD_with_Microsoft_Visual_Studio

To be solved

Make .lib for a .dll

If the lib is compiled as a .DLL, tests are looking for a .LIB. Can be solved by adding specific linking rules in CMakeLists.txt depending on the value of the variable LIBRARY_TYPE (or BUILD_LIBRARY_SHARED). Some tips or explanations can be found here: * http://xenophilia.org/winvunix.html * http://www.vtk.org/Wiki/CMake_FAQ#Why_does_FIND_LIBRARY_not_find_.DLL_libraries_under_WIN32.3F

Update CPack options

Maybe after the previous fix, CPack options for Windows have to be updated.

Factory registration

The most important: on Windows platforms, the factory does not properly handle registering formats. It needs an explicit call. Have to fix that in some way ASAP.

Adrien: if the lib is compiled as a DLL, it should work out of the box... ? nevertheless, it would be good to create a function to manually register every formats in case of static lib.

Nicolas : This problem could be link to the dllexport declaration, if you not export the factory singleton, a new is created by executable using DLL, so I propose to first resolve 6) and then check if 4) remains ..

Naming conventions for libraries

Nicolas D proposed to use Boost naming conventions for compiled libraries (https://answers.edge.launchpad.net/lidarformat/+question/79469). Here is a full description: http://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html#library-naming

Thus, on Windows: * debug/dynamic: lidarformat(-mt)-dg.dll and lidarformat(-mt)-dg.lib * debug/static: liblidarformat(-mt)-dg.lib * release/dynamic: lidarformat(-mt).dll and lidarformat(-mt).lib * release/static: liblidarformat(-mt).lib
We also have to decide wether the libs names are upper or lower case. Boost conventions: all lower. ;-)

DLL Symbols exportation ##

On Windows, in order to create a DLL, a specific declaration is needed for the methods/functions. GCC exports all symbols by default, Visual does not ...

Solution 1: ( proposed by Olivier Tournaire, change into config.hpp made by Nicolas David)

I propose the following as a portable way of solving the problem: In a config.hpp file, add:

```

ifndef _lidarformat_DLL_CONFIG_H_

define _lidarformat_DLL_CONFIG_H_

// We are using the Visual Studio Compiler and building Shared libraries

if defined (_WIN32) && defined(_DLL)

#if defined(lidarformat_EXPORTS) // define by cmake /*MyLibrary_EXPORTS / #define LIDARFORMAT_EXPORT __declspec(dllexport) #else #define LIDARFORMAT_EXPORT __declspec(dllimport) #endif / MyLibrary_EXPORTS */

else /* defined (_WIN32) && defined(_DLL) */

#define LIDARFORMAT_EXPORT

endif

endif /* _lidarformat_DLL_CONFIG_H_ */

```

Then, include LidarFormat/config.hpp in all headers of the lib and add LIDARFORMAT_EXPORT before any class declaration.

NB 1: Cmake will define MyLibrary_EXPORTS on Windows when it configures to build a shared library. If you are going to use another build system on windows or create the visual studio projects by hand you need to define MyLibrary_EXPORTS when building a DLL on windows.

NB 2: Such config files brings lot of complications for syntax checking on some IDE (Eclipse CDT for example)

Solution 2: ( Nicolas David)

Quite the same as above, but config.hpp is generated by cmake from a config.hpp.in . Could resolve the IDE syntax checking problems. And made the config.hpp file more readable for end-user.