Lloyd Hilaiel wrote:
All I'm suggesting is that if a library were built as part of the cmake
build that drew a nice line between language parsing and makefile
generation, then people like me who constantly want to hack stuff up
and try stuff out would be able to do so at a level higher than cmake
and in a complimentary and cooperative way. If the existing built-in cmake
language parser used that interface it would maintain itself.
The question is whether the code is currently architected for this. If
it isn't, then it slows down the CMake team to worry about this, unless
they desired it for other reasons anyways and were already planning to
do it. Assuming the code isn't as nicely compartmentalized as you'd
like, what are you personally going to do to make it so? I mean, it's
one thing to say, "Gee, do a lot / a ton of extra work for me so that I
can have something nice to hack on." It's another thing to say, "I'm
willing to clean up such-and-such a module in such-and-such a way so
that it's usable for this-or-that purpose. Will you take my patches if
I provide them?" And to be clear, I am not on the CMake team or in any
way responsible for CMake development. I just report bugs and plot and
scheme how to take over the world with CMake.
This is different than the Lua proposition, because I'm taking a more
conservative path... I don't know that picking a language and shoving
it into cmake is the right way to go.
It isn't... unless it happens to make the CMake team's development
burdens noticeably easier. Anything other than that, is work and pain
for someone else's sake, with no payoff for the majority of us.
I agree that frontend and backend separation makes sense, in principle.
But I am saying, that is likely a ton of work. Are you personally
offering to do a good chunk of that work?
Cheers,
Brandon Van Every
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
