[CMake] [cmake-developers] CMake IR

Nagy-Egri Máté Ferenc csiga.biga at aol.com
Fri Jul 31 03:05:07 EDT 2015


@all:


Thank you folks for the input and the active discussion (not shifting into flame and troll wars).


@Dave&Dan:




I agree that JSON looks better. I have no fetish about XML and I could be convinced on just about anything in the choice of the IR. The only important point is that it SHOULD EXIST and be well defined. Hooking all the generators straight into the script interpreter is not good. 




The only reason I intially chose XML and XSD is because they are readily available in just about any language. (Take the C++ codegen lib for instance) The big difference is that XSD is a widely adopted recommendation. Every lib supports it. The moment JSON can provide a schema that is as widely adopted as XSD, I have no objection against JSON. I read through http://www.w3schools.com/Schema/default.asp in a matter of a few hours and it as simple as things can get. But spawning a JSON schema for this project alone would feel like being back at square 1.



Even if nothings becomes of this idea, if CMake could manifest such a thing (like LLVM is for… just about everything C++ related), it would both distill the internals into something easier to comprehend, and at least significantly increase interoperability with IDEs and it’s own generators. (Deferred generation would be a welcome side-effect. The generators would only be invoked once the IR is complete. Whether the generator make use of the global info or spawn build invocations and targets on their first encounter is up to the generator to decide.)




@Dan:




I don’t quite understand resistance toward MS tech. Windows resides on +80% of PCs in the world, CMake already has VS and NMake generators… if there existed multiple input languages, I do not understand why one of them couldn’t be a native Windows script language.




@Eric:




Thank you for the extensive and thorough answer.




I have not taken a look at Gyp, but will surely do.




As for conditionals and complex scenarios. If the people who encountered such barriers could elaborate a little on what their experiences were, maybe design could take such cases into consideration from day one.




As for the GUI editor of a project, it has occured to me (and others too) that such a tool would be darn useful. If it were a seperate tool, I’d still use it just about every day, but you are correct that this feature would be best embedded into the IDE. I am actively engaged with the folk at the Visual C++ team who are looking for a way to hook CMake into the IDE. So, if all goes well it might even happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150731/3e275643/attachment.html>


More information about the CMake mailing list