Hugin Compiling Windows with SDK

From PanoTools.org Wiki
Revision as of 05:56, 25 October 2009 by Nick (talk | contribs)
Jump to navigation Jump to search

This article gives step-by-step instructions for building hugin from a source code snapshot using Visual C++ 2008 Express Edition and precompiled dependencies. That is the recommended way to build Hugin for Windows. Once you are proficient with this, you can venture in the more complex replacement of individual SDK component up until building from scratch. It also shows how to build enblend-enfuse, which hugin requires, with the same tools.

Bear in mind that a source snapshot of hugin is a transient stage in an incomplete and rapidly evolving package, so may have a short useful life, and will contain bugs and defects. Your main purpose in building one should be to help find, report, and maybe correct some of those.

Background

The hugin build is based on cmake, a cross platform makefile generator. On Windows, cmake can generate project files for various Microsoft Visual Studio toolsets, from the same specifications it uses to create makefiles on other platforms.

There is an ongoing community effort to publish an SDK (Software Development Kit) containing all the support components needed to build hugin and enblend (and AutoPano-SIFT-C) on Windows. Pablo started the publication of SDKs two years ago. His last SDK only works for SVN revisions prior to 3479 because of new dependencies introduced with the Fast Preview project during Google Summer of Code 2008. For later revisions, the updated SDK is available here . The current SDK works only for Microsoft Visual C++ 2008 Express. This has introduced problems with non-Latin characters in filenames. The old SDK was also built for Visual C++ 2003.

You can install VC 2008 Express beside other Microsoft compiler versions, even professional ones, without damaging either toolset.

The enblend source tree has projects for building with both the 2003 and 2008 tools (also 2005 but there is no sdk for that).

The following instructions are for starting from scratch on a Windows PC without any software building tools installed. If you already have some of these things installed, you will need to take care that the right tools and components are used. It is vitally important that all object code is generated by the same compiler version and targeted to the same VC runtime library.

The recommended Tortoise archive clients work through the Windows File Explorer: right-click a target directory and follow the popup menus.

Get Tools

1) install Visual C++ 2008 Express -- Service Pack 1 recommended

2) install cmake -- latest release recommended 2.6.4 is known to work

3) install Tortoise SVN and TortoiseHG clients -- latest release recommended as the repositories are often upgraded in sync with the clients. If you know what you are doing, you may also want to install TortoiseBZR

Get hugin SDK

4) download the precompiled SDK unpack it into new directory huginbase with winrar or 7zip.

Build enblend

5) check out enblend source tree into huginbase. Create a folder huginbase/enblend. Right click on enblend in Windows Explorer and select "TortoiseHg..." from the context menu. Enter the following incantation into the Source Path field, make sure huginbase/enblend is in the Destination Path field and click Clone. 

http://enblend.hg.sourceforge.net:8000/hgroot/enblend/enblend

The result should be a new directory, huginbase/enblend, containing the source tree.

6) open huginbase/enblend/enblend_msvc2008.sln with Visual Studio 2008 Express. Change the target configuration to 'release' (build menu, configuration manager). Click build solution. After it completes, copy enblend/INSTALLDIR into huginbase/enblend-3.1/. The hugin install script expects this directory.

If the compilation failed, the SDK is probably not synchronized with the source code. To find the cause, in MSDev, in the solution explorer, right click on the enblend project-> Properties. There, follow Configuration Properties -> C/C++ -> General. On the first line is additional include directories. Click on it, and expand the window it just opened. The list of folder starting by ..\..\XXX means that XXX is expected in the huginbase folder. Compare the list here with the folders in hugin base. Change the folders required and\or download and add the missing packages

Current list of broken links between enblend and SDK:

WARNING -> This section is a work in progress. Until finished, you may break something by following this.

  • LCMS required but not part of SDK ->
    • Download version 1.18 here and unzip in huginbase folder
    • Change the dependency to point to 1.18
    • inside lcms-1.18 there is a Projects folder. Select the MSVC2008 project. Start it.
    • in the configuration manager, select to build lcms only. You do not need the other tools (that will raise an error because they don't find some dependencies)
  • SDK comes with wxMSW-2.8.10 but enblend expects versio 2.8.7 -> in MSDev in the additional DLL menu, change all paths to wxMSW-2.8.10 (don't forget, not only the version is different, the folder name is too) - do the same for enblend and enfuse projects
  • SDK provides tiff in wxMSW-2.8.10 while enblend searches in tiff-3.8.2 -> change that include for ..\..\..\wxWidgets-2.8.10\src\tiff - do the same for enblend and enfuse projects
  • SDK provides boost 1.39.0 and enblend expects trunk -> in MSDev in the additional DLL menu, change all paths from boost_trunk to boost_1_39_0 - do the same for enblend and enfuse projects
  • In the enfuse property window -> Linker -> General -> Additional Library Directories, change the path for wxWidgets for the new one. Also change the folder for lcms. Do these 2 actions on the enblend project
  • In the enfuse property window -> Linker -> Input-> Additional Dependencies, change tifflib for wxtiff.lib. Do the same for enblend


Build hugin

7) check out hugin source tree into huginbase. Make a new folder called hugin inside huginbase. Right click on huginbase/hugin in Windows Explorer, select "SVN Checkout...", enter this source URL, set target directory to "hugin" and click OK. 

  https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk

The result should be a new directory, huginbase/hugin, containing the source tree. Write down the reported SVN revision number, you will need it later.

If you are working with the 2.7 version of the SDK, right-click on the huginbase/hugin folder. In the context menu select TortoiseSVN -> update to revision... and enter the revision number 3478. Make sure the radio button is set on Revision rather than on HEAD revision and click OK.

8) Start the cmake gui (cmakesetup.exe). To ensure that the environment is set right, run cmakesetup.exe from the VC 2008 command shell (available under the Windows Start Menu) - essential if you have other compilers installed. You might want to create a desktop shortcut that does this with one click.

