Re: [cmake-developers] CMake alternative language

[Charles Huet]

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, then just
imported a file which used those to perform the add_library and such in the
X-Macro pattern (
https://en.wikibooks.org/wiki/C_Programming/Preprocessor#X-Macros).

I think having a language that allows for more terse expressions would be a
net gain.


Also, I find ironic to preach for a simple language when CMake is mainly
targetted at C++.
C++ programmers are used to having *lots* of very powerful tools at their
disposal (template meta-programming, operator overloading, macros, etc) and
having to choose which one to use for the job.

If you do not trust your team mates to keep the buildsystem simple and to
the point even if they had lots of stuff at their disposal, how can you
trust them with the C++ program ?


Le jeu. 14 janv. 2016 à 09:04, CHEVRIER, Marc  a
écrit :

> 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 problem to solve) must be considered.
>
> May be a good approach is to enhance current language for more flexibility
> (for example adding capability for functions to return value, etc…)
>
> Marc
>
>
>
>
>
> On 13/01/16 22:21, "cmake-developers on behalf of Alexander Neundorf" <
> cmake-developers-boun...@cmake.org on behalf of neund...@kde.org> wrote:
>
> >On Wednesday, January 13, 2016 10:59:39 yann suisini wrote:
> >> Hi,
> >>
> >> I'm a new user of CMake, but I just want to express my newcomer point of
> >> view.
> >> Honestly , I can feel the power of CMAKE, but it's a real pain to learn
> ...
> >> I'm using CMAKE for an embedded platform with a non GNU compiler , ant
> at
> >> the end the CMAKE description is longer than the one I built directly in
> >> Ninja.
> >> I had to write a python script to parse my eclipse project xml to
> create a
> >> list of sources files usable by CMAKE.
> >> The first thing I thought was: why this is not a part of cmake ? And the
> >> second thing was : why not using the scripting power of an existing
> >> language like Python(or other one) and add CMAKE as a framework /
> library ?
> >
> >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
> would
> >have to understand two programs: the program itself, and the "build
> program".
> >
> >I'm not saying that the cmake language is beautiful, but it helps to keep
> >cmake scripts somewhat simple, and not evolve into a second program
> >additionally to the actual program which is being built.
> >
> >Alex
> >
> >--
> >
> >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
-- 

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 

Re: [cmake-developers] CMake alternative language

[Jean-Michaël Celerier]

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 would
> have to understand two programs: the program itself, and the "build
> program".


The problem is when you have to do a real program for your build system
anyways (which occurs one day or another for any large enough project I
guess).
Currently it's a real pain (but it'd be even more painful to have to ship
Python / Bash / $script_language as part of your build system).
-- 

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

Re: [cmake-developers] CMake alternative language

[Charles Huet]

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 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
>> would
>> have to understand two programs: the program itself, and the "build
>> program".
>
>
> The problem is when you have to do a real program for your build system
> anyways (which occurs one day or another for any large enough project I
> guess).
> Currently it's a real pain (but it'd be even more painful to have to ship
> Python / Bash / $script_language as part of your build system).
> --
>
> 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

Re: [cmake-developers] CMake alternative language

[Eric Wing]

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 head) about why Lua (as
opposed to other languages).

- Lua above all other languages was recommended by me and others
because it satisfied all the constraints:
- It is tiny and can be included with the CMake source and doesn’t
impact the size of CMake in any significant way
- Being 100% ANSI C allows it to go everywhere CMake already goes and
satisfies the requirement that only a C++ compiler is needed to
bootstrap it.
- Lua is a language designed to be embedded, for this very kind of 
purpose.
- Lua is sandboxed by default and has a minimal (and optional)
standard library.
- This means users won’t be encouraged to call all sorts of
non-portable library calls like with some other languages. CMake can
control what APIs are exposed addressing those concerns that a full
programming language may allow too much variance and craziness in the
community.
- Lua’s liberal license is compatible with CMake’s liberal license.

