Docs: write Windows build instructions

[aras-p]

Description

I recently wrote down how to build OIIO from source for myself (https://gist.github.com/aras-p/6497703c9b52f67761e6191343e43f7b), and maybe a slightly cleaned up version would be good to put into actual docs.

Tests

N/A

Checklist:

• I have read the contribution guidelines.
• If this is more extensive than a small change to existing code, I
  have previously submitted a Contributor License Agreement
  (individual, and if there is any way my
  employers might think my programming belongs to them, then also
  corporate).
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite
  (adding new test cases if necessary).
• My code follows the prevailing code style of this project.

[DominikGrabiec]

Thank you for that!
I'll give it a go soon, and I have an idea to use vcpkg to pre-build then export the dependencies (if they're at the right versions).
If that works out I'll contribute to the docs as well.

[DominikGrabiec]

Not sure if this is a bug in the project's CMake but you need to also specify -DUSE_QT5=0 otherwise you get an error because QT5 is not found.

[aras-p]

Not sure if this is a bug in the project's CMake but you need to also specify -DUSE_QT5=0 otherwise you get an error because QT5 is not found.

Hmm, I don't have any Qt on my system, and just -DUSE_QT=0 is enough here 🤷

[DominikGrabiec]

Taking what you wrote and what vcpkg have in their OIIO port I have managed to build OpenImageIO using:

vcpkg install boost fmt libheif libjpeg-turbo libpng libsquish openexr robin-map tiff zlib --triplet=x64-windows-static

cd oiio
mkdir build
cd build

cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static -DCMAKE_TOOLCHAIN_FILE=%VCPKG_ROOT%\scripts\buildsystems\vcpkg.cmake -DBUILD_SHARED_LIBS=OFF -DVERBOSE=ON -DBUILD_DOCS=OFF -DINSTALL_DOCS=OFF -DBUILD_TESTING=OFF -DLINK_STATIC=OFF -DUSE_LIBRAW=OFF -DUSE_OPENCOLORIO=OFF -DUSE_FFMPEG=OFF -DUSE_FREETYPE=OFF -DUSE_GIF=OFF -DUSE_OPENCV=OFF -DUSE_OPENJPEG=OFF -DUSE_WEBP=OFF -DUSE_PYTHON=OFF -DUSE_OPENGL=OFF -DUSE_DCMTK=OFF -DUSE_NUKE=OFF -DUSE_QT=OFF -DUSE_QT5=OFF -DUSE_OpenVDB=OFF -DUSE_PTEX=OFF -DUSE_TBB=OFF -DOIIO_BUILD_TOOLS=OFF ..

Should also work if the triplet is x64-windows rather than x64-windows-static.

[DominikGrabiec]

From what I can see in externalproject.cmake, USE_QT is used for if statements but USE_QT5 is used in the call to checked_find_package (Qt5 COMPONENTS ${qt5_modules}). So if I didn't include that it ended up warning on missing Qt5.

CMake Warning at E:/vcpkg/scripts/buildsystems/vcpkg.cmake:833 (_find_package):
  By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5" with any of
  the following names:

    Qt5Config.cmake
    qt5-config.cmake

  Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
  to a directory containing one of the above files.  If "Qt5" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  src/cmake/checked_find_package.cmake:127 (find_package)
  src/cmake/externalpackages.cmake:257 (checked_find_package)
  CMakeLists.txt:154 (include)


-- Qt5 library not found
--     Try setting Qt5_ROOT ?

[lgritz]

I think it might be more clear to call this OpenImageIO_ROOT, just to be consistent with the CMake convention that somebody would use so their downstream find_package(OpenImageIO) works.

[lgritz]

This is really great, thanks so much, @aras-p. (I really need to get that phrase assigned permanently to a hotkey.)

I made one suggestion, which we don't have to fix in this PR, it's easy enough to patch afterwards. (The instructions here aren't wrong, I just think it may save us trouble down the road to match the other "how do you build downstream" instructions using the same nomenclature.)

I'm also thinking we should straighten out the USE_QT vs USE_QT5 confusion, but again, that sure doesn't need to be part of this PR, and maybe I need to think a bit about the least awkward way to handle that and also leave room for Qt6 eventually without that becoming yet another awkward transition.