Windows and Documentation

[MikePelton]

So the very good news is, on Windows at least, we can now build Theia (0.7 for now) with VCPKG. The next challenge is that the Theia doc doesn't get built. It's in the repo as a bunch of RST files, so in a Python world you'd build those with Sphinx and DocUtils. If Python isn't part of your world, you wind up needing to install boatloads of stuff just to get the doc built, which is nuts. Can I ask someone who's at home in Python land to build the doc as HTML and puts that in this repo too please? Thanks in advance, Mike

[MikePelton]

This has become an Ubuntu noob question now... Abandoning the Windows implementation and now building under 18.04. Have ticked the BUILD_DOC and BUILD_DOCUMENTATION flags in CMake GUI, but where does the generated html documentation get put?

[MikePelton]

Looping back on the Windows question, running 0.7 under Windows I saw a number of run-time errors that had all the hallmarks of DLL's being built with different run-time C libraries, which is hard to do in Linux but easy enough under Windows. In build_reconstruction, Any call into OpenImageIO for instance would crash, as the constructor for image_buffer that takes a const std::string reference passes the data() pointer directly off the reference into local storage, but at that point the pointer's meaningless - the memory spaces are different. Passing the .c_str() off the std::string into image_buffer goes through a different constructor and presumably passes by value, so that survives the journey over the fence into the DLL. Similarly in extract_features vl_malloc is called before the vl_state has been set up - this would seem to be relying on the order of instantiation of statics which is always the kiss of death to portability. I wouldn't for a second diminish Chris's phenomenal effort in getting all this together - Windows was never on the agenda and the VCPKG guys (in this instance) have some fixing to do, but unless you're patient and/or well funded I'd give the Windows builds a wide berth. As always, I'd be delighted to be proved wrong.

[sweeneychris]

Hi Mike, The documentation should be generated under the docs/ directory (I think it is docs/html?). If it's not generated right in the source, then check around in your cmake build folder as well. Sorry, it's been a while since I generated the docs that way :/ Regarding Windows -- yes, I totally acknowledge that Theia is not at all set up for Windows. I've worked with some folks in the community to make it more friendly to windows, but since I don't have any windows machine and generally haven't developed for that platform I don't have much of a mechanism to test it easily. If you have fixes that can help improve the build for windows I'm happy to accept PRs! And yes, OpenImageIO has been an unintended nightmare for many. I was frustrated with using CImg previously, but honestly it seems that CImg would be better than OpenImageIO in hindsight.

…

On Tue, Jan 22, 2019 at 1:25 AM MikePelton ***@***.***> wrote: Looping back on the Windows question, running 0.7 under Windows I saw a number of run-time errors that had all the hallmarks of DLL's being built with different run-time C libraries, which is hard to do in Linux but easy enough under Windows. In build_reconstruction, Any call into OpenImageIO for instance would crash, as the constructor for image_buffer that takes a const std::string reference passes the data() pointer directly off the reference into local storage, but at that point the pointer's meaningless - the memory spaces are different. Passing the .c_str() off the std::string into image_buffer goes through a different constructor and presumably passes by value, so that survives the journey over the fence into the DLL. Similarly in extract_features vl_malloc is called before the vl_state has been set up - this would seem to be relying on the order of instantiation of statics which is always the kiss of death to portability. I wouldn't for a second diminish Chris's phenomenal effort in getting all this together - Windows was never on the agenda and the VCPKG guys (in this instance) have some fixing to do, but unless you're patient and/or well funded I'd give the Windows builds a wide berth. As always, I'd be delighted to be proved wrong. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#232 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwytti39BFLnXgtD4Haxdja4-JGLaESks5vFtjzgaJpZM4Z5kwk> .