On Fri, Aug 12, 2016 at 4:58 PM, Roger Leigh <rle...@codelibre.net> wrote: > You can simplify this to two steps: > > 1. Clone the superbuild repository > 2. Build the third-party and first-party packages > > This is the approach we take with the OME super-build > https://github.com/ome/ome-cmake-superbuild/ > > See the packages in > https://github.com/ome/ome-cmake-superbuild/tree/develop/packages > all the ones with an "ome-" prefix are the first-party libraries; > everything else is third-party. They are all external projects. > > We have cmake options to select all packages, first-party packages only or > select individual packages by hand; the recursive dependency resolution will > add/ignore dependencies depending upon the chosen policy (defaulting to > include third-party dependencies). So when you're building on BSD or Linux, > you can say "no third-party dependencies except for gtest", or choose > everything, and on Windows where there is no package manager, you always > build everything. And on Windows you can build just the dependencies and > reuse them later; it has support for using cached builds which we use on the > CI side to cut down build times; we only rebuild the cache when the > superbuild git tree hash changes; see the scripts/jenkins-build script > > In addition to that, we have the means to build the first-party libraries in > different ways > > 1. From source release tarball (last stable release) > 2. From git (specify remote+branch as cmake options) > 3. From a local git checkout (on whatever branch is currently checked out) > > You can see the selection logic here: > https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L4 > > In practice (1) is for end-users to build the whole thing, and (3) is what I > use in practice to develop locally where I have a full set of git repos > checked out locally, and I tell the superbuild to build them, along with all > the third-party deps; (3) is also what we use on the CI system, with jenkins > cloning all the individual repos into the workspace, then doing pretty much > the same thing. (2) is OK for one-off builds, but the need for a full git > clone for every package is too much for routine use > > And you can see how first- and third-party dependencies are handled here: > https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L48 > > I might rearrange that so that the classification is in the dependency > rather than the dependeee later on though. It kind of evolved this way as > we added additional features and needs a little cleanup to make it perfect. > > Everything in the above repository is BSD licensed, so feel free to use it > for inspiration or take what you like. The main point I wanted to make was > that with the superbuild *everything* can be an external project, including > your own code. And from that point you can add in features like being able > to selectively build just the third-party or just your own code, rather than > forcing them to be separate manual steps.
I get where you are going with this, but I don't really think our code base would benefit from treating third party and first party libraries the same in CMake. We can't really use our different libraries in isolation anyway, mostly due to a combination of architectural issues and business logic. Also I have to do some custom target stuff to pull everything together for our Android APK build (our product is targeted for Android platform). I have to do a lot of trickery to integrate with ant to make our builds seamless between java & C++. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
