[CMake] OO and/or IDEs
On Dec 16, 2007 2:55 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > On Dec 16, 2007 1:54 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > On Sunday 16 December 2007, Brandon Van Every wrote: > > > > > > Meanwhile I just keep expanding my search radius, asking various build > > > system communities "the OO question." > > > > What's the purpose ? > > CMake is kind-of going OO. > > The purpose is to understand what benefits OO has, if any, for build > systems. Then to understand whether Lua, Python, or Ruby offer those > benefits. Then to understand whether CMake "kinda implementing > something like OO" also provides those benefits. Possible futures for > build systems in general: > > 1) OO approaches really don't matter. "Make"-style tools were the > right way to do things all along. In industrial practice, nobody ever > moves away from Make, because the industrial continuity of Make-style > development is paramount over any marginal benefit that OO provides. > > 2) OO approaches do prove to matter in some arenas. Perhaps > integration with IDEs or XML or some such, as the Waf author seems to > think? Or whatever. Make-style systems and OO systems exist side by > side, each in their own areas of greatest applicability. > > 3) OO approaches prove to matter greatly as software reaches a certain > level of complexity. Industry moves en masse to OO build systems, > retiring their 1990s legacy Make systems. > > Which future do you think it will be? If you assume (1), then in 10 > years you could get left behind. So my goal is not to assume, but to > go out there and understand. Alternately, if (1) really is the > future, we can learn how to make CMake be the best possible (1). We > should not, however, assume that we're great and that everyone who's > trying something else is dumb. Possibility (4) has occurred to me. The OO question, and the somewhat related "syntax nicety / maturity" question, may not be nearly as important as supporting the correct IDEs well. For instance, Eclipse. In that world view, the choice of extension language(s) is a political decision, not a technical one. When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake. And so on for PHP, Python, etc. For any given implementation language, there's not a lot of variety. Maven 2 seems to have deliberately excluded itself from the "make-like tool" category, so that will be the subject of another post. Anyways; political decisions for supporting Eclipse. How do you avoid offending a Java programmer? Well, if you're not going to write anything in Java, perhaps there is no way. Perhaps instead you cast your lot with the C/C++ Eclipse users and support it that way. Which makes scripting languages moot / orthogonal / detrimental? Or maybe you look to see whether Python, Ruby, or Lua is winning the Eclipse support wars. If none of those are winning, perhaps you wait for a winner to emerge before committing. It doesn't always pay to be in the vanguard of capabilities. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On 2007-12-17 20:30-0500 Brandon Van Every wrote: When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake. Correction about Autoconf with some additional comments about autotools. Autoconf requires m4 and shell scripting (both of which are exposed to the user), automake requires perl (hidden from the user with the public interface a unique extension of make), libtool is implemented as a giant (and slow!) shell script with a small number of command-line options for that shell script. autotools tries to use the lowest common denominator of all make systems so it will work on any Unix platform rather than the unique capabilities of native make systems such as GNU make. In sum, as virtually everyone on the Linux side of things realizes by now, autotools is a technical mess. BUT autotools were first to market in the Linux world so there are still a large number of Linux projects that continue with autotools. However, my guess based on obvious technical superiority, the possibility of porting to windows (not all Linux projects are like Chicken!), and the huge advertisement the KDE adoption gave to CMake is that the current CMake share of Linux projects is strongly growing at the expense of autotools. Furthermore, it is obvious from traffic on this list that a large and growing number of windows projects are beginning to use CMake as well. Brandon, because of this strong growth, I disagree with your emphasis on the importance of strategic decisions now for CMake. Those were done a long time ago, and people and projects are strongly voting with their feet despite (and this is an extremely important consideration) virtually everybody absolutely hating to change build systems. So long as the CMake developers steer a steady course and don't shoot themselves in the foot with some stupid decision, their strong growth will continue, and as a result I think they we be _the_ major build system in the decades to come. Thus, my own feeling is CMake developers and users can quit worrying about market share since the future is bright indeed on that score almost regardless of what they do. Instead, they should totally concentrate on technical improvements that don't disturb things too much and which make CMake build systems simply easier to design and maintain. I am talking about such things as cross-compiling, module improvements (including standardization), scoping, improved regex, and even Boolean precedence. The first three are already in the CVS version of CMake and the rest have been recently discussed positively on list with at least a chance to get into CVS. In sum, the CMake developers have something they can be proud of, that pride will continue to drive them to make some modest improvements like listed above, and so long as they don't make any irrevocable mistakes in such changes their current large growth rate assures them of world domination for both Linux and windows build systems. :-) Just my $0.02. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 10:35 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > > BUT autotools were first to market in the Linux world so there are still a > large number of Linux projects that continue with autotools. However, my > guess based on obvious technical superiority, the possibility of porting to > windows (not all Linux projects are like Chicken!), and the huge > advertisement the KDE adoption gave to CMake is that the current CMake share > of Linux projects is strongly growing at the expense of autotools. Plus, if I had a better pattern matching technology and another 6 months of either willpower or funding, I could implement completely automagical conversion from GNU Autoconf + GMake to CMake. Including the nasty awk + grep + egrep + sed tools that Unixen like to use. Haven't decided if I really want to take it on though. I need the better pattern matching technology. > Brandon, because of this strong growth, I disagree with your emphasis on the > importance of strategic decisions now for CMake. Those were done a long > time ago, and people and projects are strongly voting with their feet > despite (and this is an extremely important consideration) virtually > everybody absolutely hating to change build systems. So long as the CMake > developers steer a steady course and don't shoot themselves in the foot with > some stupid decision, their strong growth will continue, and as a result I > think they we be _the_ major build system in the decades to come. I'm not that bullish. I live in a Windows + console game development universe where plenty of people try out CMake and tell me it sucks. Not necessarily for well-measured reasons, but initial impressions do count. A lot of these people end up rolling their own because custom-built NIH is endemic to the game industry. I think it has to do with game projects not lasting long enough to be reused. There's a huge burnout rate for game developers, with entire programming and art teams getting swapped mid-project. So nobody knows what's going on, nobody likes what was done before, and projects tend to be rewritten from scratch. I also don't see how you could read all those articles I just posted, and assume that CMake is going to sweep the table in decades to come. A far more likely scenario is some Java or C# technology spills over into the C/C++ universe and becomes a checkbox item. > Thus, my own feeling is CMake developers and users can quit worrying about > market share since the future is bright indeed on that score almost > regardless of what they do. Instead, they should totally concentrate on > technical improvements that don't disturb things too much and which make > CMake build systems simply easier to design and maintain. I guess you have no fear of a Disruptive Technology biting you in the ass. http://en.wikipedia.org/wiki/Disruptive_technology I prefer to keep my eye on the 8-ball. http://web.ics.purdue.edu/~ssanty/cgi-bin/eightball.cgi Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 11:02 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > I guess you have no fear of a Disruptive Technology biting you in the ass. > http://en.wikipedia.org/wiki/Disruptive_technology > I prefer to keep my eye on the 8-ball. > http://web.ics.purdue.edu/~ssanty/cgi-bin/eightball.cgi Related to "Disruptive Technology" is Kuhn's concept of a "Paradigm Shift." http://en.wikipedia.org/wiki/Paradigm_shift I find the following passage compelling with respect to "young bucks," who haven't necessarily grown up with "crappy" make tools, plain C, or even C++. "Sometimes the convincing force is just time itself and the human toll it takes, Kuhn said, using a quote from Max Planck: "a new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."" Technology generations in computerdom are capable of being exceedingly long or exceedingly short. It really depends. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On 2007-12-17 23:02-0500 Brandon Van Every wrote: I guess you have no fear of a Disruptive Technology biting you in the ass. That is correct. Disruptive technology by definition is overwhelmingly superior, and I like such technology and don't fear it in the least. Also, I am comfortable with change so therefore I tend to be an early adopter of disruptive technology. But life is short so I don't adopt new technology unless there is a real and overwhelming case (not just marketspeak) that it is _much_ better than what I am using. For me, CMake was disruptive technology (overwhelmingly superior) compared to autotools, and therefore it was a no-brainer decision for me because of my comfort with change. If/when I adopt my next build system it must be similarly overwhelmingly superior to CMake. But right now, I am pretty satisfied with CMake and cannot imagine when the next build-system revolution will strike. Some here have guessed three years, but my own feeling is it will be _much_ longer. Anyhow, changing your strategy to deal with disruptive technological changes is a waste of time at best; by definition disruptive technology changes are extremely hard to predict and therefore there is no change in strategy that will stop them. OTOH, discussing possible incremental changes to CMake such as improved regex is well worthwhile because of better service to users and the pride that goes with that. But I don't think such changes are going to affect when the CMake tipping point occurs. I think that tipping point has already happened based on the rate of CMake adoption in a software area (build systems) where everybody ordinarily dislikes change. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 10:35 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > people and projects are strongly voting with their feet > despite (and this is an extremely important consideration) virtually > everybody absolutely hating to change build systems. Here, I think it's more important to concentrate on the lifecycle of build systems, rather than people's emotions about them. The vast majority of software developers don't like build systems no matter what stage of the lifecycle they're at. Most engineers want the build to go away. They don't think it's real code, they think it's pure overhead. They resent having to maintain it. Only when the complexity of their business gets to a certain point, and the inevitable relationship between their build system and their profitability emerges, do they grudgingly take steps to address it. Then after cutting off their fingers some more with half-measures, they grudgingly hire a dedicated build engineer. If a software project continues to grow in complexity and requirements, the build dies. Then there's a (forced) opportunity to replace it with something better. As builds die, engineers look at the available products and decide what the next build is going to be. They may choose something incrementally conservative, i.e. CMake over GNU Automake, which are broadly of the same style. Or they may choose something "apparently cutting edge," if they think it may give them a competitive advantage. Or if the risk is manageable, i.e. they can afford to change their minds again, if the new build doesn't work out. I don't take it as a given that CMake will inherit all GNU Autoconf / GMake projects. Especially not indefinitely, as the next 10 years unfold. It's important to look at competitors and determine what engineers think is attractive in a build tool. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 11:51 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > On 2007-12-17 23:02-0500 Brandon Van Every wrote: > > > I guess you have no fear of a Disruptive Technology biting you in the ass. > > That is correct. Disruptive technology by definition is overwhelmingly > superior, I'm not sure you read the Wikipedia link I provided. See the description of "low-end disruption." That corresponds to all those guys out there rolling up things like Waf and Premake. Things we laugh at now, but may not be laughing at later. Some of those low-end things like JRake are even getting traction. There's a constellation of blog entries about them. It performs significant work despite not having 51 person-years into it. > But right now, I am pretty satisfied with CMake and cannot imagine > when the next build-system revolution will strike. Whereas I can, and have been providing you with articles about it from the Java universe. > Anyhow, changing your strategy to deal with disruptive technological changes > is a waste of time at best; by definition disruptive technology changes are > extremely hard to predict They're even harder to predict if you're unwilling to pay attention to competitors and notice the facts on the ground. > OTOH, discussing possible incremental changes to CMake such as improved > regex is well worthwhile because of better service to users Not much to discuss. It's already to the point of action. :-) I don't have anything against "low hanging fruit." Despite Bill's misgivings about CMake "competing with Python / Ruby / Perl," beefing up CMake with PCRE and a few more string processing routines is an obvious and easy improvement to the product. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 18, 2007 12:42 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > Some of those low-end > things like JRake are even getting traction. There's a constellation > of blog entries about them. It performs significant work despite not > having 51 person-years into it. It occurs to me that Java and C# do not have the same portability problems as C/C++. Sure, Java has some, but any Java-oriented build system can rely on Java being nearly the same on all platforms. Meanwhile, C# is primarily a Windows thing. Hmm, what aspects of target OSes do Java and C# fail to pave over? If CMake handles those better than competing build systems Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
Quoting Brandon Van Every <[EMAIL PROTECTED]>: beefing up CMake with PCRE and a few more string processing routines is an obvious and easy improvement to the product. I'm working on that, by the way. PCREs have been actually easy to implement, including your wishes about outputting the matches directly to variables instead of using REGEX_REPLACE (PCRE_REPLACE in our case), etc. I also took a look at the IF command implementation and I'm going to implement PCREs there, too: IF(variable PCRE_MATCHES pcre_regex) / IF(string PCRE_MATCHES pcre_regex). The most difficult part is understanding the really odd (at least to me) behavior of REGEX_MATCH and REGEX_REPLACE in current CMake (I'd like PCRE to mimic as much as possible). There is one thing which discourages me, though: nobody from Kitware commented on the interest of PCREs, what the "deadline" for PCREs to be included in CMake 2.6.0 would be, nothing. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Tuesday 18 December 2007, Pau Garcia i Quiles wrote: ... > There is one thing which discourages me, though: nobody from Kitware > commented on the interest of PCREs, what the "deadline" for PCREs to > be included in CMake 2.6.0 would be, nothing. I think one requirement would be that the pcre library is added under CMake/Utilities/ and converted to build with cmake. Kitware has the policy to have no extra dependencies for building cmake except a C++ compiler with STL. (ccmake etc. are optional). It's BSD licensed, that's good. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
Quoting Alexander Neundorf <[EMAIL PROTECTED]>: On Tuesday 18 December 2007, Pau Garcia i Quiles wrote: ... There is one thing which discourages me, though: nobody from Kitware commented on the interest of PCREs, what the "deadline" for PCREs to be included in CMake 2.6.0 would be, nothing. I think one requirement would be that the pcre library is added under CMake/Utilities/ and converted to build with cmake. Kitware has the policy to have no extra dependencies for building cmake except a C++ compiler with STL. (ccmake etc. are optional). It's BSD licensed, that's good. I already have PCRE 7.4 under CMake/Utilities here and it builds using CMake. It was cmake-ified by Christian Ehrlicher from KDE4 on Windows fame. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