- Lua is one of the cleanest, simplest mainstream languages out there
and is incredibly easy to learn, yet still supporting a wide range of
higher-level constructs (functions as first class values, closures,
proper tail recursion). Documentation and tutorials are readily
available.
- Lua’s core data structure is the table, which is a extremely similar
to JSON (which it happens to also predate), which makes lists and
declarative data style very easy and natural to do.
- Lua has proven itself in the video game industry in that C/C++
developers are comfortable dealing with it (not a syntax shell shock
to them, say like LISP, or quite frankly CMake)
- Lua being a full, well designed programming language allows for ways
to write things which is currently really hard in CMake’s language.
Additionally, adding features to CMake’s language is hard in that you
have to think about all the potential side-effects, edge cases, and
inconsistencies. Lua takes this burden away and how to use everything
is well known/documented.

- To prove to us that CMake was already too far down the road and
retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
CMake/Lua proof of concept working in like 13 hours. (Oops.)
- But it was decided that Kitware didn’t want to go down this road.

- We attempted to build off Ken Martin’s experiment to keep it alive,
but that project essentially failed.
- Lack of time, resources, expertise, etc, and this was back in the
CVS days so keeping up with the mainline was hell since merge tracking
is pretty much non-existent.
- There was one interesting thing implemented showing that both
existing CMake script and Lua script could co-exist. And I think there
was even a proof a concept that different language scripts could call
one another.



So just on the constraints/requirements issue, I think we convinced
Brad, that *if* anything should be chosen, it should be Lua, which is
why Lua is still in his head. And these constraints are still in play.
I am constantly fighting dependency hell on platforms. It is nice that
CMake has no external dependencies except a C++ compiler and can
bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
I needed to build CMake; no problem. I just tried to build Swift on
the Pi. I got hit by a bug where the build process pulls in the wrong
version of Python (2 vs 3) if both exist on the system. What a mess.
(And a 9+ hour build cycle to retry.) Not to mention the disk space
problem of needing all these dependencies.

But it sounds like Brad is more interesting in a purely declarative
replacement for CMake.
That would be nice for all the editor-assist reasons. Though I’m also
skeptical of pulling that off (though I hope it can be done in a
useful way). There are other systems like that, yet, I’m using CMake
for a reason. I don’t have any real insight on the problem, but I
recall hacking Ant XML files and just to have a simple conditional
(if/else) was a huge PITA. And as these things cascade with more
conditionals, it becomes a major effort. Antidotally, I watched
several projects try to use Gyp even though there was a CMake
description already written (albeit, not working for the platforms we
needed). I watched from the sidelines as those projects failed to get
Gyp working. I don’t have any insight in why unfortunately. For one
project though, I did later come in and did get the CMake description
working.

I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help 

Re: [cmake-developers] fixup_bundle with @loader_path

[Brad King]

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 way but we need to make sure enough information is passed to
know the loader path.

Clinton?

Thanks,
-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

Re: [cmake-developers] CMake alternative language

[yann suisini]

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 Huet wrote:
>
> > I don't think this is a dumb question, actually this is part of the
> > problem I think would be resolved whit a new language.
> >
> > The barrier of entry to using CMake is too high in my opinion, and I
> > think using an existing language would lower it *a lot*.
>
> Personally I'm determinant to use CMake, mostly due to its maturity and
> CPack's features, but recently stumbled upon Meson http://mesonbuild.com/
> )
> build system whose goal is "to be both extremely fast, and, even more
> importantly, as user friendly as possible."...it also uses Ninja instead
> of Make as backend.
>
> Otoh, I believe that main problem with CMake is lack of quality docs -
> even
> Mastering CMake book has constantly very bad reviews.
>
> Sincerely,
> Gour
>
>
> --
> One who sees inaction in action, and action in inaction,
> is intelligent among men, and he is in the transcendental position,
> although engaged in all sorts of activities.
>
>
>
>
> --
>
> 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

Re: [cmake-developers] CMake alternative language

[Charles Huet]

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 with a working prototype, with the
ability of slow migration by using both CMake script and Lua.

I understand that some users are against such a change (as pointed out in
this very thread) but I'd be willing to contribute time and effort towards
it, if given the assurance it would not be in vain.

>I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help me
avoid fighting the CMake language, and that would be very welcome. But
I don’t expect the messiness to ever truly go away…that is the
byproduct of systems/environments being so different and ever
changing.

This perfectly sums up what I feel :)

Le jeu. 14 janv. 2016 à 14:46, Eric Wing  a écrit :

