[CMake] OO and/or IDEs

[Brandon Van Every]

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