@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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
