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.
Therefore, I think we should combine these things together:
- From one side, we would have (for
2017-01-12 11:48 GMT+02:00 Charles Huet :
[...]
> Lua is the language that should be used, since it is easy to embed on all
> the platforms CMake supports. All arguments about language X being better
> than language Y do not matter, since all other languages do not answer
We are pleased to announce that CMake 3.7.2 is now available for download.
Please use the latest release from our download page:
https://cmake.org/download/
Thanks for your support!
-
Changes in 3.7.2 since 3.7.1:
Aleix
On 01/13/2017 11:05 AM, Egor Pugin wrote:
> Why not just use C/C++ for writing build system (bs) rules?
>
> CMake first will build bs itself (e.g. into shared library) and then
> load and execute it on the source tree.
In an earlier post of this thread I said that no dynamic loading will
be
Hello all! 13.01.2017, 18:56, "Brad King" :On 01/12/2017 01:20 PM, Shmuel H, wrote: maybe a general problem with dependencies, which generally make our life harder?Yes. People typically install CMake only in order to build something else.If Python were added as an external
> One requirement for such a format is
> that it is possible for a tool to read the entire spec, make small
> modifications, and write it back out as close as possible to the
> original format.
I have such yaml formatting function for my layout.
You may see those pretty specs I've posted.
At the
On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, wrote:
> Hello,
>
> First of all, I have been using CMake for a few years now, it is awesome
> tool, thank you.
>
> The only problem I currently have with CMake is its language, which has
> not really intended to be one. After
From: Marco Schuler
Date: 2017-01-12 11:16 GMT+01:00
Subject: Re: [cmake-developers] Creating a Keil uVision generator
To: Paul Wilkinson
Hi all
2017-01-03 0:27 GMT+01:00 Paul Wilkinson :
> Hi all,
>
>
On 01/11/2017 04:23 PM, Shmuel H, wrote:
> a few endless discussions about this topic
Previous discussions have not ended in a new language being integrated,
but that does not mean they failed. Several challenges w.r.t. the
internal architecture were identified. A lot of progress has been made
On 01/11/2017 03:59 PM, Stephen Sorley wrote:
> So, could check_function_exists() be explicitly deprecated in the
> documentation in favor of check_symbol_exists()?
Yes. Please submit a MR with proposed documentation updates.
There may still be use cases for the test that
Hi Jean,
If that would be implemented, a python (or any other language) interpreter
would be included in CMake. However, Brad have a problem with that approach.
On Thu, Jan 12, 2017 at 7:28 PM, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:
> (My simple user opinion):
>
> I'm
(My simple user opinion):
I'm not a fan of the idea.
Not particularly because of Python, but because with this, now
if I want to use a library that someone made with a CMakeLists.py in my
project
(for instance as a submodule) :
* I also have to install Python on the machines where the build
Hello Bard,
First of all, let me show my appreciation for an open source maintainer
that open for changes which is not a obvious.
The problem with a solution that doesn't add another language as a
dependency is that it creates incompatibility and requires installing of
more components in order
I hope I've known this earlier so I can do less... and I'll goto your branch and
join gitter channel to discuss .
On Mon, Jan 9, 2017 at 5:12 PM, Charles Huet wrote:
> Hi,
>
> I ported the work of @inbilla to CMake trunk a few months ago, and fixed
> quite a few tests on
Hi,
I also worked on a similar prototype, and I think this should be discussed
further and set as a long-term goal for CMake.
The conclusions from the last time this came up were (from the top of my
head):
1)
Lua is the language that should be used, since it is easy to embed on all
the
Hi Daniel,
It is not about a specific problem with the CMake language, I have little
problems with almost every language (e.g. Python with its variable scopes
and destructors, C++ with a few strange standard decisions), nothing is
perfect.
However, I think that reinventing the wheel is very bad,
Thanks Brad, I've created the merge request here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/394
-Stephen Sorley
On Thu, Jan 12, 2017 at 9:44 AM, Brad King wrote:
> On 01/11/2017 03:59 PM, Stephen Sorley wrote:
> > So, could check_function_exists() be
Hello everyone,
Didn't trace back when this happened, but for quite a long time now
install/local/fast and install/strip/fast targets, at least when using
"Unix Makefiles" generator, are not at all fast. They depend on
install/local and install/strip targets respectively instead of
On 01/12/2017 01:20 PM, Shmuel H, wrote:
> maybe a general problem with dependencies, which generally
> make our life harder?
Yes. People typically install CMake only in order to build something else.
If Python were added as an external dependency then that would be yet
another step. If it were
Hi,
Why not just use C/C++ for writing build system (bs) rules?
C++ is for those who have modern compilers. (By C++ I mean modern C++11-14-17).
C is for everything. These two apis can coexist.
CMake first will build bs itself (e.g. into shared library) and then
load and execute it on the source
20 matches
Mail list logo