> 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 head) about why Lua (as
> opposed to other languages).
>
> - Lua above all other languages was recommended by me and others
> because it satisfied all the constraints:
> - It is tiny and can be included with the CMake source and doesn’t
> impact the size of CMake in any significant way
> - Being 100% ANSI C allows it to go everywhere CMake already goes
> and
> satisfies the requirement that only a C++ compiler is needed to
> bootstrap it.
> - Lua is a language designed to be embedded, for this very kind of
> purpose.
> - Lua is sandboxed by default and has a minimal (and optional)
> standard library.
> - This means users won’t be encouraged to call all sorts of
> non-portable library calls like with some other languages. CMake can
> control what APIs are exposed addressing those concerns that a full
> programming language may allow too much variance and craziness in the
> community.
> - Lua’s liberal license is compatible with CMake’s liberal license.
>
> - Lua is one of the cleanest, simplest mainstream languages out there
> and is incredibly easy to learn, yet still supporting a wide range of
> higher-level constructs (functions as first class values, closures,
> proper tail recursion). Documentation and tutorials are readily
> available.
> - Lua’s core data structure is the table, which is a extremely similar
> to JSON (which it happens to also predate), which makes lists and
> declarative data style very easy and natural to do.
> - Lua has proven itself in the video game industry in that C/C++
> developers are comfortable dealing with it (not a syntax shell shock
> to them, say like LISP, or quite frankly CMake)
> - Lua being a full, well designed programming language allows for ways
> to write things which is currently really hard in CMake’s language.
> Additionally, adding features to CMake’s language is hard in that you
> have to think about all the potential side-effects, edge cases, and
> inconsistencies. Lua takes this burden away and how to use everything
> is well known/documented.
>
> - To prove to us that CMake was already too far down the road and
> retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
> CMake/Lua proof of concept working in like 13 hours. (Oops.)
> - But it was decided that Kitware didn’t want to go down this road.
>
> - We attempted to build off Ken Martin’s experiment to keep it alive,
> but that project essentially failed.
> - Lack of time, resources, expertise, etc, and this was back in the
> CVS days so keeping up with the mainline was hell since merge tracking
> is pretty much non-existent.
> - There was one interesting thing implemented showing that both
> existing CMake script and Lua script could co-exist. And I think there
> was even a proof a concept that different language scripts could call
> one another.
>
>
>
> So just on the constraints/requirements issue, I think we convinced
> Brad, that *if* anything should be chosen, it should be Lua, which is
> why Lua is still in his head. And these constraints are still in play.
> I am constantly fighting dependency hell on platforms. It is nice that
> CMake has no external dependencies except a C++ compiler and can
> bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
> I needed to build CMake; no problem. I just tried to build Swift on
> the Pi. I got hit by a bug where the build process pulls in the wrong
> version of Python (2 vs 3) if 

Re: [cmake-developers] Git for windows patch

[Konstantin Podsvirov]

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 necessary to discuss here.

Dear list, does anyone have experience and recommendations?

15.01.2016, 02:49, "Shawn Waldon" :
> Hi,
>
> Recently I had to build a project on windows whose required build 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 install 
> location for Git for Windows [2] when asked for git. I have tested it on my 
> windows machine and it works there.
>
> Shawn
>
> [1]: https://git-for-windows.github.io/
> [2]: C:\Program Files\Git\bin\git.exe ('Program Files (x86)' for older 
> versions or 32 bit systems)
> ,--
>
> 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


Regards,
Konstantin Podsvirov
-- 

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

Re: [cmake-developers] CMake alternative language

[Jean-Michaël Celerier]

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):
foobazifiy(MyOtherListOfSameSizeThanMyList[i])




On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
wrote:

> 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 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
>>> would
>>> have to understand two programs: the program itself, and the "build
>>> program".
>>
>>
>> The problem is when you have to do a real program for your build system
>> anyways (which occurs one day or another for any large enough project I
>> guess).
>> Currently it's a real pain (but it'd be even more painful to have to ship
>> Python / Bash / $script_language as part of your build system).
>> --
>>
>> 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

Re: [cmake-developers] CMake alternative language

[J Decker]

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})
> endforeach()
>
Probably a bad exmple, since you're not using MyList or i that simplifies to

foreach( Element ${MyOtherListOfSameSizeThanMylist} )
foobazify( ${Element} )
endforeach()

