<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 8, 2016 at 5:30 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:</div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
See above.  Lua has come up several times in the past in particular because<br>
its implementation is meant to be small and embeddable.  I've thought a few<br>
times about how to make Lua scripting available from within the CMake language<br>
in a clean way, but that will not be as valuable as the above pure-spec approach.<br>
<br></blockquote><div><br></div><div>Please, do not do that.</div><div><br></div><div>The moment you make CMake scriptable in more than one language, you are forcing every CMake user to learn that additional language because sooner or later he will step into a third-party that is using that additional language.</div><div><br></div><div>IMHO, if you want Lua, then Lua it is. But then please get rid of CMake scripting.</div><div><br></div><div>BTW, I am sure you are aware of CMakeScript, CMake scripting in JavaScript:</div><div><br></div><div><a href="http://sourceforge.net/projects/cmakescript/">http://sourceforge.net/projects/cmakescript/</a></div></div><div><br></div><div>Also, declarative? Why? There are already a few declarative build systems (e. g. qbs, one of the reasons for its existence was CMake was not declarative). By moving CMake from the current procedural scripting to a declarative approach, you may alienate your current user base and be good for none anymore.</div><div><br></div>-- <br><div class="gmail_signature">Pau Garcia i Quiles<br><a href="http://www.elpauer.org" target="_blank">http://www.elpauer.org</a><br>(Due to my workload, I may need 10 days to answer)</div>
</div></div>