<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Well, CMake scripts can be written in a somewhat declarative form now.<div class="">What prevents this now is that a lot of people use indirections everywhere. For example: add_library(foo STATIC ${SRCS})</div><div class="">If it was a plain list, any decent IDE would be able to parse this and add another file to the list easily.</div><div class="">If some commands allowed more expressive alternative forms, it would definitely improve the situation:</div><div class=""><br class=""></div><div class="">add_library(foo STATIC</div><div class="">  bar1.c</div><div class="">  bar2.c</div><div class="">  WINDOWS</div><div class="">  windows-specific.c</div><div class="">  APPLE</div><div class="">  apple-specific.m</div><div class="">)</div><div class=""><br class=""></div><div class="">I find that most of the conditionals are just to create the list of sources per platform and then the list of dependencies. It’s certainly possible to use generator expressions for some cases, but they don’t have the prettiest syntax around, and maybe also not access to all the local variables that you need to pick the right files.</div><div class=""><br class=""></div><div class="">In my company, I got annoyed by all the people who just copy pasted CMake files (in imperative form) around without understanding what was everything doing, so I made some functions with parameters similar to the example above and everything became a (custom) declarative format. </div><div class="">It had the benefit of fixing all the copy issues around (that was just annoying boilerplate) and introduce some interesting sanity checks:</div><div class=""> - checking that all the files in the source folder are used (so we don’t miss a header for IDE users for example or leave stray files around)</div><div class=""> - checking that all the include folders exist (this prevents some spelling mistakes)</div><div class=""> - checking that all the include folders are relative and don’t go back in the hierarchy or aren’t absolute (for a cleaner project structure and preventing undeclared dependencies between targets)</div><div class=""> - checking for dependency cycles (and erroring on them), CMake tolerates this, not my coding standards (btw, it’s fun to write graph DFS algorithms in the CMake language)</div><div class=""> - translating “Framework::Foobar” to the right calls to find the frameworks and link against it without more boilerplate</div><div class=""> - translating “FOO::FOO” to a find_package() call and using the imported target automatically in some circumstances</div><div class="">All of that was done because CMake has a powerful scripting language, so it’s definitely interesting to have one!</div><div class=""><br class=""></div><div class="">Maybe CMake doesn’t need a real declarative mode, it just needs a small set of user friendly functions that does the same thing as the low level ones and can be easily edited by IDEs?</div><div class=""><br class=""></div><div class="">/Florent</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Jan 2017, at 21:02, Shmuel H, <<a href="mailto:shmuelhcmake@gmail.com" class="">shmuelhcmake@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><span style="font-size:14.4px" class="">> My point is that an IDE should be able to edit the declarative spec</span><br style="font-size:14.4px" class=""><span style="font-size:14.4px" class="">> without having run a configuration or even create a build tree.  The</span><br style="font-size:14.4px" class=""><span style="font-size:14.4px" class="">> spec should be the preferred form for making changes and stored in</span><br style="font-size:14.4px" class=""><span style="font-size:14.4px" class="">> version control.  Any intermediate spec generated by a procedural</span><br style="font-size:14.4px" class=""><span style="font-size:14.4px" class="">> Language script cannot serve this role.</span><br class=""></div><div class="gmail_extra"><span style="font-size:14.4px" class=""><br class=""></span></div><div class="gmail_extra"><font size="1" class="">I understand that. Maybe we should let the user decide whether to use the advantages the declarative spec or to use a script to generate it. That way, we would not lose the scripting future, which is a big future of CMake. On the other side, we would not force users to use that and even we would make it a lot easier for IDEs to manage these projects.</font></div></div>
-- <br class=""><br class="">Powered by <a href="http://www.kitware.com" class="">www.kitware.com</a><br class=""><br class="">Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" class="">http://www.cmake.org/Wiki/CMake_FAQ</a><br class=""><br class="">Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br class=""><br class="">CMake Support: <a href="http://cmake.org/cmake/help/support.html" class="">http://cmake.org/cmake/help/support.html</a><br class="">CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" class="">http://cmake.org/cmake/help/consulting.html</a><br class="">CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" class="">http://cmake.org/cmake/help/training.html</a><br class=""><br class="">Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" class="">http://www.kitware.com/opensource/opensource.html</a><br class=""><br class="">Follow this link to subscribe/unsubscribe:<br class=""><a href="http://public.kitware.com/mailman/listinfo/cmake-developers" class="">http://public.kitware.com/mailman/listinfo/cmake-developers</a></div></blockquote></div><br class=""></div></body></html>