>
> 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
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
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 a
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 easil
> 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 can
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
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 progr
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",
>
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 to
> the constraints that
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 e
> 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 m
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 dependency then that woul
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 allow
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 t
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
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 to
(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 happen
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 not
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,
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
i
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 platforms
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 reading a few endless disc
22 matches
Mail list logo
