Re: [Plplot-general] Nightly testing?

[Alan W. I. <ir...@be...>]

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
__________________________