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 <brad.k...@kitware.com> 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
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