Set cmake's source code directory to huginbase/hugin and its build directory to huginbase/hugin-build (this will create a new directory for the build). Click Configure and tell it to use Visual C++ 2008. Cmake then checks the build tools and if that goes well does the first round of searching for components. When done it displays a list of configuration variable settings, on a red background. Click "Show Advanced Values" to display all of them.

This is when you get to correct anything that needs correcting. First, set HUGIN_WC_REVISION to the SVN revision number (which should be automatic but currently is not on Windows). And set CMAKE_BUILD_TYPE to "Release". It is an error to leave HUGIN_WC_REVISION blank, and you will get a warning message later if CMAKE_BUILD_TYPE is "Debug". Heed it.

Next, check that all component pathnames start at huginbase. Cmake may have found some things installed in standard places on your system; but it should only be using the ones in the sdk. To correct a pathname, click on it and either type in the right one or click '...' to pop a fileselector. Look out for values with "_NOT_FOUND" in them; these may indicate problems with your directory names or structure. You will need to set ENBLEND_EXE_DIR to huginbase/enblend-3.1/INSTALLDIR that that was created when you built enblend. Also, you need to set HUGIN_BUILDER and HUGIN_BUILDATE -- this is you name and date of the build that will appear on application splash screen.

When you are satisfied the paths are right, click Configure again, and Cmake will try to validate the variables. That might set some new ones, which will appear in red. Recheck all values, even the grey ones. If a variable keeps coming up wrong try deleting it from cache (right click on name pops menu) and configure again; this is often necessary to trigger a new search. Keep fixing and clicking Configure until everything is OK. Then click OK to generate the project files.

9) Open hugin.sln in the build directory with Visual Studio 2008 Express and wait while it loads and checks all the projects. Then select a target configuration and click "build solution". After a long time, and many warnings, you should get a successful build.

10) Build the INSTALL project. This should put a complete hugin installation in huginbase/hugin-build/INSTALL/FILES.

NOTE any missing file stops the install script, leaving the installation more or less incomplete. If this happens, first look at the install scripts, cmake_install.cmake (several places in the hugin-build tree) to identify all the files that were not found (paths with "_NOT_FOUND" in them). If you can find all of them, put them where the install script expects them -- hugin/cmakemodules/winbundle.cmake will help indentify those places. You can't just build INSTALL again, because the files are searched for at configuration time, so the install scripts will still contain invalid pathnames until you run cmakesetup again. Exit Visual Studio first, since all project files must be rebuilt. It may be necessary to delete pathnames of the failed places (such as enblend-3.1) from cache to ensure everything gets regenerated. Then Configure, OK, open the new hugin.sln and build INSTALL.

Updating the hugin build

To update your source tree to to the latest revision, right click on huginbase/hugin in Windows Explorer and select "SVN Update". Remember to note the revision number.

Check if there is a new release of the sdk, and if so, download and install it.

Then you have to run cmakesetup again. Proceed as in 8) above, but click "Delete Cache" before "Configure", so that the new configuration gets built from scratch.

Remember to "Clean" or "Rebuild" the entire solution in MSVC.

Installing hugin on Windows

Directory hugin-build/INSTALL/FILES contains a complete, self-contained hugin installation. You can use this as is, or copy it to a directory of your choice if you wish to delete the build tree (it is a good idea to put the the SVN version number in the name of that directory. e.g. FILES becomes "hugin_0.7.0.2766"). You should create a shortcut to hugin.exe on your desktop (note you can start new projects by dragging and dropping groups of files on the shortcut). You may also want to associate the new hugin.exe with the hugin project file (.pto) file extension.

This way of installing can be undone simply by deleting the files. It will not break any other hugin installation that may be on your system. However, note that all instances of hugin do share the same persistent settings, so options you set in one version will affect the others, too.

The source tree and sdk contain support for building Windows Installer (.msi) packages with War Setup and/or Innosetup. At present these are under development and could potentially damage your Registry and/or prior installations of hugin, so I would advise not using them until a stable release is issued.

The hugin team periodically publishes "snapshot" builds for testing. The Windows versions of these come in two forms, as a self-installing archive that automates the simple "copy files" method described above, and as a Windows Installer package.

Some things that don't work

Trying to target the dll versions of the Visual C runtimes. Only the static C libraries (libcmt, libcmtd) will do. You can't mix static and dll runtimes, so all (static) dependencies must also have been compiled with /MT or /MTd. While it might be possible to use dll versions of some of the support libraries, such as tiff or OpenEXR, it is safest to keep a strict policy of "static libraries only".

Trying to use dependencies built with a different compiler. For all practical purposes, Microsoft runtime libraries are now usable with only one compiler version. Although linking code built with more than one compiler sometimes seems to work, the resulting program is likely to fail.

Trying to link Boost libraries of a different source version than the Boost headers. Boost takes some trouble to lock object code to source version as well as compiler version, so it is rarely possible (and always a mistake) to do this.

Occasionally a build step fails mysteriously, that has succeeded before. The main cause of this is a file being marked in the Windows filesystem as in use when a tool tries to open it. On a slow, heavily loaded machine, the filesystem may not update a closed file's status quickly enough -- solution: reduce the load. On any machine, Google Desktop Search (or other automatic indexer) may grab a recently updated file and really have it open -- solution: pause or disable indexing and retry the build step.

--Tksharpless 16:42, 23 January 2008 (CET)

Retrieved from "https://wiki.panotools.org/index.php?title=Hugin_Compiling_Windows_with_SDK&oldid=11924"