<div>Hello all!</div><div> </div><div>13.01.2017, 18:56, "Brad King" <brad.king@kitware.com>:</div><blockquote type="cite"><p>On 01/12/2017 01:20 PM, Shmuel H, wrote:</p><blockquote> maybe a general problem with dependencies, which generally<br /> make our life harder?</blockquote><p><br />Yes. People typically install CMake only in order to build something else.<br />If Python were added as an external dependency then that would be yet<br />another step. If it were bundled then our bootstrap script and CMake-based<br />build of CMake itself would both have to learn to build Python. Python<br />is also a distribution in addition to a language, so deploying it raises<br />the question of what to bundle with it. None of these is something I'd<br />like to have added to the responsibilities of maintaining and distributing<br />CMake.<br /><br />There are already other build systems that use Python as their language,<br />but many people still choose CMake over them anyway.</p></blockquote><div> </div><div>I believe that language should be one.</div><div> </div><div>Many of us well know C ++, and so we understand each other.</div><div> </div><div> </div><blockquote type="cite"><blockquote> However, for me - a user, a known and well-designed programming language<br /> for CMake would be very helpful. I can't say that for every other user,<br /> but I think it would make their life a lot easier too.</blockquote><p><br />As Charles Huet mentioned Lua is a good choice because it provides a<br />language and is portable to everywhere that has C. It is also not a<br />distribution. I've posted in the past a design for a cmake_lua command<br />that allows one to use Lua code within CMakeLists.txt files. Actually<br />using it as a full replacement language though will first require more<br />refactoring internally as I mentioned in my previous post.<br /><br />As I've mentioned in previous discussions, if we're going to go through<br />a language change we should make sure it addresses important needs.<br />Having a declarative specification that can be externally tooled will<br />be helpful to IDEs. I'd envision such a format that is then imported<br />by the procedural-language part of the configuration process for<br />evaluation of conditions and finalization for the current target.<br /><br />Without a comprehensive design I'm hesitant to proceed on any such effort.</p></blockquote><div> </div><div>I completely agree. Must first be designed very, very good design decision.</div><div> </div><blockquote type="cite"><p><br />-Brad</p><span>-- </span><p><br />Powered by <a href="http://www.kitware.com/">www.kitware.com</a><br /><br />Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ">http://www.cmake.org/Wiki/CMake_FAQ</a><br /><br />Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br /><br />CMake Support: <a href="http://cmake.org/cmake/help/support.html">http://cmake.org/cmake/help/support.html</a><br />CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html">http://cmake.org/cmake/help/consulting.html</a><br />CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html">http://cmake.org/cmake/help/training.html</a><br /><br />Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br /><br />Follow this link to subscribe/unsubscribe:<br /><a href="http://public.kitware.com/mailman/listinfo/cmake-developers">http://public.kitware.com/mailman/listinfo/cmake-developers</a></p></blockquote><div> </div><div> </div><div>Regards,</div><div>Konstantin Podsvirov</div><div> </div>