On 2016-09-23 15:30+0100 Tom Schoonjans wrote: > Hello once again, > > Travis-CI and Appveyor are not part of Github, but are separate companies in > their own right. They are just (popular) examples of companies that make use > of the webhook and integration possibilities that are offered by Github. A > list of similar companies can be found here: https://github.com/integrations > <https://github.com/integrations> > > To the best of my knowledge, most of these companies operate under a > financial model that includes free usage by open source projects, but paid > services for closed source projects (usually these are private repositories > on Github, but private hosting is also possible). Either way, their usage is > completely optional, though highly recommended. Even if one of these > continuous integration providers would go broke or cease to provide free > services for open source projects, there are alternative providers available, > or they can just be turned off and other testing options could be found. >
> If you would get [a cdash] server up and running, I am sure there are ways to have a webhook following a commit trigger a build. Good. > [out of order] I have to admit that my knowledge of CMake, CTest and CDash is > next to nothing (I am more of autotools kind of guy myself), but it looks promising. We are strong advocates for CMake and friends ever since we moved to CMake a decade ago from a pretty sophisticated autotools approach. However, I will attempt to avoid over-advocating CMake to you by confining myself to making the suggestion that you give it a serious try for one of your software projects to see how you like it for your build-system and test system needs. Note, with a bit of care in choosing template file names for configuration both CMake-based and autotools-based build systems can coexist for the same software project so you can directly compare the results of the two. When we did that for PLplot we started by simply building one of our minor libraries with CMake as a proof of concept and when that proved to be trivial everyone pitched in so that very quickly (a month or so in our spare time) we had implemented a complete CMake-based build system for all the large number of components of PLplot. And ctest soon followed. We ended up liking that build and test system so much that we quickly (within 6 months or so) abandoned our autotools-based build system as too much trouble to maintain. After that positive experience I have personally moved to CMake for all my other software projects as well, and I assume other PLplot developers have mostly done the same. Note, a decade-old build system normally accumulates a lot of cruft and PLplot is no exception in that regard. So reducing that cruft and also learning to take advantage of modern CMake facilities requires a substantial amount of on-going maintenance. But I am happy to do that maintenance because the result is a build system that is much more sophisticated and useful than what we created a decade ago which in turn was already a bit more sophisticated than what we could achieve with autotools at that time. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