> instead of :
>
> for i in range(0, MyList.size):
> foobazifiy(MyOtherListOfSameSizeThanMyList[i])
>
>
>
>
>
> On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
> wrote:
>>
>> 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
>>  a écrit :
>>>
>>>
>>> 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
 would
 have to understand two programs: the program itself, and the "build
 program".
>>>
>>>
>>> The problem is when you have to do a real program for your build system
>>> anyways (which occurs one day or another for any large enough project I
>>> guess).
>>> Currently it's a real pain (but it'd be even more painful to have to ship
>>> Python / Bash / $script_language as part of your build system).
>>> --
>>>
>>> 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
-- 

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

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

[Stephen Kelly]

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
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15424

Yes, let's assume that anyone interested in this topic is now subscribed to 
the cmake mailing list use that thread which does not include the other 
mailing lists. 

Thanks,

Steve.



-- 

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

Re: [cmake-developers] cmake daemon mode protocol

[Stephen Kelly]

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 proposal. Would something
> along these lines be possible:


> * Start daemon-mode without any additional parameters
> 
> * Daemon responds with "
>   {
> "type": "handShake",
> "version": "3.5.x",
> "supportedProtocols": "3.5"
>   }

As you discovered, the cmake binary might not even support the daemon mode 
at all.

I think what you are really asking for is 'the capabilities of the cmake 
binary'. In that sense, you might also want to know what generators are 
available, whether daemon mode is available (and with which protocol 
versions) etc.

The issue at

 http://public.kitware.com/Bug/view.php?id=15462

proposes to dump that information to stdout with a different -E command.

> 
> * Client Handshake:
>   {
> "type": "handshake",
> "requestProtocolVersion": "3.5"
>   }
> 
> * Daemon:
>   {
> "type:"handshake",
> "protocolVersion": "3.5"
>   }

Something like this is possible too. It's not far off what is already done 
in the branch.

> 
> At this point the normal operation should be possible.
> 
> * Client:
>   {
>  "type": "setProjectInformation",
>  "sourceDirectory": "/some/path",
>  "cookie": "1"
>   }
> 
>   Being able to set the source directory is important so that a fresh
> checkout can be configured. There is no build directory available at
> that time...

I understand the desire to inspect a cmake project without asking the user 
to specify a build dir, but cmake has to write build files somewhere in 
order to test the compiler etc. 

For this case, I suggest that if the user tries to 'open the source 
directory', you would use QTemporaryDir to build in a temporary location and 
run the daemon there. I believe clion does something equivalent to that. 

Is that viable? I suppose you are suggesting that cmake do that instead of 
leaving it for clients to do?

