On 2016-05-13 09:10-0000 Wadud Miah wrote: > I honestly really despise CMake as it hides so many important flags. I know Autools has been around for some time, but I don't think there is anything wrong with it. I find it highly flexible, configurable and easy to use. If you could move PLplot to Autotools, that would be a big win :-)
Hi Wadud: I have to respond to your above negative reaction to CMake, but I will try to be gentle. :-) Also, I have decided to answer you on list because there is some background material here that some of our newer developers might not be aware of. To answer your specific concern and to also to publicize this extremely useful option for all developers on this list, CMake does hide information by default, but it is straightforward to obtain all flags that are used (at least for the "Unix Makefiles" generator that is default on Unix systems) by using the the VERBOSE=1 option on make, e.g., make VERBOSE=1 all when CMake is used to configure those Unix Makefiles. So the next time you are frustrated by cmake results that seem hidden from you, try that make option to see _exactly_ what is going on. Here is the longer story of our conversion from an autotools-based build system (ABBS) to a CMake-based build system (CBBS). I was the second-most active maintainer of our ABBS a decade ago, and at that time I was willing to struggle indefinitely with its many problems (e.g., different languages for different components of the system, very slow to configure and build, lots of cross-platform issues, and lots of consistency issues every time there was a new autotools release). However, I then read an article about KDE's conversion from autotools to CMake (motivated by all those autotools issues I mentioned above). That article demonstrated how the KDE developers all quickly fell in love with their new CBBS once they got a chance to play with it. So I started speculating on this mailing list about what might be possible with a CBBS for PLplot, and Rafael (Rafael Laboissiere was our chief Autotools guru) challenged me to "show him the code". I decided to give CMake a try myself for one minor PLplot library just as a proof-of-concept, and it was amazingly easy and fast compared to Autotools. IIRC, it took me only a few hours to understand the CMake syntax starting from scratch and implement that proof of concept. And the nice thing is that CBBS and ABBS can coexist (with some care about naming the supporting *.in configuration template files) so I could commit that working proof of concept CBBS without disrupting our ABBS. I then followed up in the next few weeks (with help especially from Arjen, Werner, and Andrew who were all enthusiastic about the potential of a CBBS) with adding the remaining PLplot components existing at that time to our CBBS. Understandably (since he had so much invested in our ABBS) Rafael was not willing to help develop that CBBS, but to his credit he did not blight my initial ideas by saying something like "I will never support that or go along with that". Instead, Rafael (rightly) got tired of the speculation about what _might_ be possible with CMake and challenged me to "show him the code". So I did, the advantages were immediately obvious to the rest of our developers, and within a year after that first proof of concept we were dropping our ABBS because Rafael did not have time/energy to keep up with what was possible with our CBBS. Of course, since then our CBBS has developed very far beyond what was possible with our ABBS a decade ago before we abandoned the ABBS approach. Of course, before 2006 or so virtually every open-source project had an ABBS and most still do because of inertia. That inertia is completely understanable since it is certainly a non-trivial amount of work to convert from an ABBS to a CBBS. Thus, if some Autotools guru is willing to do all that work necessary to support an ABBS, more power to him. But if cannot keep up with existing development or if developers are tired of issues with their ABBS, then they should consider implementing a CBBS. When they do make that large investment, they will be rarely disappointed since their new build system will typically be faster, will be much more powerful and flexible, will have better cross-platform support, and will be easier to maintain than the equivalent ABBS. 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. :-) 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
