Re: [cmake-developers] [Discussion] Add python support for CMakeLists
> > It's up to users to use generator expressions instead of if(WIN32) or > whatever: > > add_library(foo > foo.cpp > $<$:foo_win.cpp> > ) > > This has been possible for years and was designed with IDEs in mind: Sure, it’s possible, but it’s not very user friendly or declarative (you need to parse and interpret the generator expression). > > http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html > >> 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. > > You should be able to put any configure-time variable through the generator > expressions $ or $ to make them genex-compatible. Same, it’s not user friendly or a great syntax. I’ve rarely seen any advanced usage in projects in the wild, I think for that very reason. One thing that I dislike in genex is that there is no “else” clause. So you have to duplicate the whole condition and add a $ around it. Having something close to a ternary operator would be nice. /Florent -- 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
Re: [cmake-developers] [Discussion] Add python support for CMakeLists
Florent Castelli wrote:
> 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
> )
It's up to users to use generator expressions instead of if(WIN32) or
whatever:
add_library(foo
foo.cpp
$<$:foo_win.cpp>
)
This has been possible for years and was designed with IDEs in mind:
http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html
> 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.
You should be able to put any configure-time variable through the generator
expressions $ or $ to make them genex-compatible.
Thanks,
Steve.
--
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
Re: [cmake-developers] [Discussion] Add python support for CMakeLists
On 01/16/2017 03:40 PM, Florent Castelli wrote: > Well, CMake scripts can be written in a somewhat declarative form now. [snip] > I made some functions with parameters similar to the example above and > everything became a (custom) declarative format. Yes, many projects have macros/functions to achieve exactly that. This shows that a preferred form for editing the spec, even for humans, is a declarative format. In the above cases that format is stored inside `CMakeLists.txt` files or loaded by them. This is consistent with my proposal for a generalized declarative spec that is loaded by the procedural language for evaluation. -Brad -- 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
[cmake-developers] Question / Feature request: LLVM bitcode target
Hello, This goes somewhere between a question and a feature request. We are working on mull, https://github.com/mull-project/mull mutation testing system based on top of LLVM. Currently the development is mostly focused around testing of C++ projects and we use LLVM and its libraries as a playground. To run Mull against a library like LLVMCore or LLVMSupport, we need to compile the library, its tests and all of its dependencies to LLVM bitcode. Currently the best thing we can do to achieve this so far is to get a compilation database for a target and all of its dependencies using ninja and do some bash magic to patch the `clang ...` commands to produce a suite of *.bc files which Mull can then consume. We think that it would be great if CMake had a capability of generating LLVM bitcode targets out of existing targets with a support of incremental compilation so that one could iterate on development of a library and this kind of bitcode target would produce a set of *.bc files in a same way like add_library produces libraries. I have tried to clone the targets by hand using this script as a starting point: https://github.com/shadow/shadow/blob/master/cmake/LLVMTools.cmake#L40 but found that it was hard to create a clone of existing target to 100% match all of the compilation options of a source target. I could make it work for some of the LLVM targets but overall this approach seems to not be a solid one. So the following are questions that taken together might constitute a feature request: - Can it be possible to recursively clone existing library target created with add_library and all of its dependencies? - Modify this cloned target to produce a set of *.bc files instead of a binary. - Have this routine wrapped into a stable and portable CMake function like: add_llvm_bitcode_target? Thanks. -- 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
Re: [cmake-developers] [Discussion] Add python support for CMakeLists
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, 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
--
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
Re: [cmake-developers] [Discussion] Add python support for CMakeLists
> 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
Re: [cmake-developers] [Discussion] Add python support for CMakeLists
On 01/14/2017 03:27 AM, Shmuel H, wrote: > 1. Script stage: Look for and run build script, that will generate a > [JSON] configuration file. 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. -Brad -- 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
Re: [cmake-developers] [Discussion] Add python support forCMakeLists
This all rhymes fairly well with an earlier suggestion of mine, CMake IR, a
stateless intermediate representation. Though I originally suggested this
feature to facilitate the authoring of generators, it could’ve also act as an
alternative front-end, other than the CMake script language (which is still the
least friendliest part in CMake, hence these attempts of ridding it in favor of
friendlier scripting languages).
The scenario depicted here is pretty much doable already, but not in CMake
terms. The stateless part is pretty much MSBuild, built atop XML with well
defined schemas for the various build steps (C++ build, C++ link, C# build,
etc.), and there is a custom target that has pre-build, build, and post-build
steps (as all other targets as well). If you’d invoke Python there, you’re
pretty much at the place you depict here. Using MSBuild, you’d only need a
schema to invoke CMake targets to interoperate with current CMake projects.
One of the reasons why VS is so successful, is because you don’t need to invoke
voodoo to acomplish something as simple as a build. Click-click and you’re
done. This is because the build representation is SIMPLE (just XML). I
understand that the reason why CMakes script language only has one type, the
string type is because it is the common denominator for all the target
generators and it is easy to handle inside generator implementations, but heck,
it’s a pain to use. The fact that source files to add_executable() may be a
list, but target_compile_definitions cannot… it’s a joke. I have to manually
insert spaces in between compiler options.
Apologies if my tone is harsh at times, but I believe CMake could do a lot
better. Server Mode is welcome sight, but it’s pretty much a workaround, or at
least half the job. I believe CMake really needs to open to other front-ends
than its script language, and Server Mode only compliments this. I understand
that it becomes an N*M issue at this point, but heck; we have lived with
containers and iterators (abstractions in general) that go around this issue.
MSBuild going cross-platform thanks to .Net Core renders it a compelling
alternative for everyday tasks. (And I still have not touched upon Scons, Cake,
Fake, Psbuild and the likes.)
Feladó: Shmuel H,
Elküldve: 2017. január 14., szombat 9:27
Címzett: Brad King
Másolatot kap: CMake Developers
Tárgy: Re: [cmake-developers] [Discussion] Add python support forCMakeLists
Maybe we could combine them together: the configuration process would be
separated into two stages:
1. Script stage: Look for and run build script, that will generate a [JSON]
configuration file.
2. Look for a configuration file, and generate build files according to it.
Then, a programmer should decide if he need to use the script stage. If not, he
would be able to edit it all with its favorite IDE. If he need the script
stage, he would not be able to edit it with a automatic tools.
I think we should make the configuration files as simple as we can (`cbp` files
are not a good example for a simple file): usable defaults for fields, etc.
Adding named condition \ variables would serve only a part of developers needs
(for example, choosing source files according to the current OS) but it would
prevent developers from being able to customize their building with functions
(For example, applying a long set of configurations for each build target to be
used as a plugin for an application with a lot of restrictions).
On Fri, Jan 13, 2017 at 9:28 PM, Brad King wrote:
On 01/13/2017 11:45 AM, Shmuel H, wrote:
> * From the other side, programmers should be able to use a script
> language to customize their build process.
>
> For example, a simple declaration (pseudo code):
> cmake_libraries += {
> ["name": "myLib",
> "files": "myLib.c",
> "link_type": "static"]
> }
The declarative part needs to be self-standing so that it can be loaded
by an IDE, edited by the user, and saved back out in the original format
with a minimal diff. An IDE will have no idea how to write snippets back
into a procedural script. This is one reason CMakeLists.txt files cannot
be edited through an IDE except as text files.
My proposal is that the declarative part would have most of the build,
but with some kind of named condition/config variables. Then the
procedural part will introspect the system to determine the values of
the configuration variables so that CMake can evaluate the conditions.
-Brad
--
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
C