> * Daemon should do progress handling while reading the CMakeLists.txt
> or whatever it does:
>   { "type": "progress", "state": "busy", "task": "someId",
> "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }
> 
> * Daemon sends occasional:
>   { "type": "progress", "task": "someId", progressTotal: 25,
> progressCurrent: 12, "cookie": "1" }

Yes. CMake can provide approximate values of how complete the configure step 
is. See cmGlobalGenerator::AddMakefile. That could be exposed to the daemon 
'somehow', such as by defining some virtual callback interface. 

Richer information about some semantics like 'task' and 'busy state' could 
also be provided in a similar way I expect, assuming those could be defined.

> * Finally Daemon responds sends data as that is available now.
>   {
> "type": "projectInformation",
> "sourceDirectory": "/some/path",
> "buildDirectory": "",
> "projectName": "SomeProject",
> "cookie": "1"
>   }

At this point in your proposal, cmake has run the configure step in a 
temporary directory, right? So it would be 

  "buildDirectory": "/tmp/foo/bar"

right?

> * Client:
>   {
> "type": "setProjectInformation",
> "buildDirectory": "/some/other/path",
> "cookie": "2"
>   }

As this sets a new build directory, cmake will have to run the configure 
step from scratch in this new location.

> * Daemon does progress indication as above...
> 
> * Daemon responds with project info:
>   {
> "type": "progressInformation",
> "sourceDirectory": "/some/path",
> "buildDirectory": "/some/other/path",
> "projectName": "SomeProject",
> "cookie": "2"
>   }

I must admit I'm not seduced by this idea as it seems to be that it should 
be easy for an IDE to build in a temporary dir itself. 

However, I think it makes sense to design the protocol to handle specifying 
either a sourceDir or a buildDir (or both if from scratch). Starting daemon 
mode without arguments as you suggest could work (though we would have to 
see how that affects the protocol). Or with a different argument (eg

 cmake -E daemon buildDir
 cmake -E daemon_source sourceDir

) could work. I am also just brainstorming ideas, not proscribing anything.

> We might also want a "ping"/"pong" to detect if the daemon is still
> responding. 

Yes, I had the same thought. I also considered self-terminating the daemon 
if there is no message on the wire for N seconds, effectively requiring the 
IDE to ping every N seconds if it is not doing anything else.  I considered 
this because otherwise the IDE might crash and leave zombie cmake daemons 
running, but I didn't investigate that possibility.

> That would require the daemon to be able to handle
> multiple requests to be in flight... not sure that this is worth it.

Yes, adding a multi-threading requirement to the daemon might 

[cmake-developers] Git for windows patch

[Shawn Waldon]

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
install location for Git for Windows [2] when asked for git.  I have tested
it on my windows machine and it works there.

Shawn

[1]: https://git-for-windows.github.io/
[2]: C:\Program Files\Git\bin\git.exe ('Program Files (x86)' for older
versions or 32 bit systems)
From 9cb6cda92245779f9c3868d6bcc88edb4f02db6b Mon Sep 17 00:00:00 2001
From: Shawn Waldon 
Date: Thu, 14 Jan 2016 18:18:41 -0500
Subject: [PATCH] git: add search paths for default git for windows install

---
 Modules/FindGit.cmake | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Modules/FindGit.cmake b/Modules/FindGit.cmake
index 2c3e5fd..6f6e41e 100644
--- a/Modules/FindGit.cmake
+++ b/Modules/FindGit.cmake
@@ -50,12 +50,14 @@ if(WIN32)
 file(GLOB github_path "${github_path}")
 # SourceTree search path for Windows
 set(_git_sourcetree_path "$ENV{LOCALAPPDATA}/Atlassian/SourceTree/git_local/bin")
+# Git for Windows (git-for-windows.github.io) paths
+set(_git_for_windows_paths "C:/Program Files/Git/bin;C:/Program Files (x86)/Git/bin")
   endif()
 endif()
 
 find_program(GIT_EXECUTABLE
   NAMES ${git_names}
-  PATHS ${github_path} ${_git_sourcetree_path}
+  PATHS ${github_path} ${_git_sourcetree_path} ${_git_for_windows_paths}
   PATH_SUFFIXES Git/cmd Git/bin
   DOC "git command line client"
   )
-- 
2.5.0

-- 

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

Re: [cmake-developers] fixup_bundle with @loader_path

[clinton]

- 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=15918
> 
> We already handle @executable_path, so @loader_path should be handled in
> a similar way but we need to make sure enough information is passed to
> know the loader path.
> 

As far as I know, the information needed is already available, so my initial 
guess is that we don't need any significant re-engineering.

Simon,
Would you happen to have a simple example showing the problem without boost, 
that would be easy to replicate?  That could become the basis for a test.

Clint
-- 

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

Re: [cmake-developers] CMake alternative language

[Stephen Kelly]

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 made during the configure step which can then be inspected.

Thanks,

Steve.


-- 

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

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

[Tamás Kenéz]

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 EXPORT targets DESTINATION lib)
install(EXPORT targets NAMESPACE ns:: DESTINATION cmake)

The generated `targets.cmake` describes the dependency relation with:

set_target_properties(ns::two PROPERTIES
  INTERFACE_LINK_LIBRARIES "\$"
)

That is, it uses `one` instead of `ns::one`. Changing the EXPORT_NAME of
`one` has no effect either.

It works find if I replace PRIVATE with PUBLIC or INTERFACE (of course
there'll be no more LINK_ONLY genexp in that case).

Is this really a bug or did I miss something? I also searched Mantis and
haven't found anything related.

Tamas
-- 

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

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

[Brad King]

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 is something I could do :-)

Sounds good to me.  For compatibility we should continue to support
the generator name and have it simply not create an extra generator
(and instead warn that it no longer creates one).  It can be dropped
from the documentation though.

