As a user, I loved the ABBS since for unix-ish systems it would largely "just work".
However, there are two problems that I consistently ran into: * autotools doesn't work on windows due to unix-ish requirements * I could never understand autotools enough to use them myself From that point of view, Cmake is young but clean. Initially, it was awkward to run but things are getting better. In my experience, the main issues now are of maturity in that when cmake doesn't correctly detect things then often the build breaks and it is up to the end-user (not necessarily a guru) to figure out the mystical arguments to make things work. It is informative that you can use VERBOSE=1 to debug the problem oneself (I'll have to give that a try) but it is even better if the build process had clear diagnostics on what exactly the failure is and how to fix the problem as a package builder/consumer. In addition, there is the usual confusion of build processes for cygwin platforms but since the cmake process is compiler specific, the correct use for windows vs cygwin is a matter of the build scripts and not the fault of cmake. --Chris On 5/13/2016 18:28, Alan W. Irwin wrote: > On 2016-05-13 12:58-0700 Alan W. Irwin wrote: > >> To summarize, your suggestion to move back to an ABBS has fallen on >> somewhat stony soil. :-) The reason for that is we had a chance to do >> a head-to-head comparison between a new CBBS that had been developed >> for a month or so and an ABBS alternative that had been developed for >> many years, and there was absolutely no contest. So I would >> encourage you to give CMake a second chance especially now that you >> know about that VERBOSE=1 option. :-) > More general points concerning PLplot and CMake. Since 2006, the > open-source (OSI-approved BSD 3-clause License) CMake code that is > written in C++ has attracted a large band of volunteer developers who > are lead by CMake code gurus from KitWare such as Brad King. As a > result there has been extremely strong development of CMake in the > last decade. > > All this development of CMake itself has occurred in a way that was > backwards compatible for the CMake-2 series of releases. Some > well-publicized backwards incompatiblities (most of which had long > been deprecated) were introduced for CMake-3 which was a substantial > rewrite of CMake-2. The series of CMake-3 releases has also been > backwards compatible within the series. So that is a great boon to a > mature project that is not being actively developed because that > project's build system "just works" regardless of CMake-3 version. > > That said, the early releases of the CMake-3 had a number of bugs > introduced by that rewrite that had to be flushed out by user testing > so I strongly recommend using the highest version possible of CMake-3 > (currently 3.5.2 which works fine for me on Linux). Also, I continue > to develop the PLplot CBBS to support any new directions that PLplot > development takes and to make our build system easier to maintain. > > With regard to that maintainability point, I try to replace use of > CMake features that have become officially deprecated or which are > advertised as problematic in the CMake-3 series with improved CMake-3 > logic that has become available. However, I do that in a conservative > way so that our build system continues to work for CMake-3.0.2. That > is the minimum CMake version we allow on Linux to support such > distributions as Debian jessie where 3.0.2 is the latest version of > CMake that is available. (Note, the minimum version of CMake I have > adopted for all non-Linux operating systems is currently 3.3.2, but > that will likely get bumped just as soon as both the Cygwin and > MinGW-w64/MSYS2 distributions provide a binary package for a later > version of CMake. > > To summarize, I have pretty much become the "CMake guru" for this > project, but it is not that much of a burden so I feel confident that > when I retire from PLplot someone else will be able to continue > developing our CBBS without many issues with the same motivations as > above (support new PLplot development and improve maintainability of > our CBBS). Or if some keener wants to try some other build system that > does not interfere with our CBBS, I will probably be too invested in > our CBBS to help with development of that additional build system, but > I do intend to follow Rafael's good example, and challenge that person > to "show me the code" since sometimes great things (such as our > present CBBS) happen as a result of such challenges. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
