Thanks, Chris! As kind of a tinkering background project, I have been trying to cobble together an appveyor.yml for OIIO, taking small steps when I get the chance. I'm really inexperienced with Windows dev, so I've done it by trial and error and a lot of google searching for other projects' appveyor files. So I appreciate one more clean example!
The current status is that I've got it installing all of the required and a few of the optional dependencies, and compiling most of the OIIO source code, but it's hitting errors upon linking that are definitely beyond my ability to understand. My goal is that in the coming days (maybe over the weekend if I get time), cleaning up what I have and posting a PR for it, hoping that it will be obvious to other onlookers (with more Windows and/or Appveyor experience) what I should do next to fix the remaining problems. The end goal, of course, is to add Windows to our CI regime so that we never again check in a change that breaks the build on any of the platforms. I'm already finding TravisCI indispensable to my development practice, and the lack of similar confidence check on Windows bugs me. While I have you... I'm curious on your (and others') opinions on another related matter. I want to make it super easy for people to build the software and not have the dependencies be a hassle. Setting up the TravisCI builds (which need to download and build most of the dependencies on the fly) takes a couple big steps in the direction of a "make dependencies" one-step process. But I'm not sure how the final form of it should be organized. Should we have separate options for "build nothing, just use what's on the system", and "see what's on the system, use what's available, download and build the rest"? Should the latter be further bifurcated into "download and build missing essentials" versus "download and build everything missing?" Should there be an option to download and build dependencies that *are* on the system (maybe you want to force a build of a more modern version, or experiment with a different set of compiler flags?), and if so, should you be able to decide that on a package-by-package basis? Should it (for all, or for packages individually) offer a choice of building from source or installing a compiled package (e.g., homebrew or apt-get or whatever)? Should the dependency setup be invoked as a separate script (bash or whatever is appropriate for each major system)? Or should it happen as part of the CMake build or as part of the make wrapper that some of us use? Is there any advantage to having the dependent projects be set up as git submodules, or is that pointless and they should just be 'svn co' or 'git clone' on demand into a temp directory, if they are needed? Is there a project with lots of dependencies that people feel have done all this in "the right way" that we should use as the model for our approach? > On Apr 6, 2016, at 5:53 AM, Chris Foster <[email protected]> wrote: > > Hey guys, > > I just noticed that someone (presumably Larry...) enabled appveyor on > the OpenImageIO github account. I very recently set it up for my > project displaz which uses a similar set of libraries etc, and it's > really nice. Feel free to steal some of the config or ask questions > if you like. Current config: > > https://github.com/c42f/displaz/blob/master/appveyor.yml > > I hadn't used the visual studio project cmake generator before, but I > found it by far the easiest to work with on appveyor, along with > `cmake --build` to abstract the msbuild details. > > Cheers, > ~Chris > -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
