[CMake] OO and/or IDEs
Brandon Van Every
bvanevery at gmail.com
Mon Dec 17 20:30:23 EST 2007
On Dec 16, 2007 2:55 PM, Brandon Van Every <bvanevery at gmail.com> wrote:
> On Dec 16, 2007 1:54 PM, Alexander Neundorf <a.neundorf-work at gmx.net> 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
More information about the CMake
mailing list