Website fails to build on Windows

[cary-ilm]

The test image gallery step fails with:

E:\devdays\openexr\build>cmake --build . --target website
MSBuild version 17.3.0+f67e3d35e for .NET Framework
  Running doxygen
  Generating test image pages
  %1 is not a valid Win32 application
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(247,5): error MSB8066: Custom build for 'E:\devdays\openexr\website\Doxyfile.in;E:\devdays\openexr\build\CMakeFiles\c3152c30a40b569a3efe05c31097f728\index.rst.rule;E:\devdays\openexr\build\CMakeFiles\b2d3be5298683ed7e04330859653c62d\index.html.rule;E:\devdays\openexr\build\CMakeFiles\e5d5900e5ad15c837a0c50e9bda0ccd4\website.rule' exited with code 1. [E:\devdays\openexr\build\website\website.vcxproj]

[lji-ilm]

I am following up on these finally ... I tried to build the website on WSL Ubuntu 22 LTS first before dare to try it on Win 10 native, because it need to at the very least run on WSL; and considering most Windows people these days can grab a WSL with ease, so if we can build it on WSL maybe we don't even need to bother with windows native.

This quickly bring my attention to this line:

openexr/website/scripts/test_images.py

Line 395 in 231d0e9

result = run (['which', 'exrheader'],

print(f'PATH={os.environ["PATH"]}')
result = run (['which', 'exrheader'],
              stdout=PIPE, stderr=PIPE, universal_newlines=True)
print(f'exrheader={result.stdout}')

This won't work -- certainly not on windows native because we have no "which" and probably not even PATH, but also not even on vanilla WSL because one would not have installed exrheader in PATH according to the website instructions. I'm trying to build+install openexr on WSL first (which will generate the exrheader executable commandline tool, then continue with the experiment...

[lji-ilm]

After manually build openexr first and installing exrheader in PATH, i was able to build the website successfully in WSL. That gives me at least a workable way to edit the contents.

The specific error Cary posted above is from here:

openexr/website/CMakeLists.txt

Line 46 in 231d0e9

COMMAND ${CMAKE_COMMAND} -E env "PATH=${CMAKE_CURRENT_BINARY_DIR}/../bin:$ENV{PATH}"

This means the command cmake is not on PATH. However on Windows development it is generally anti-pattern for a build to add a bunch of customized app onto PATH such as cmake and exrheader. Rather, it should be a self-contained variable in the CMAKE file.

Given that there are so many python subprocess.run() calls in that scripts\test_images.py, I don't think it would worth fixing all of them to be turely cross-platform; we'll need to make sure all those subprocess.run() calls can properly find their apps, for many of which simply doesn't exist on windows. I think there are two paths we can take here:

1. Just update the documentation page, telling people to use WSL, and install exrheader in path before trying to build the website.
2. Do not include test_images.py in the website building process. Rather, pre-transcode the website images from exr into a website format (PNG or JPEG) in the openEXR repo, and the website builder simply retrieve these website-friendly image from the repo.
   @cary-ilm what do you think?

[lji-ilm]

Continue to learning how to build this website -- it appears the generated website in my local dir is missing style sheets.

Simply open the index.html inside $repo\_build\website\sphinx results in a page that looks like this:

I'm wondering how to supplement the styles, and as so, shall we edit the "how to build website" part (in the website itself!) to capture this?

[cary-ilm]

@lji-ilm, I really wanted to avoid duplicating all the images as jpg's in the images repo, which was the reason to go to the trouble of converting them on the fly. In addition to the extra storage, it just seemed fragile to manage the duplicates. But for something with so little churn, maybe that's not worth the hassle.

[lji-ilm]

@lji-ilm, I really wanted to avoid duplicating all the images as jpg's in the images repo, which was the reason to go to the trouble of converting them on the fly. In addition to the extra storage, it just seemed fragile to manage the duplicates. But for something with so little churn, maybe that's not worth the hassle.

hmm, in my mind it runs backwards; as what people eventually see on the website is the JPEG, some human eyes should QA the JPEG as the ground truth presentation -- it doesn't matter if the exr files was all correct but then imagemagick screwed up, right? The website is the final publication, and the publication need to look correct regardless of the technical tool generate it (and the source exr file is part of the "technical tools")

What i'm trying to say is that we should keep the website jpeg on the repo -- because the website editor (might be a non-technical professional editor) need to proof-read the jpegs and not relying on the supposed correctness of the source exr's data. They can be on a separate repo, tho.