Hi,
your experiences match mine exactly. Setting up build dependencies often is an incredibly tedious and long process (not just for OIIO). This is why I developed the desire to have it automated so that it becomes a documented and repeatable process for my projects. The fact that the output of different C++ compiler versions on Windows is by default incompatible means that providing pre-built binaries is a daunting task. Just supporting GCC, VS2012, VS2013 and VS2015 would mean making up to 16 different builds of everything, if I count correctly (32 bit / 64 bit, debug / release, 4 compilers). And no sharing of build scripts between compilers, of course! I have not yet figured out exactly how conan should be used. Do you absolutely have to integrate conan into your build scripts, that is, do you need to turn it into one more mandatory dependency with all the conventions (local caches, temporary directories in user profile...) it brings to the table? Is there an easy way to keep conan optional? I guess I'd like to keep the option of building OpenImageIO without needing conan, even if it means wrangling all the dependencies myself. Regards, Gregor ________________________________ From: Oiio-dev <[email protected]> on behalf of Simon Smith <[email protected]> Sent: 05 January 2017 10:43 To: OpenImageIO developers Subject: Re: [Oiio-dev] Easier Windows builds Hi, We’ve been using OIIO for a few years now under windows, linux, and OSX and having not used cmake before all this the whole process was quite “alien” to me (as a previously Windows only developer) and I’d like to think that I’m a pretty standard Windows developer so this should be applicable to others. The assumption that there was a simple solution that didn’t involve too much understanding was quickly thwarted! Now I understand more about cmake, dependencies, compilers etc things are clearer so I wanted to share my experiences with Windows. This won’t answer “which alternative to use” as I don’t know - I just worked it all out manually with what is out there now - but I’m hoping it might shed light on the issues we are looking at. First off, one size doesn’t fit all when it comes to cross platform development - I don’t personally think there is a simple perfect solution, but I do think that you can get 95% of the way there, with the last 5% being down to your own local requirements. We have a shared area where all dependencies are held across all platforms. In here we hold all the libraries and headers for debug, release, and relwithdebug for use with specific visual studio (as well as clang/gcc/whatever) compilers. This folder structure can either be zipped up and shared around or placed on a shared drive for all developers to use. I’m pretty sure this is common as I don’t want all my developers compiling the dependencies! To that end, this complicates deployment as some libraries aren’t built for this sort of deployment and assume you are installing onto the build machine so manual steps are always needed. The main thing Windows developers need to understand (and often this is hidden away from them) is that you have to build everything you need to use yourself with the same compiler that you are going to use for the final application. That might be VisualStudio 2012, or 2015, or even 2009. Sometimes you get away with not doing this, but it’s safer to assume that you aren’t in my experience! Now things are moving to c+11 as a minimum requirement this becomes more important. We also use Qt and that is shifting its requirements too. As soon as one of your application dependencies requires a certain compiler, everything you link against needs updating to be compiled with that new minimum requirement. As already mentioned by others, it’s the building of all the dependencies is a pain :( - Some libraries need files manually editing to get them to build correctly for windows as well as specific debug/release builds. - Not all use cmake with its install_prefix, so you have to extract the built libs yourself and copy into your deployment area. - Some you have to run multiple cmake sessions on to generate projects that correctly link to debug as well as release libraries (i.e., they only allow you specify one library rather than ones for debug and release). All of this is doable, and I’ve done it many times, but I always have to come back to my notes to get things working. To do all 3 build types on 3 platforms takes time … a lot of it … to get all 3 platforms up to speed with new compilers can take me days to complete :( What I would like to have in a perfect world is being able to address the following things: 1) All dependent projects can be generated from cmake into debug, release, and relwith debug projects within a VS solution. 2) There are cmake install-prefix paths for the 3 configurations, or different configurations can be “decorated” with compiler, debug/release, version information. 3) cmake is actually able to search and find the dependencies easily. (1) Is a pipe dream unless all dependencies are updated for us! Once they are in VS solutions though building them is easy as you are in “familiar territory”. (2) This is where a lot of the manual moving of libs comes in for me and where I can’t kick of the 3 builds and leave it to it. Boost does a really great job with its naming convention (when you know how to set). Ideally I want to be able to build debug, release, then relwithdebug, go into the build directories and scoop out the files in one go (or just point them all to the desired destination first time around!) (3) This stuff rarely works for me. It takes ages setting them all up and is the most tedious part of things. I think this is down to how we keep our dependencies stored as mentioned at the top of this email. I have been meaning to write up my notes on getting Windows to work with just Visual Studio, the source archives for all dependencies, and CMake to generate the project files to then build. I’d like to think it would be of help to others and give something back to the community but have never had the time to do so properly - as is the pressures of work time! One thing I can say is that each time I do this, rebuilding of OIIO does get better - all the small changes that have gone in over time are really, really appreciated! It also helps when some libraries rarely change so it’s just when you have to update compilers that these need revisiting. Whatever solution is taken in the end, these are the issues that it would personally need to address for it to be a “better” solution that it is now - and I’d like to think that my position is fairly “common” … maybe :) Best Regards, Simon --- Simon C Smith Co-Founder & CTO www.lightmap.co.uk<http://www.lightmap.co.uk> Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. On 3 Jan 2017, at 22:35, Robert Matusewicz <[email protected]<mailto:[email protected]>> wrote: Hi, I'm not really a Windows stakeholder, but want to give my voice for Conan as it looks very reasonable. The PR I raised on github was the result of quick-play with Conan to see how it fits and how easy is to integrate with cmake and I really was impressed by it. The pros of Conan are: - easy installation, one click in Windows. Can be installed with pip - CMake integration - just add a conanfile.txt with the description of packages that are required and include conan generated cmake file and it's done (in theory). Some packages are provided with FindXXX.cmake file that take into account some conan-specific info during library search (like name of the library that may be non-standard due to storing libraries for multiple configurations: MT, MTd, MD, static, dynamic, etc - cmake can automatically run 'conan install' - conanfile.txt can be versioned and is easy to read - support for multiple compiles, so (in theory) can be used with VS, clang, gcc (didn't tested that yet, will try to test that this week) - multi-configuration support: release vs debug, different runtime version, different architectures There are of course some cons of that package manager like: - not package signing yet (https://github.com/conan-io/conan/issues/773) - some libraries are not present in the repository and should be packaged first - not all packaged provides custom FindXXX.cmake files and due to that cmake have sometimes problem with finding conan-provided libraries Cheers Robert 2016-12-31 5:28 GMT+00:00 Larry Gritz <[email protected]<mailto:[email protected]>>: Brainstorm time... It continues to be difficult, especially for newbies, to build OIIO from scratch on Windows. Building the dependencies are a big part of the hassle. This is exacerbated by my lack of experience with and access to a Windows machine (though I did manage to eke out an Appveyor build script, which despite being very clunky has drastically cut down the frequency with which I break the build on Windows). Robert has proposed enhancements that allow a build of many critical dependencies using Conan (https://conan.io/) here in this PR: https://github.com/OpenImageIO/oiio/pull/1593 I want to put that PR on hold slightly to allow for wider discussion here of the alternatives, so that we can collectively decide the best way to achieve this. (And by "we", I mean consensus of the stakeholders who depend on Windows builds and know more than I do about how to achieve it. I think the two goals, which may or may not have identical solutions, are: (a) for people who need to use OIIO source code (for example, developers/contributors) to have an easy way to get/install OIIO's build-time dependencies; and (b) for people who only need OIIO binaries and libraries to be able to install both the dependencies and OIIO itself as easily as possible (ideally just binaries, or if from source, then as close as possible to a foolproof one-command download, build, and install of everything). Possible systems/strategies include: https://conan.io/ Conan package manager https://github.com/Microsoft/vcpkg Microsoft Vcpkg https://github.com/meshula/mkvfx Nick Porcino's "mkvfx" project Are there others to also consider? Maybe take a look at all of these and see what you guys think about the relative merits of supporting/using one or more of them as our strategy for easier OIIO builds and dependency installation? -- Larry Gritz [email protected]<mailto:[email protected]> _______________________________________________ Oiio-dev mailing list [email protected]<mailto:[email protected]> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- My public key can be found at https://keyserver2.pgp.com<https://keyserver2.pgp.com/> _______________________________________________ Oiio-dev mailing list [email protected]<mailto:[email protected]> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
