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 neces
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)
> foobazify(${Element})
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
in
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 p
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):
f
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 m
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
>
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 'I
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 EX
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 in
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 this
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 .. -G"KDevelop
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 -DCM
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 command
- 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:
>
> https://cmake.org/Bug/view.php?id=1591
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 -DCMAKE_BUILD_TYPE
On 01/14/2016 09:11 AM, Charles Huet wrote:
> Thanks for the insight !
[snip]
> but Lua seems to be a better fit for CMake now that I think about the
> constraints you listed.
Yes, Eric, thanks for the excellent post summarizing the history of this
issue and why Lua is a great candidate.
> The ma
The following issue has been SUBMITTED.
==
https://cmake.org/Bug/view.php?id=15920
==
Reported By:R Jones
Assigned To:
===
The following issue has been SUBMITTED.
==
https://cmake.org/Bug/view.php?id=15919
==
Reported By:qiv
Assigned To:
===
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 provided
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
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 hea
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 13:14 +, Charles H
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 Neun
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. Then developers wo
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, t
I fully agree with Alexander.
It seems a very bad idea to use a general purpose script language to manage
CMake stuff.
For sure, CMake language is a bit “curious” :) and changing for a more user
friendly one is a good idea but, in my opinion, only dedicated languages (I.e.
Specialised for the p
27 matches
Mail list logo