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
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to