Hi Larry, On Thu, Apr 7, 2016 at 3:43 AM, Larry Gritz <[email protected]> wrote: > 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!
This is more or less the way I put mine together. I've done a little windows dev, but by no means have a lot of experience. I've found it surprisingly difficult to configure Travis and Appveyor, given what initially looks like extensive docs! Personally I'd be happy if they had definitive example configurations with all yml variables in a prototypical way, and skip the rest of the docs entirely. > 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. This is my goal too, with a side goal of providing installers for anyone who wants to track the bleeding edge on windows but doesn't want to build things. > 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. Good question. I definitely think there's value in a separate "meta build system" to build dependencies. Especially for projects which want to support windows, and for projects with unusual or bleeding edge dependencies. > 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)? IMHO there should be a meta build system which knows how to build all of the dependencies, except perhaps for ones which are very large and have standardized installers on all platforms (qt, boost?) I've had fairly good success with using cmake for this with ExternalProject.cmake. The only open example I've got of this is again in displaz, but for some closed source software I've used it for systems with some thirty dependencies or so. Here's the displaz example: https://github.com/c42f/displaz/blob/master/thirdparty/external/CMakeLists.txt With ExternalProject you should be able to have per-dependency flags to turn all dependencies on and off as desired. > 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? I've tried making it part of the main CMake. Unfortunately it doesn't work well - at least with ExternalProject_add() - because the meta build system has no knowledge of the targets in the third party build systems. To make matters worse, they're not built or installed at cmake time, so cmake can't figure out where the libraries and headers will be using the usual find_package infrastructure. > 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? Not sure about the advantages of this, I doubt it helps much unless you also intend to hack on the third party libs. ExternalProject.cmake can pull from repositories if required. > 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? None that I know about, I'd say the approach above is the least clunky thing I've found so far, but it's not perfect. Tracking dependencies between third party libs in the approach above can be a little fragile, but ExternalProject has the infrastructure to make it work if you're careful. If set up right, you can also have a properly parallel build of all the third party libs using make as the backend. This is really helpful if you've got a large list of dependencies. Cheers, ~Chris _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
