Slashdot Mirror
CML2 Coming in Kernel 2.5
MrHat writes: "Eric S. Raymond's CML2, or 'Configuration Menu Language' -- part of the next-generation Linux kernel build system -- is now officially ready for 2.5. CML2 includes a compiler for a domain-specific configuration language, used to configure kernel subsystems and resolve dependencies between them. CML2 and Linux 2.5 will 'ship' with several different configuration interfaces, including an adventure game, whipped up by ESR during an extended flight. The story from the horse's mouth (or LKML, if you prefer):'This release resolves all known logic bugs and rulebase problems. The only things left on the to-do list are convenience features and some minor improvements in the test/coverage tools. This code is now officially ready for the 2.5 fork.'"
The other examples posted on ESR's page are for kernel-oriented projects. How hard is it to stick this in another project? Something slightly smaller-scale than the kernel?
Also, this seems to only be concerned with compilation-time configuration. Although pre-compilation config is important, how hard is it to adapt this to work after compilation? If another app could use this configuration engine after it's been compiled and distributed, it may make it easier to customize pre-compiled packages (RPMs, DEBs, etc).
I can't say that I don't give a fuck. I've just run out of fuck to give.
I read the article and I was immediately impressed at how much MORE readable CML1 was... Perhaps because I know enough shell scripting to follow it in my head. CLM2 was impossible for me to quickly follow what was going on and I had to think about it quite a bit more.
I think the basic idea of CLM2 remains sound, but I wonder if it will result in more "cutting and pasting" rather than direct editing...
LedgerSMB: Open source Accounting/ERP
It's good to see some high profile hackers putting their minds to making GNU/Linux easier for people. This language should make it easier for hackers to fiddle with their kernel, and to get into kernel hacking, which is a great thing considering how daunting a challenge it is at the moment. It will also help people who have been playing with GNU/Linux for a short while start setting their systems up properly, instead of running on a hastily preconfigured kernel that came from their distribution installer.
It was promising then to see ESR say that he wanted this language to help GNU/Linux newbies. There's been a lot of good work recently on making the first steps more accessible, but there's been little progress in helping people who have completed the first challenge and who then want to get their OS running smoothly.
While Adventure is amusing, a Nethack/Angband-style configuration could be far more useful. The same room/object analogy could be used (town-level: different stores as sub-menus), you can check your inventory for current config, choose your race/class (arch/proc), etc etc etc.
.h and hordes .c ! Return victorious with the Amulet of bzImage!
When you are suited up and ready to battle, the compilation process could be initiated by entering the dungeon and watching gcc slay the demons of
Well, maybe that's taking it too far.
But if it got popular enough, maybe Blizzard would re-hash it in a fully-graphic real-time game for Windows.....
I know, I know.... "Don't moderate, reply."
The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.
The current configuration tool *is* CML. The tool that ESR has produced is CML2. CML does its work with a mix of shell, perl, other tools. It's nasty. CML2 is pure Python.
That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python
No, it hasn't happened yet because it's not material for a *stable* kernel series. It'll go into the development kernel, and all of the stuff that needs to be updated to make it work will get updated in the devel tree.
because it wasn't GPL compatibly licensed
Python has had a few releases that the FSF thought were not compliant, but Guido and co. thought that they were. Python has always tried to be GPL compatible. 1.5.2 and lesser are compatible, and so are all of the current newer branches of Python.
Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.
The idea was to create a uniform set of configuration tools that got dependancy checking right and were easy to maintain. CML was none of those things.