<div dir="ltr">I think that the special thing about CMake, is the option to customize a build system (if needed). This is also the thing that makes CMake harder to use than other declarative-based build systems.<br><div><br></div><div>Therefore, I think we should combine these things together: </div><div><ul><li>From one side, we would have (for example) a global list of targets with the option to export it to (for example) a JSON document and then simply load it. </li><li>From the other side, programmers should be able to use a script language to customize their build process.</li></ul><div>That would enable programmers, IDEs and automated tools to create a valid and simple documents for simple projects and also would give programmers the power they need in order to customize cmake for their needs. </div></div><div><br></div><div>For example, a simple declaration (pseudo code):</div><div>cmake_libraries += {</div><div> ["name": "myLib",</div><div> "files": "myLib.c",</div><div> "link_type": "static"]</div><div> }</div><div><br></div><div>And a customized script for easily adding a library for a cpp class:</div><div>def my_add_library(name, class_name):</div><div><div> cmake_libraries += {</div><div> ["name": name,</div><div> "files": [class_name + '.cpp', class_name + '.h'],</div><div> "link_type": MY_LINK_TYPE]</div><div> }</div></div><div><br></div><div># Then, add my customized library:</div><div> my_add_library('myLib', 'myLib')</div><div><br></div><div>Note that it still would be possible to export these "scripted files" to a simple JSON file. </div><div><br></div><div>I would be happy to hear your opinion about this general design.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 5:56 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/12/2017 01:20 PM, Shmuel H, wrote:<br>
> maybe a general problem with dependencies, which generally<br>
> make our life harder?<br>
<br>
</span>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.<br>
<span class=""><br>
> 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.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Brad<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/<wbr>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" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/cmake-<wbr>developers</a><br>
</div></div></blockquote></div><br></div>