[CMake] improve the CMake language?

[Gonzalo Garramuño]

Brandon Van Every wrote:
> 
> Is it worth trying to address these problems and make CMake a better
> scripting language? 

Yes, but currently as a low priority.  CMake first needs to have an 
extremely solid cross-compile toolchain and support as many systems as 
possible first without any major issues.
CMake is already very close to getting there.  I think in a year or so
this will be achieved without major issues.  Already the cmake2.5 
internals and fixes are way better than the 2.4 branch.

At that point it may indeed be worth forking cmake to improve or change
its language.

> 
> My concern is that if the status quo is maintained, CMake script will
> always be ugly to program with.  

Yes.  No doubt about that.  It is already uglier to program with than
most modern scripting languages.
Personally I think you need to see cmake as what it is: a tool to create
makefiles.  Not a scripting language.  If you are doing lots of file, 
regex or string manipulation... alarms should be going off.  You should 
probably write that as a small tool in ruby, perl or python and have 
cmake just call the command.

> This will put it at a disadvantage
> compared to build systems written in Python, Ruby, or Perl.  

Perl and TCL -- no.  Perl because of the sygils and bad OO.  TCL due to 
bad OO, brackets and weak regex.

Ruby?  Certainly.  Its metalanguage allows for the creation of a next 
generation make system.  But nobody is, afaik, actually working on one. 
  Most rubyists are happy with rake, which is only a very simple make 
system and does not take full advantage of ruby meta language strengths.

Python?  Probably, but use of parenthesis still remains more cumbersome 
than what it should be (not as bad as cmake, thou).

I do agree that sooner or later, the cmake macro language will become a 
disadvantage ( how soon?  who knows--- I give it 3 to 5 years or even 
more ).

The syntax of the language also will only matter when something matches 
cmake's features first.  In the short run, I'm unaware of anything that 
will be successful at this.

Currently all competing open source build systems are inferior feature
wise to cmake.  And cmake has had a lot more tuning in terms of properly
setting compiler flags than any other build system I've used.

Build systems built on top of scripting languages also suffer from being 
a tad bloated.  Unless you plan to use the scripting language later for 
something else, you end up installing tons of libs the build system 
probably never uses (networking, web, ssh, ftp, etc).

Another issue with other popular systems built on scripting languages is
that they usually try to replace not just a tool like 'cmake' or
'autotools' but they replace 'make' also.  Which is a neat idea, but 
also a potential mistake.  This often makes troubleshooting build 
problems harder, as the build systems internals are often not as well 
documented as the api.  One of the big strengths of cmake is that both 
the modules and the C++ is very readable.
When you replace make, developers only familiar with IDEs are completely 
left out, unlike a tool like cmake.

Another issue with scons, rake, etc. are that they are still slower than
cmake's approach.  For small projects, that may not matter, but today on 
large projects you still can notice.  Even a difference of 10 seconds 
adds up to a lot when you consider the hundreds of iterations a C/C++ 
project has to go through to reach a stable state.

The last headache with a build system built on top of a scripting
language is that as soon as a better language appears, the build system
may need to be rewritten or thrown out.

CMake may indeed eventually need to replace its macro language, but all 
the C++ core and platform specific stuff can always remain regardless of 
the user front-end.  And thankfully, cmake's internals are really very 
clean C++ code, so I am confident that even if Kitware were to refuse 
changing their language once lots of people start feeling the need for 
doing so, someone else can step up to the challenge.

 > I'm not just talking about SCons and so forth.

python scons, ruby's rake and jam are (currently) cmake's closest 
contenders.  But they are not good or comprehensive enough to 
distinguish themselves (yet, at least).
Python gives you a better language overall, but its syntax also gets in 
the way when writing rules.  Rake is usually better, but it is a very 
barebones make system (think cmake sans modules).

> we'll write our own
> custom build system in our favorite scripting language.  It happens in
> the game industry all the time.
> 

Does it?  I work in a related industry and I never heard of such.  Only
very large companies can afford that kind of luxury.

There usually is not enough time to create your build system.  And the
last thing you want is to then have to keep maintaining that build
system, which is something 5 to 30 developers will use and must always work.

That being said, the gaming industry is also mostly oriented towards one 
or two platforms, so the need for a comprehensive multiplatform system 
like cmake is also probably overkill.


-- 
Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy