[cmake-developers] [Discussion] Add python support for CMakeLists

[Florent Castelli]

Well, CMake scripts can be written in a somewhat declarative form now.
What prevents this now is that a lot of people use indirections everywhere. For example: add_library(foo STATIC ${SRCS})
If it was a plain list, any decent IDE would be able to parse this and add another file to the list easily.
If some commands allowed more expressive alternative forms, it would definitely improve the situation:

add_library(foo STATIC
  bar1.c
  bar2.c
  WINDOWS
  windows-specific.c
  APPLE
  apple-specific.m
)

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.

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. 
It had the benefit of fixing all the copy issues around (that was just annoying boilerplate) and introduce some interesting sanity checks:
 - 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)
 - checking that all the include folders exist (this prevents some spelling mistakes)
 - 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)
 - 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)
 - translating “Framework::Foobar” to the right calls to find the frameworks and link against it without more boilerplate
 - translating “FOO::FOO” to a find_package() call and using the imported target automatically in some circumstances
All of that was done because CMake has a powerful scripting language, so it’s definitely interesting to have one!

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?

/Florent

> On 16 Jan 2017, at 21:02, Shmuel H, <shmuelhcmake at gmail.com> wrote:
> 
> > My point is that an IDE should be able to edit the declarative spec
> > without having run a configuration or even create a build tree.  The
> > spec should be the preferred form for making changes and stored in
> > version control.  Any intermediate spec generated by a procedural
> > Language script cannot serve this role.
> 
> 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.
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170116/96d9b3a3/attachment.html>