Re: [cmake-developers] CMake alternative language

I think this problem already exists. When "projects build elaborate macro/function systems in the CMake language", you have to understand the build system program. And in my experience, those systems are widely different from one another. I have seen a system where you defined lots of variables,

Re: [cmake-developers] CMake alternative language

On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf wrote: > > My personal opinion: if the full power of python would be available, the > build > scripts would quickly turn into real programs, because programmers would be > tempted to do so if all of python would be available.

Re: [cmake-developers] CMake alternative language

As long as CMake embeds everything that is required, I don't see the additional pain (since this is what it already does with the CMake language). Le jeu. 14 janv. 2016 à 13:35, Jean-Michaël Celerier < jeanmichael.celer...@gmail.com> a écrit : > > On Wed, Jan 13, 2016 at 10:21 PM, Alexander

Re: [cmake-developers] CMake alternative language

I am hesitant to add more fuel to the fire for this discussion because it has been discussed many times before through the years and my sense is that this isn’t what Brad is really interested in pursuing. I encourage you search the mailing list history. I’ll try to summarize (off the top of my

Re: [cmake-developers] fixup_bundle with @loader_path

On 01/13/2016 01:38 AM, Simon Wells wrote: > it kept saying that @loader_path/libboost_chrono-mt.dylib was not found It looks like this was now reported here with a patch: https://cmake.org/Bug/view.php?id=15918 We already handle @executable_path, so @loader_path should be handled in a similar

Re: [cmake-developers] CMake alternative language

Maybe just implement the python syntax (or a t lease a subset) in the cmake core , so no need extern dep and provide a clean/defined interface to be able to call complex external script is whatever languages. 2016-01-13 14:27 GMT+01:00 Saša Janiška : > On Sri, 2016-01-13 at

Re: [cmake-developers] CMake alternative language

Thanks for the insight ! I started going towards python because I am more familiar with it, but Lua seems to be a better fit for CMake now that I think about the constraints you listed. The main point I am getting from your mail is that Kitware may not want to go down this route, even if

Re: [cmake-developers] Git for windows patch

Hi, Shawn! I am using CMake and Git on the Windows. As an IDE I use Qt Creator. My experience is that on Windows you need to use: "C:\Program Files [(x86)]\Git\cmd\git.exe" If you use your proposed way, I'm having problems work with Git in my project. It seems to me that this decision is

Re: [cmake-developers] CMake alternative language

The problem is doing : list(LENGTH MyList NumList) math(EXPR MaxItList ${NumList}-1) foreach(i RANGE ${MaxItList}) list(GET MyOtherListOfSameSizeThanMyList ${i} Element) foobazify(${Element}) endforeach() instead of : for i in range(0, MyList.size):

Re: [cmake-developers] CMake alternative language

On Thu, Jan 14, 2016 at 3:09 PM, Jean-Michaël Celerier wrote: > The problem is doing : > > list(LENGTH MyList NumList) > math(EXPR MaxItList ${NumList}-1) > > foreach(i RANGE ${MaxItList}) > list(GET MyOtherListOfSameSizeThanMyList ${i} Element)

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

Brad King wrote: > I think the responses in this thread have indicated there is interest > in working toward the full daemon approach. Perhaps discussion should > now proceed on the daemon protocol design over in the thread Tobias > started on cmake-developers: > > cmake daemon mode protocol >

Re: [cmake-developers] cmake daemon mode protocol

Tobias Hunger wrote: > Hi Stephen, > > I have successfully build and run your cmake server mode changes and > the python client script does work as advertised. Thanks for doing that! > I do have a couple of remarks about it. This is more intended as a > starting point for discussion as a real

[cmake-developers] Git for windows patch

Hi, Recently I had to build a project on windows whose build required git. And even though I had installed git from here [1] in the default location, I had to tell CMake where to find it every time I did a build in a clean build tree. So here is a patch that tells CMake to look in the default

Re: [cmake-developers] fixup_bundle with @loader_path

- On Jan 14, 2016, at 6:48 AM, Brad King brad.k...@kitware.com wrote: > On 01/13/2016 01:38 AM, Simon Wells wrote: >> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found > > It looks like this was now reported here with a patch: > >

Re: [cmake-developers] CMake alternative language

Charles Huet wrote: > When the configure step takes > about 30 seconds, and all you can do is use MESSAGE() to find what > happens, this is no walk in the park. A real debugger would do a world of > good to CMake. This is one of the things that I address with the daemon work - a 'recording' is

[cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug

It seems that the names of the PRIVATE dependencies of a library are not affected by either the NAMESPACE option or the EXPORT_NAME property. A minimal example: add_library(one STATIC ...) add_library(two STATIC ...) target_link_libraries(two PRIVATE one) install(TARGETS one two

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On 01/14/2016 03:38 PM, Alexander Neundorf wrote: > On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote: >> +1 from my side, KDevelop 3 is super ancient (last release around 2008 >> according to the interwebs). Get rid off the generator. > > Brad, what's your opinion on this ? > Removing

Re: [cmake-developers] CMake alternative language

Looking at what kind of mistakes the newcomers make, I think it's rather the global workflow and the roles of certain key variables/properties they don't get. At first their problem is not that they can't make a for-loop or increment a variable. It's that they don't understand how the build and

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote: > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > > Running version 3.2.2 on Ubuntu 15. I run the following command: > > > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 > > -DCMAKE_CXX_COMPILER=g++-4.9

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote: > On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote: > > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > > > Running version 3.2.2 on Ubuntu 15. I run the following command: > > > > > > $ cmake ..

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

On 01/13/2016 06:17 PM, Eric Wing wrote: > Under the hood, I think the LLVM linker can handle all of these > through ld. But I think the thing that is tripping me up is that Swift > seems to need to link against some additional libraries which are not > needed in the pure C case. The swiftc

[cmake-developers] [CMake 0015919]: Building CUDA files fails when source path contains parenthesis

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15919 == Reported By:qiv Assigned To:

[cmake-developers] [CMake 0015920]: Tests fail

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15920 == Reported By:R Jones Assigned To:

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On Wed, Jan 13, 2016 at 3:16 PM, Alexander Neundorf wrote: > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: >> Running version 3.2.2 on Ubuntu 15. I run the following command: >> >> $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 >> -DCMAKE_CXX_COMPILER=g++-4.9

Re: [cmake-developers] CMake alternative language

My stumbling blocks are the use of keywords instead of operators... if( Something == ${SomeOtherThing} ) vs if( Something STREQUAL ${SomeOtherTHing} ) It might be nice if the operator '=' could be used in addition to the function SET() SET( a something ) becomes A = something Was gong to say