I just finished building a fork of hugin and a fork of libpano13 and unmodified enblend on Windows using MSYS2 / mingw64
I tested barely more than opening an existing project, so there is a good chance some operations won't work because of errors I made in building. I ran into a massive string of problems. The non trivial ones and how I kludged around each are described below. I'd really appreciate some information on how I might have solved or avoided any or all of these problems more cleanly (other than telling me not to use mingw64). If some or all of these don't have great answers, I hope my description will help anyone else who wants to build hugin this way. I was working with a fork of hugin and libpano1, but I'm nearly certain that nothing that went wrong nor any of my kludges would be different if this was not a fork. First I got MSYS2 https://www.msys2.org/ Then I used lots of pacman commands to install lots of packages I expected to need. I didn't make a good list. But it is pretty obvious what is missing when you try CMake and pretty easy to find the name and install the package with pacman. You can't get hugin itself or panotool13 or enblend that way. But I wanted to build those myself anyway. I think building libpano13 is necessary. No pre-built binaries are compatible. But I'm pretty sure you could use pre-built binaries instead of building enblend. I followed online advice to use ninja instead of make. I don't think that caused any of these problems. *Lots of problems were in wxWidgets. * Online discussion of the first wxWidgets problem (described below) gave the opinion that the MSYS mingw64 package for wxWidgets puts things in the wrong place. I'm not an expert, but that seems wrong to me and I think instead CMake looks in the wrong place. The online suggestion for that was rebuild wxWidgets correctly. For most of the other wxWidgets problems, I think the MSYS package for wxWidgets *is *at fault and rebuilding it would be best. I never found online info of those problems. I kludged things to live with the bad wxWidgets rather than sidetrack into building a good one. cmake can't find wxWidgets I followed the instructions here. The line numbers there are obsolete. But correct places are easy to find by searching for MSYS https://forums.wxwidgets.org/viewtopic.php?f=19&t=47555#p202984 even after it find wxWidgets CMake Error at src/hugin1/CMakeLists.txt:27 (MESSAGE): It is looking for a manifest that I think it should not need and which certainly is not provided by the wxWidgets package. I gave it a different version of the manifest. Like almost all my kludges, I edited a line in CMakeCache.txt and then reran CMake: WINDOWS_DPI_MANIFEST:FILEPATH=C:/msys64/mingw64/include/wx-3.1/wx/msw/amd64.manifest It still can't find other parts of wxWidgets -- wxWidgets DLL path: WXWIDGETS_DLL_PATH-NOTFOUND A large fraction of the things it can't find are in the correct place for MSYS mingw64 which is /msys64/mingw64/bin CMake find functions seem to have lots of built in knowledge of MSYS mingw64, but it doesn't seem to work. If there was a good way to tell it that things are generally in /msys64/mingw64/binI'd like to know that. I had to individually tell it each thing WXWIDGETS_DLL_PATH:PATH=C:/msys64/mingw64/bin /include/vigra/separableconvolution.hxx:1413:13: error: ISO C++17 does not allow dynamic exception specifications 1413 | throw(PreconditionViolation) My understanding of this error is that the vigra package in MSYS is too old and a newer copy would be better. So adding that to the set of things I build myself would be cleaner. BUT instead, I noticed that is fixed in two .hxx files stdconvolution.hxx separableconvolution.hxx In the newer vigra *and *I noticed that the change to those two files would not impact the binaries. It would be wrong to copy all the .hxx files from the newer version without rebuilding the binaries. But copying those two without rebuilding is safe. -- Could not find OPTIONAL package OPENEXR -- Found OPENEXR: C:/msys64/mingw64/lib/libImath.dll.a;C:/msys64/mingw64/lib/libIlmImf.dll.a;C:/msys64/mingw64/lib/libIex.dll.a;C:/msys64/mingw64/lib/libHalf.dll.a;C:/msys64/mingw64/lib/libIlmThread.dll.a;C:/msys64/mingw64/lib/libz.dll.a I never understood that one and I never fixed it, even when I fixed the later OPENEXR problem. I have never understood any of the common cases in trying to use CMake on windows where the message that it found something is right next to the message that it could not. Can anyone tell me what part of hugin won't work as a result of this optional item missing? Also what is the actual thing that is missing? CMake Error at CMakeModules/win_bundle.cmake:107 (MESSAGE): OpenEXR dlls not found in search path That was hard to diagnose and I'm not sure I diagnosed/fixed it correctly. If I diagnosed it correctly, that cmake file thinks things are part of OPENEXR that are not in openexr but are in babl. So in msys: pacman -S mingw64/mingw-w64-x86_64-babl then in CMakeCache.txt OPENEXR_BIN_DIR:PATH=C:/mingw64/lib/babl-0.1/ enblend-enfuse files not found. I had expected the ninja install command in this environment to do something comparable to what sudo make install had done in Fedora (put the binaries in a standard place where they will be found) and I initially failed to notice that did not happen when I gave that command for enblend. So the CMake for hugin could not find enblend. But I was only doing that as a first cut anyway. Going forward I actually will want my enblend binaries in a nonstandard place. So this is a change I would have done later if I hadn't needed it now: ENBLEND_DIR:PATH=C:/msys64/home/johnf/enblend/bin Need to set builder (HUGIN_BUILDER) manually Would have been easy if I knew what a "builder" is. I thought it was a tool, like ninja. But it apparently is me. HUGIN_BUILDER:STRING=jfine src/hugin_base/panotools/PanoToolsInterface.h:50: warning: "NOMINMAX" redefined I didn't want to sort out the "right" conditionals there for the interaction of win32/msys/mingw It was simpler to just wrap the #define NOMINMAX inside a #IFNDEF NOMINMAX That is safe from a wide range of possibilities of environment conflict. src/hugin1/hugin/huginApp.cpp:382:5: error: 'wxTaskBarJumpList' was not declared in this scope src/hugin1/ptbatcher/BatchFrame.cpp:1291:9: error: 'wxTaskBarButton' was not declared in this scope I really think the MSYS package of wxWidgets is at fault on this one, and this is the best reason to rebuild that from source code and find a way to fix it there. By kludging around this problem, I think I've taken away a cute bit of windows functionality. But I don't think I've badly broken anything. Anyway, I added && 0 to the end of the innermost #IF at each of those spots to just disable that feature in my local source code. Some better solution is clearly needed. This is the most unacceptable kludge I did in this project. Once it all built, I needed a directory I could run it from, which is apparently what ninja install does, except that for hugin (unlike enblend) it suddenly cares about a bunch more things that it hadn't found before and hadn't earlier cared that it hadn't found. The first was exiftool.exe, which is not in the MSYS system, so I made the edit: EXIFTOOL_EXE_DIR:PATH=C:/Tools I expect it will be elsewhere on your system (after you download it). The rest of these were all in C:/msys64/mingw64/bin which is the only correct place for them in an MSYS/mingw64 system. As I asked before, is there any general way to tell CMake that? Or it has to be one at a time? For one at a time, the trick is knowing the right filename from the abstract filename. I looked and guessed and in some cases it was a difficult guess: TIFF_DLL-NOTFOUND TIFF_DLL:FILEPATH=C:/msys64/mingw64/bin/libtiff-5.dll JPEG_DLL-NOTFOUND JPEG_DLL:FILEPATH=C:/msys64/mingw64/bin/libjpeg-8.dll PNG_DLL-NOTFOUND PNG_DLL:FILEPATH=C:/msys64/mingw64/bin/libpng16-16.dll ZLIB_DLL-NOTFOUND ZLIB_DLL:FILEPATH=C:/msys64/mingw64/bin/zlib1.dll VIGRA_DLL-NOTFOUND VIGRA_DLL:FILEPATH=C:/msys64/mingw64/bin/libvigraimpex.dll EXIV2_DLL-NOTFOUND EXIV2_DLL:FILEPATH=C:/msys64/mingw64/bin/libexiv2.dll GLEW_DLL-NOTFOUND GLEW_DLL:FILEPATH=C:/msys64/mingw64/bin/glew32.dll SQLITE3_DLL-NOTFOUND SQLITE3_DLL:FILEPATH=C:/msys64/mingw64/bin/libsqlite3-0.dll FFTW3_DLL-NOTFOUND FFTW3_DLL:FILEPATH=C:/msys64/mingw64/bin/libfftw3-3.dll For some reason, it did not care that it had not found pano13.dll It would not run unless that also was copied to the place ninja install put all those others. Then it also wanted PTmender.exe but wanted the directory of that not the FILEPATH PANO13_EXE_DIR:PATH=C:/msys64/home/johnf/buildpano/tools On your system that will be wherever PTmender.exe ended up when you built libpano13 After fixing those and some super trivial things it runs. Gradually, I'll figure out what parts of it might be broken. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/96dc3f1c-a86c-4b98-b6a8-f3a7d85ce186n%40googlegroups.com.