Please include a Help/release/dev/*.rst file with a release note
about the removal.

Thanks,
-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

Re: [cmake-developers] CMake alternative language

[Tamás Kenéz]

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 install
phases relate to each other, how to organise the files and targets of a
multi-target project, how to connect two projects. These would be just as
difficult to grasp in Python or Lua as it is in CMake-script.

I support replacing the CMake language but in order to lower the barrier I
think 10-20 nice, minimal sample projects would be more important.

Tamas


On Wed, Jan 13, 2016 at 2:14 PM, Charles Huet 
wrote:

> I don't think this is a dumb question, actually this is part of the
> problem I think would be resolved whit a new language.
>
> The barrier of entry to using CMake is too high in my opinion, and I think
> using an existing language would lower it *a lot*.
>
> Thanks for sharing :)
>
>
> Le mer. 13 janv. 2016 à 10:59, yann suisini  a
> écrit :
>
>> Hi,
>>
>> I'm a new user of CMake, but I just want to express my newcomer point of
>> view.
>> Honestly , I can feel the power of CMAKE, but it's a real pain to learn
>> ...
>> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
>> the end the CMAKE description is longer than the one I built directly in
>> Ninja.
>> I had to write a python script to parse my eclipse project xml to create
>> a list of sources files usable by CMAKE.
>> The first thing I thought was: why this is not a part of cmake ? And the
>> second thing was : why not using the scripting power of an existing
>> language like Python(or other one)
>> and add CMAKE as a framework / library ?
>> Probably a dumb question ! :)
>>
>> Yann
>>
>> 2016-01-13 10:34 GMT+01:00 Charles Huet :
>>
>>> Hi,
>>>
>>> > * There is a lot of code out there in the current CMake language so I
>>> do not
>>>   think it is realistic to drop it.  I'm not proposing that this change.
>>>
>>> I am. (more below)
>>>
>>> > * Many projects build elaborate macro/function systems in the CMake
>>> language
>>>   in order to end up with a declarative specification listing the actual
>>>   source files, dependencies, and usage requirements.  I'd like to offer
>>>   an alternative to this.
>>>
>>> In my experience, most of the elaborate macros/functions come either
>>> from a misunderstanding of some of CMake's internals (scope, link
>>> debug/release libs, etc) or to circumvent some shortcoming of the CMake
>>> language (e.g. no return value for functions).
>>>
>>> >  I'd like to improve this by *optionally* moving part of the
>>> specification
>>>   to a (stateless) declarative format that IDEs can load/edit/save
>>> directly
>>>
>>> Split the buildsystem in two different languages ? Would the declarative
>>> part be in a different file ?
>>> Also, the declarative part in my opinion must take advantage of the
>>> language.
>>> For instance, add a source file only for WIN32 systems should be easy in
>>> said declarative format.
>>> Using a custom language (based on JSON for instance) would mean to add
>>> conditionals, which comes back to making a custom language again.
>>>
>>>
>>> To come back to my first point, I understand completely that this would
>>> be a tremendous change, and the transition would be difficult to say the
>>> least. But I think it would be more than worth it in the long term.
>>>
>>> > The moment you make CMake scriptable in more than one language, you
>>> are forcing
>>> > every CMake user to learn that additional language because sooner or
>>> later he
>>> > will step into a third-party that is using that additional language.
>>>
>>> What I have in mind is to deprecate the current CMake language and
>>> replace it with another language. So there would be a transition period,
>>> but in the end there would only be one language again, and a better one.
>>>
>>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
>>> would not need learn a new language (or at least learn one that has many
>>> resources, and can be used for other purposes).
>>> Old-timers would have to learn a new language (or maybe not, most
>>> programmers I know have played a bit with python to automate simple tasks),
>>> but this would be easier than learning CMake was, since there are
>>> established rules and a more consistent design to it.
>>>
>>> Of course I'm not saying this should happen overnight, nor am I saying
>>> this *must* happen, but I think discussing it can only be beneficial.
>>>
>>> I've seen lots of people wonder how to make their CMake scripts more
>>> efficient, and currently this is a very difficult thing to do, since there
>>> is no profiling possible.
>>> And who can say they never spent way too much time trying to understand
>>> why a variable was not correctly initialized ? When the configure step

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

[Kevin Funk]

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 -DCMAKE_BUILD_TYPE=$config
> > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"
> 
> are you sure you actually want to use the KDevelop3 generator ?
> This is for the KDE3 version, and you are probably using the KDE4 version of
> KDevelop ? For that you don't need these generated project files.
> 
> Actually I was thinking about removing this generator, because KDevelop3 is
> really really old, not sure whether it is still available in current Linux
> distributions.
> 
> Alex

+1 from my side, KDevelop 3 is super ancient (last release around 2008 
according to the interwebs). Get rid off the generator.

Cheers,
Kevin

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
-- 

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

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

[Alexander Neundorf]

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"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
> > > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
> > > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"
> > 
> > are you sure you actually want to use the KDevelop3 generator ?
> > This is for the KDE3 version, and you are probably using the KDE4 version
> > of KDevelop ? For that you don't need these generated project files.
> > 
> > Actually I was thinking about removing this generator, because KDevelop3
> > is
> > really really old, not sure whether it is still available in current Linux
> > distributions.
> > 
> > Alex
> 
> +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 is something I could do :-)

Alex

-- 

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

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

[Brad King]

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 seems to know how to
> automatically link in those extra dependencies (and I don't need to
> add all the search paths to where the Swift core libraries are
> located).

That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
the call to it in "Modules/CMakeDetermineCompilerABI.cmake".  That is
responsible for extracting the implicit link information passed by a
given language compiler's front-end.  We'll need to extract that for
Swift.

> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
> as Java). But it didn't seem to do anything for me.

Where did you add the code to set it?

> I just tried not filtering the current primary file from the list. It
> still worked. So maybe we can get away with not filtering that.

Great.  It will be simplest to list all the sources in every call and then
repeat the one that is current.

> Anyway, it seems like adding SOURCES is the next step. Any hints on
> how to do that?

The cmLocalGenerator::ExpandRuleVariable method does the placeholder
substitution.  It relies on values in the RuleVariables structure
to be populated by the calling generator.  The Makefile generator
populates that for the compile line here:

 cmMakefileTargetGenerator::WriteObjectBuildFile

and the Ninja generator here:

 cmNinjaTargetGenerator::WriteCompileRule
 cmNinjaTargetGenerator::WriteObjectBuildStatement

Note that for Ninja we actually convert our placeholders to Ninja
rule placeholders and then provide the values on the actual build
statement line.

You should be able to call

 this->GeneratorTarget->GetObjectSources(objectSources, config);

to get the list of source files and then filter it based on
sf->GetLanguage().

The name "" is not very good because it does not specify
how any filtering is done.  Perhaps a special case name such as
"" would be better.

Do we know that there is a one-to-one mapping between libraries
and Swift modules?

-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

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

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15919 
== 
Reported By:qiv
Assigned To:
== 
Project:CMake
Issue ID:   15919
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-14 10:11 EST
Last Modified:  2016-01-14 10:11 EST
== 
Summary:Building CUDA files fails when source path contains
parenthesis
Description: 
When working in a source path containing "()" I get the following error upon
building CUDA files:

15:13 sandbox$ make
[  6%] Building NVCC (Device) object
CMakeFiles/githash.dir//./githash_generated_float3.cu.o
/bin/sh: 1: Syntax error: "(" unexpected
CMakeFiles/githash.dir/build.make:167: recipe for target
'CMakeFiles/githash.dir/./githash_generated_float3.cu.o' failed
make[2]: *** [CMakeFiles/githash.dir/./githash_generated_float3.cu.o] Error 2
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/githash.dir/all' failed
make[1]: *** [CMakeFiles/githash.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2


The following fix provided by ngladitz in #cmake solves the issue on my machine:

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index ada5b8a..fe2647a 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -1474,6 +1474,7 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
   -P "${custom_target_script}"
 WORKING_DIRECTORY "${cuda_compile_intermediate_directory}"
 COMMENT "${cuda_build_comment_string}"
+VERBATIM
 )
 
   # Make sure the build system knows the file is generated.

Steps to Reproduce: 
16:06 sandbox$ cat CMakeLists.txt 
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(githash)

FIND_PACKAGE(CUDA REQUIRED)
# FIND_PACKAGE(MPI REQUIRED)

INCLUDE(FindCUDA)

# INCLUDE_DIRECTORIES(/usr/local/cuda/include ${MPI_INCLUDE_PATH})

FILE(GLOB SOURCES "*.cu" "*.cpp" "*.c" "*.h")
CUDA_ADD_EXECUTABLE(githash ${SOURCES})

LIST(APPEND CMAKE_CXX_FLAGS "-std=c++0x -O3 -ffast-math -Wall")

LIST(APPEND CUDA_NVCC_FLAGS --compiler-options -fno-strict-aliasing -lineinfo
-use_fast_math -Xptxas -dlcm=cg)
# LIST(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_20,code=sm_20)
LIST(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_30,code=sm_30)
# LIST(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_35,code=sm_35)

# TARGET_LINK_LIBRARIES(githash /usr/local/cuda/lib64/libcudart.so
${MPI_LIBRARIES})


15:13 sandbox$ cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/.../Dropbox (CRG)/.../sandbox
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-14 10:11 qivNew Issue
==

-- 

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

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

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15920 
== 
Reported By:R Jones
Assigned To:
== 
Project:CMake
Issue ID:   15920
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-14 10:32 EST
Last Modified:  2016-01-14 10:32 EST
== 
Summary:Tests fail
Description: 
98% tests passed, 7 tests failed out of 410

Label Time Summary:
Label1=   0.35 sec (1 test)
Label2=   0.35 sec (1 test)

Total Test time (real) = 4137.46 sec

The following tests FAILED:
115 - BuildDepends (Failed)
173 - CTestTestUpload (Failed)
174 - CTestCoverageCollectGCOV (Failed)
193 - CMakeCommands.target_link_libraries (Failed)
223 - Fortran (Failed)
327 - RunCMake.ctest_submit (Failed)
372 - RunCMake.IfacePaths_INCLUDE_DIRECTORIES (Failed)

Additional Information: 
What information is needed to diagnose these?  These also fail on 3.3.1.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-14 10:32 R JonesNew Issue
==

-- 

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

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

[Robert Dailey]

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=$config
>> -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"
>
> are you sure you actually want to use the KDevelop3 generator ?
> This is for the KDE3 version, and you are probably using the KDE4 version of
> KDevelop ? For that you don't need these generated project files.
>
> Actually I was thinking about removing this generator, because KDevelop3 is
> really really old, not sure whether it is still available in current Linux
> distributions.

This might explain it. I just installed kdevelop on Ubuntu 15, not
sure what version it is using. I also have never used kdevelop before
so I was not aware that it had built in support for CMake. I saw it in
the list of generators so I naturally assumed I had to use it. Note
that Eclipse is in kind of the same boat, as far as which versions it
supports and its not immediately obvious.
-- 

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

Re: [cmake-developers] CMake alternative language

[J Decker]

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 understand that it would be difficult' but ... not
really, if the first word isn't a 'keyword' (Function/Macro name) then
if the next token is a = instead of a ( then assume it's a SET 

-
Re: "no return values for functions"  that's not true... this script
sets the return value just fine...

---
cmake_minimum_required( VERSION 3.0 )

macro( SomeFunc ReturnVal )
   set( ${ReturnVal} SomeResult )
endmacro( SomeFunc )

SomeFunc( RetVal )
message( "and we have a result of " ${RetVal} )

output : and we have a result of SomeResult

-
J/K : I think the alternative language should be LISP; oh wait that's
already what it is. other than the function is outside of the parens

One of the last comments mentioned something about the named
parameters passed to methods like

SET_TARGET_PROPERTIES(${project} PROPERTIES
  FOLDER utils
  COMPILE_DEFINTIIONS "SomeOtherSyms"
)

Is at first a little confusing... but at least I don't have some
required order where I have to isnert a bunch of blank ',,' to get
to the option I want to use.

It might be nice if there were methods to define your own syntax for
these things for use in passing options to MACRO where as you iterate
through the ARGN members it can trigger some sort of state table
lookup/dispatch... but then I really don't have a use for such a thing
in the reality of switching to cmake maybe 5 years ago.

Re: Profile-ability of CMake.  I haven't yet found anywhere that I
would blame any part of the build process slowness on CMAKE, but
rather on the build tools themselves (CygWin or MinGW for instances).
Although... there is One project I often rebuild (OpenAL) which uses a
bunch of CHECK_FUNCTION_EXISTS(snprintf HAVE_SNPRINTF) which seems to
be pretty slow.   But Really, I think the target rules would be better
to test CMAKE_COMPILER_IS_ and WIN32/UNIX variables to get that
result.  There's certainly less permutations to test that way than
testing for each function that might exist; since the variations are
limited to environments (each generator) with perhaps a minor off case
for some toolchains.  But I guess that was put in to satisy autotool
people coming to a different build system.
-- 

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