Re: [CMake] find_library

[Chuck Atkins]

Hi Vania,

 find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>

In this first call, SYSTEMC_PATH is being dereferenced as a CMake
variable.  This works because in your invocation of CMake:

cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/
>

You define the CMake variable with -D on the command line

 However, in your second call

>  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>

the PATHS ENV SYSTEMC_PATH arguments specify that SYSTEMC_PATH be
dereferenced as an environment variable, not a CMake variable.  This is
equivalent to PATHS "$ENV{SYSTEMC_PATH}"
-- 

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

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] Update/Set _expectedTargets inside exports-release.cmake.

[Rashad Kanavath]

Hello Stephen,

On Tue, Jan 12, 2016 at 8:58 PM, Stephen Kelly  wrote:

> Rashad Kanavath wrote:
>
> > I am having this when I build packages for debian where I split
> components
> > into separate packages project1-core, project1-gui etc..
>
> I think you need to patch the buildsystems of the software you are
> packaging
> so that they support that kind of split by exporting to a different export-
> set per split component.
>
> ie:
>
> install(TARGETS project1-core EXPORT CoreExports ...)
> install(TARGETS project1-gui EXPORT GuiExports ...)
> install(TARGETS project1-network EXPORT NetworkExports ...)
>

Thanks for your reply. I will check with upstream if this is possible to
have such a modification.

If there is some cmake way without modifying upstream I would prefer that.


>
> and put conditional includes for the resulting files in the
> Project1Config.cmake file.
>
> 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
>



-- 
Regards,
   Rashad
-- 

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

Re: [CMake] using macros

[Petr Kmoch]

Hi Owen.

As a sanity check, the definition of the macro in the toplevel CMakeList
comes *before* the add_subdirectory() command for the one which errors out,
right?

Petr

On Thu, Jan 14, 2016 at 8:25 AM, Owen Hogarth II 
wrote:

> I am trying to use a macro to enable c99 in some of my cmake modules.
>
> In the top level cmake file I add this macro
>
> macro(use_c99)
>   if (CMAKE_VERSION VERSION_LESS "3.1")
> if (CMAKE_C_COMPILER_ID STREQUAL "GNU")
>   set (CMAKE_C_FLAGS "--std=gnu99 ${CMAKE_C_FLAGS}")
> endif ()
>   else ()
> set (CMAKE_C_STANDARD 99)
>   endif ()
> endmacro(use_c99)
>
> then in another CMakeLists.txt file I add
> use_c99()
>
> but I get this error:
>
> CMake Error at source/internal_src/cube/CMakeLists.txt:1 (use_c
> 99):
>   Unknown CMake command "use_c99".
>
> why am I unable to use the macro? My main cmake is using 3.0.2 from debian
> repository.
>
>
> --
>
> 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
>
-- 

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

[CMake] find_library

[Vania Joloboff]

I am running cmake 3.2.2 on Linux 64 bits

I run cmake with

 cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/

In my CMakeLists.txt,

If I put

 find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
  PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)

it works.

If I put
 find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
  PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)

which I think should be identical, I get error
CMake Error at CMakeLists.txt:28 (message):
  ERROR: SYSC_LIB-NOTFOUND

Can anyone explain the difference and why the second does not work ?

btw

find_library(SYSC_LIB NAMES systemc foobar PATHS "${SYSTEMC_PATH}"
   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)

 also works
and
find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
  PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64
  NO_DEFAULT_PATH)
also fails

At least it is consistent :-(

Thanx

--

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

Re: [CMake] find_library

[CHEVRIER, Marc]

Defining a variable using -D option does not put this one in the environment 
(i.e. system environment) so using ENV will fails...




On 14/01/16 10:28, "CMake on behalf of Vania Joloboff"  wrote:

>I am running cmake 3.2.2 on Linux 64 bits
>
>I run cmake with
>
>  cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/
>
>In my CMakeLists.txt,
>
>If I put
>
>  find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>it works.
>
>If I put
>  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>which I think should be identical, I get error
>CMake Error at CMakeLists.txt:28 (message):
>   ERROR: SYSC_LIB-NOTFOUND
>
>Can anyone explain the difference and why the second does not work ?
>
>btw
>
>find_library(SYSC_LIB NAMES systemc foobar PATHS "${SYSTEMC_PATH}"
>PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>  also works
>and
> find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64
>   NO_DEFAULT_PATH)
>also fails
>
>At least it is consistent :-(
>
>Thanx
>
>-- 
>
>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
-- 

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

[CMake] Fwd: FILE(UPLOAD) doesn't seem to respect custom CA settings while DOWNLOAD does

[Sergey Zakharchenko]

Hello,

I'm trying to get CMake to talk to an SSL server using a self-signed
certificate. It works just fine with downloads. The certificate path
appears in the LOG:

successfully set certificate verify locations:
  CAfile: /path/to/my/certificate.pem
  CApath: /etc/ssl/certs

and the TLS handshake succeeds. However, it doesn't seem to work with
UPLOAD (note CAfile is 'none'):

successfully set certificate verify locations:
  CAfile: none
  CApath: /etc/ssl/certs
SSLv3, TLS handshake, Client hello (1):
[512 bytes data]
SSLv3, TLS handshake, Server hello (2):
[66 bytes data]
SSLv3, TLS handshake, CERT (11):
[5986 bytes data]
SSLv3, TLS alert, Server hello (2):
[2 bytes data]
SSL certificate problem: self signed certificate in certificate chain

Neither setting CMAKE_TLS_CAINFO to point to the certificate, nor
adding a TLS_CAINFO argument work. Is there anything I'm missing?

I'm using CMake version 3.4.1.

Best regards,

--
DoubleF
-- 

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

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 

[Cmake-commits] CMake branch, next, updated. v3.4.1-1958-ge584aa9

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  e584aa916a85ec45a19e751e2c224b97231ff02e (commit)
   via  a7393cbd40b4387d352413c48cec36b9d3cd0b51 (commit)
  from  0a9d80385666d819587a5761d0a1f4a9f9e1edfa (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e584aa916a85ec45a19e751e2c224b97231ff02e
commit e584aa916a85ec45a19e751e2c224b97231ff02e
Merge: 0a9d803 a7393cb
Author: Brad King 
AuthorDate: Thu Jan 14 11:20:33 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 11:20:33 2016 -0500

Merge topic 'report_failed_tests' into next

a7393cbd ctest_test: Report which tests failed even when QUIET is used


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7393cbd40b4387d352413c48cec36b9d3cd0b51
commit a7393cbd40b4387d352413c48cec36b9d3cd0b51
Author: Zack Galbreath 
AuthorDate: Wed Jan 13 09:49:40 2016 -0500
Commit: Brad King 
CommitDate: Wed Jan 13 10:32:24 2016 -0500

ctest_test: Report which tests failed even when QUIET is used

Since commit v3.3.0-rc1~410^2~3 (ctest_test: Add QUIET option,
2015-02-17) if tests fail when QUIET is used one sees:

  The following tests FAILED:

but not the subsequent line(s) indicating which tests failed.
Restore the list of failed tests.

diff --git a/Source/CTest/cmCTestTestHandler.cxx 
b/Source/CTest/cmCTestTestHandler.cxx
index a8f983f..b6a4819 100644
--- a/Source/CTest/cmCTestTestHandler.cxx
+++ b/Source/CTest/cmCTestTestHandler.cxx
@@ -609,11 +609,11 @@ int cmCTestTestHandler::ProcessHandler()
 if ( ftit->Status != cmCTestTestHandler::COMPLETED )
   {
   ofs << ftit->TestCount << ":" << ftit->Name << std::endl;
-  cmCTestOptionalLog(this->CTest, HANDLER_OUTPUT, "\t" << std::setw(3)
+  cmCTestLog(this->CTest, HANDLER_OUTPUT, "\t" << std::setw(3)
  << ftit->TestCount << " - "
  << ftit->Name << " ("
  << this->GetTestStatus(ftit->Status) << ")"
- << std::endl, this->Quiet);
+ << std::endl);
   }
 }
   }

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] finding if feature is supported by host

[Petr Kmoch]

Hi Vania.

A quick look a CMake docs will show you CMake's try_compile() command:
https://cmake.org/cmake/help/latest/command/try_compile.html
(There is also a try_run(), if required).

I believe that's precisely what you want.

Petr

On Thu, Jan 14, 2016 at 5:44 PM, Vania Joloboff 
wrote:

> Hi
>
> I can find if an include file exists with CHECK_INCLUDE_FILE
> But I want to know if a particular feature is supported
> in our case we need to know if the mmap call exists
> and whether it supports the MAP_ANONYMOUS feature
> With autoconf, I can use AC_TRY_COMPILE to try compiling
> a program using the feature.
> Is there some equivalent in cmake ?
>
> Or I have to build my own TRY_COMPILE command to check if a feature
> is supported by a particular function call ?
>
> Thanks
>
>
> --
>
> 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
>
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-837-g6e1a3df

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  6e1a3df0c7d570ae560fc39fae17de839fe2f3e6 (commit)
   via  7a37afa7e709bb1134ad7fb058195bc85f261b87 (commit)
  from  9cf63886985f39bb364e620e4459252b9ba8072a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e1a3df0c7d570ae560fc39fae17de839fe2f3e6
commit 6e1a3df0c7d570ae560fc39fae17de839fe2f3e6
Merge: 9cf6388 7a37afa
Author: Brad King 
AuthorDate: Thu Jan 14 11:42:23 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 11:42:23 2016 -0500

Merge topic 'bootstap-system-liblzma'

7a37afa7 bootstrap: Add option to build with system liblzma (#15916)


---

Summary of changes:
 bootstrap |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.4.1-835-g9cf6388

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  9cf63886985f39bb364e620e4459252b9ba8072a (commit)
   via  630c8aa8435fced988545d396714398faa3426b1 (commit)
  from  6be2dedaedec4d6df7844119d2e4954535d66ad2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cf63886985f39bb364e620e4459252b9ba8072a
commit 9cf63886985f39bb364e620e4459252b9ba8072a
Merge: 6be2ded 630c8aa
Author: Brad King 
AuthorDate: Thu Jan 14 11:42:20 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 11:42:20 2016 -0500

Merge topic 'install-DIRECTORY-genex'

630c8aa8 install: Allow generator expressions in DIRECTORY


---

Summary of changes:
 Help/command/install.rst   |7 ++---
 Help/release/dev/install-DIRECTORY-genex.rst   |6 +
 Source/cmInstallDirectoryGenerator.cxx |   28 +---
 Source/cmInstallDirectoryGenerator.h   |3 ++-
 Tests/ExportImport/Export/CMakeLists.txt   |2 +-
 .../DIRECTORY-DIRECTORY-bad-result.txt}|0
 .../DIRECTORY-DIRECTORY-bad-stderr.txt}|0
 .../RunCMake/install/DIRECTORY-DIRECTORY-bad.cmake |1 +
 Tests/RunCMake/install/RunCMakeTest.cmake  |1 +
 Tests/SimpleInstall/CMakeLists.txt |4 +--
 Tests/SimpleInstallS2/CMakeLists.txt   |4 +--
 11 files changed, 43 insertions(+), 13 deletions(-)
 create mode 100644 Help/release/dev/install-DIRECTORY-genex.rst
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
install/DIRECTORY-DIRECTORY-bad-result.txt} (100%)
 copy Tests/RunCMake/{XcodeProject/XcodeAttributeGenexError-stderr.txt => 
install/DIRECTORY-DIRECTORY-bad-stderr.txt} (100%)
 create mode 100644 Tests/RunCMake/install/DIRECTORY-DIRECTORY-bad.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.4.1-839-gf3fd50a

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  f3fd50ad4b4252c42de55657074ca0b84f97a83c (commit)
   via  a7393cbd40b4387d352413c48cec36b9d3cd0b51 (commit)
  from  6e1a3df0c7d570ae560fc39fae17de839fe2f3e6 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3fd50ad4b4252c42de55657074ca0b84f97a83c
commit f3fd50ad4b4252c42de55657074ca0b84f97a83c
Merge: 6e1a3df a7393cb
Author: Brad King 
AuthorDate: Thu Jan 14 11:42:26 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 11:42:26 2016 -0500

Merge topic 'report_failed_tests'

a7393cbd ctest_test: Report which tests failed even when QUIET is used


---

Summary of changes:
 Source/CTest/cmCTestTestHandler.cxx |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.4.1-1963-g358f772

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  358f7727f9b30ab91b65905ed7812e216b172466 (commit)
   via  f3fd50ad4b4252c42de55657074ca0b84f97a83c (commit)
   via  6e1a3df0c7d570ae560fc39fae17de839fe2f3e6 (commit)
   via  9cf63886985f39bb364e620e4459252b9ba8072a (commit)
   via  6be2dedaedec4d6df7844119d2e4954535d66ad2 (commit)
  from  e584aa916a85ec45a19e751e2c224b97231ff02e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=358f7727f9b30ab91b65905ed7812e216b172466
commit 358f7727f9b30ab91b65905ed7812e216b172466
Merge: e584aa9 f3fd50a
Author: Brad King 
AuthorDate: Thu Jan 14 11:42:34 2016 -0500
Commit: Brad King 
CommitDate: Thu Jan 14 11:42:34 2016 -0500

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1967-g24fcf2e

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  24fcf2ef037e50eb375f8e0d5e49a7658273f230 (commit)
   via  4b24626e0096f5bf6d57b5861a2eb001067c8f89 (commit)
  from  8810997b9bcabc895f99f0b68e5a96515831189e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24fcf2ef037e50eb375f8e0d5e49a7658273f230
commit 24fcf2ef037e50eb375f8e0d5e49a7658273f230
Merge: 8810997 4b24626
Author: Brad King 
AuthorDate: Thu Jan 14 13:29:21 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 13:29:21 2016 -0500

Merge topic 'FindDCMTK-update' into next

4b24626e FindDCMTK: Simplify documentation.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b24626e0096f5bf6d57b5861a2eb001067c8f89
commit 4b24626e0096f5bf6d57b5861a2eb001067c8f89
Author: Matt McCormick 
AuthorDate: Wed Jan 13 10:53:03 2016 -0500
Commit: Brad King 
CommitDate: Thu Jan 14 13:28:56 2016 -0500

FindDCMTK: Simplify documentation.

diff --git a/Modules/FindDCMTK.cmake b/Modules/FindDCMTK.cmake
index 1238616..63d253d 100644
--- a/Modules/FindDCMTK.cmake
+++ b/Modules/FindDCMTK.cmake
@@ -1,6 +1,7 @@
 #.rst:
 # FindDCMTK
 # -
+#
 # Find DCMTK libraries and applications
 #
 # The module defines the following variables::
@@ -10,32 +11,29 @@
 #  DCMTK_FOUND - If false, don't try to use DCMTK
 #  DCMTK_DIR   - (optional) Source directory for DCMTK
 #
-# `DCMTK_DIR` can be used to make it simpler to find the various include
-# directories and compiled libraries if you've just compiled it in the
-# source tree. Just set it to the root of the tree where you extracted
-# the source (default to `/usr`)
-#
-#
-# This file is able to find version of DCMTK that does or does not export
-# a *DCMTKConfig.cmake* file.
+# Compatibility
+# ^
 #
-# .. important::
-#   A set of patches has been contributed to DCMTK
-#   maintainers and merged upstream. As soon as:
+# This module is able to find a version of DCMTK that does or does not export
+# a *DCMTKConfig.cmake* file. It applies a two step process:
 #
-#   1) it has been integrated upstream so that it is available in
-#   an official release (for example X.Y.Z),
-#   2) code bases have been updated to build against X.Y.Z
+# * Step 1:  Attempt to find DCMTK version providing a *DCMTKConfig.cmake* 
file.
+# * Step 2:  If step 1 failed, rely on *FindDCMTK.cmake* to set `DCMTK_*` 
variables details below.
 #
-#   This file could be removed.
 #
-#   The set of patches is listed here: 
https://github.com/commontk/DCMTK/compare/79030ba...f461865
+# `Recent DCMTK
+# 
`_
+# provides a *DCMTKConfig.cmake* :manual:`package configuration file
+# `. To exclusively use the package configuration file
+# (recommended when possible), pass the `NO_MODULE` option to
+# :command:`find_package`. For example, `find_package(DCMTK NO_MODULE)`.
+# This requires official DCMTK snapshot *3.6.1_20140617* or newer.
 #
 #
-# Waiting for this to happen, build systems will have to be able
+# Until all clients update to the more recent DCMTK, build systems will need
 # to support different versions of DCMTK.
 #
-# On any given system, the following combination of DCMTK version could be
+# On any given system, the following combinations of DCMTK versions could be
 # considered:
 #
 # ++-+---+---+
@@ -69,34 +67,14 @@
 #   [X] DCMTKConfig ..: Means that the version of DCMTK exports a 
DCMTKConfig.cmake file.
 #
 #
-# It is a two step process:
-#
-# * Step 1:  Attempt to find DCMTK version providing a DCMTKConfig.cmake file. 
This is done with the help of `''`
-# * Step 2:  If step 1 failed, rely on FindDCMTK.cmake to set DCMTK_* 
variables details below.
-#
 # Troubleshooting
 # ^^^
 #
 # What to do if my project finds a different version of DCMTK?
 #
-# Remove DCMTK entry from the CMake registry per :command:`find_package`
+# Remove DCMTK entry from the CMake cache per :command:`find_package`
 # documentation.
-#
-# Details
-# ^^^
-#
-# At some point, the DCMTK build tree was exported [1][2][3]. Indeed, before 
the set of
-# patches discussed above has been contributed to upstream DCMTK, an initial 
implementation of
-# a DCMTK build system exporting its build tree has been implemented and has 
been tested by some
-# folks. This had the effect of populating the CMake registry.
-#
-# Since Step1 does not 

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

[CMake] Interesting behavior of MAIN_DEPENDENCY in makefiles

[James Bigler]

Say you have a simple cpp file:

cat > test.cpp
int main() { return 0; }

Then you have this as your CMakeLists.txt file:

set(input_file test.cpp)
set(generated_file
${CMAKE_CURRENT_BINARY_DIR}/${input_file}.blah${CMAKE_CXX_OUTPUT_EXTENSION})
add_custom_command(
  OUTPUT ${generated_file}
  COMMAND c++ -c ${CMAKE_CURRENT_SOURCE_DIR}/${input_file} -o
${generated_file}
  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${input_file}
  #DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${input_file}
  COMMENT "Building ${generated_file} using custom command."
  )
add_executable(test_b ${generated_file} ${input_file})
#add_executable(test_b ${generated_file} )
set_target_properties(test_b PROPERTIES LINKER_LANGUAGE CXX)

add_executable(test_cxx test.cpp)

If I put test.cpp as the MAIN_DEPENDENCY then add_executable(test_cxx
test.cpp) fails to compile an object file to link in.

If I change MAIN_DEPENDENCY to DEPENDS, then the add_executable(test_b
${generated_file} ${input_file}) will end up compiling test.cpp into an
object file twice (when it only did it once before).

Can anyone explain why this is so?  It seems like weird behavior.

Thanks,
James
-- 

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

[CMake] Last Call for Papers: GCIRE2016 - Philippines

[Jackie Blanco]

The Second International Conference on Green Computing, Intelligent and 
Renewable Energies (GCIRE2016)


University of Perpetual Help System DALTA
Las Piñas-Manila, Philippines
February 24-26, 2016

http://sdiwc.net/conferences/gcire2016/
gcir...@sdiwc.net
===
The event will be held over three days with presentations delivered by 
researchers from the international community, including presentations 
from keynote speakers and state-of-the-art lectures. All registered 
papers will be included in the SDIWC Digital Library and in one of the 
following special issues:


- International Journal of Cyber-Security and Digital Forensics (IJCSDF)
- International Journal of Digital Information and Wireless 
Communications (IJDIWC)
- International Journal of New Computer Architectures and their 
Applications (IJNCAA)
- International Journal of E-Learning and Educational Technologies in 
the Digital Media (IJEETDM)


SUBMISSION GUIDELINES:

- Researchers are encouraged to submit their work electronically as pdf 
format without author(s) name.

- Full paper must be submitted (abstracts are not acceptable).
- Submitted paper should not exceed 15 pages, including illustrations 
and must be without page numbers.
- Paper submission link: 
http://sdiwc.net/conferences/gcire2016/paper-submission/


IMPORTANT DATES:

Submission Deadline:January 24, 2016
Acceptance Notification:2-3 weeks from the submission date or Feb. 3, 
2016

Camera Ready Deadline:  February 14, 2016
Registration Deadline:  February  14, 2016
Conference Dates:   February  24 - 26, 2016
--

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-847-gb8d002a

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  b8d002af1aeefb435a9560b056f081e5d8dff734 (commit)
  from  43a32bdff6b452016a9b59224cd83e3c79c58e28 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8d002af1aeefb435a9560b056f081e5d8dff734
commit b8d002af1aeefb435a9560b056f081e5d8dff734
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Jan 15 00:01:07 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Jan 15 00:01:07 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index ea95862..17ed248 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20160114)
+set(CMake_VERSION_PATCH 20160115)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

Re: [CMake] Changing the the current generator in CMake GUI

[mozzis]

I was able to edit CMakeCache.txt and CPackConfig.cmake (with CMake GUI
closed)
 I changed 
  CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 Win64 
to
  CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010

and then in general looked for the string "64" and made appropriate changes.
I then started CMake GUI, noted that the "Current Generator" was to my
liking, and did Configure and Generate steps again.

All in all, doesn't seem that it would be too hard for CMake devs to
implement a function to do this, but IMO Cmake is a mistake anyway, I only
use it when forced (e.g., OpenCV.) CMake butchers MS Visual Studio project
files, and makes it much harder to maintain projects that use it. Which I
guess is kind of the opposite of the intended effect. More intelligent use
of existing macros for both make and MSVS would go a long way to making it
useful.



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592486.html
Sent from the CMake mailing list archive at Nabble.com.
-- 

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

[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] Changing the the current generator in CMake GUI

[Bill Hoffman]

On 1/14/2016 3:02 PM, mozzis wrote:

I was able to edit CMakeCache.txt and CPackConfig.cmake (with CMake GUI
closed)
  I changed
   CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 Win64
to
   CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010

and then in general looked for the string "64" and made appropriate changes.
I then started CMake GUI, noted that the "Current Generator" was to my
liking, and did Configure and Generate steps again.
You can not change the generator.  It is better to remove the entire 
build tree.  Out of source builds are a best practice with CMake.  Once 
a build tree has been configured with one compiler, it must be 
completely removed to change to a new compiler.  You are changing from 
32 bit to 64 bit, this means that all the try-compile stuff needs to be 
re-run as the answers are likely to be different.


All in all, doesn't seem that it would be too hard for CMake devs to
implement a function to do this, but IMO Cmake is a mistake anyway, I only
use it when forced (e.g., OpenCV.) CMake butchers MS Visual Studio project
files, and makes it much harder to maintain projects that use it. Which I
guess is kind of the opposite of the intended effect. More intelligent use
of existing macros for both make and MSVS would go a long way to making it
useful.
Thanks for the praise...  :)   CMake creates VS projects that should 
work to build the project that is the goal. I don't understand about 
make and MSVS, CMake can create makefiles or ninja files if that is what 
you are talking about.


-Bill
--

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

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

[CMake] How do I create targets first and add sources later?

[Nicholas Braden]

I often find it more convenient to call add_library() and
add_executable() first, apply properties to them etc., and then later
add the sources to them with target_sources() (usually in other CMake
files via add_subdirectory). Obviously, all my targets will eventually
have sources added.

However, CMake completely errors out as soon as it sees me creating a
target with no sources - it doesn't even care that I am adding sources
to it later. Example:
"You have called ADD_LIBRARY for library mylib without any source
files. This typically indicates a problem with your CMakeLists.txt
file"

I have been working around this by adding a dummy source file or
adding one of the sources ahead of time, but this is somewhat
inconvenient.

Is there a better way to do this? Alternatively, could CMake be
changed to allow creating a target that initially has no sources as
long as it eventually has sources added to it?

Note: I am familiar with the approach of gathering a list of source
files before creating the target, but this is really inconvenient to
do across multiple files in multiple directories. It is easier to call
target_sources() instead.
-- 

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1965-g8810997

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  8810997b9bcabc895f99f0b68e5a96515831189e (commit)
   via  6e0739808514591e9a1cee0ca78aa1da17f52a86 (commit)
  from  358f7727f9b30ab91b65905ed7812e216b172466 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8810997b9bcabc895f99f0b68e5a96515831189e
commit 8810997b9bcabc895f99f0b68e5a96515831189e
Merge: 358f772 6e07398
Author: Brad King 
AuthorDate: Thu Jan 14 13:27:58 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 13:27:58 2016 -0500

Merge topic 'FindDCMTK-update' into next

6e073980 fixup! FindDCMTK: Add compatibility table to documentation.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e0739808514591e9a1cee0ca78aa1da17f52a86
commit 6e0739808514591e9a1cee0ca78aa1da17f52a86
Author: Brad King 
AuthorDate: Thu Jan 14 13:27:42 2016 -0500
Commit: Brad King 
CommitDate: Thu Jan 14 13:27:42 2016 -0500

fixup! FindDCMTK: Add compatibility table to documentation.

diff --git a/Modules/FindDCMTK.cmake b/Modules/FindDCMTK.cmake
index dc663b5..63d253d 100644
--- a/Modules/FindDCMTK.cmake
+++ b/Modules/FindDCMTK.cmake
@@ -1,6 +1,7 @@
 #.rst:
 # FindDCMTK
 # -
+#
 # Find DCMTK libraries and applications
 #
 # The module defines the following variables::
@@ -71,9 +72,9 @@
 #
 # What to do if my project finds a different version of DCMTK?
 #
-# Remove DCMTK entry from the CMake registry per :command:`find_package`
+# Remove DCMTK entry from the CMake cache per :command:`find_package`
 # documentation.
-#
+
 #=
 # Copyright 2004-2009 Kitware, Inc.
 # Copyright 2009-2010 Mathieu Malaterre 

---

Summary of changes:
 Modules/FindDCMTK.cmake |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.4.1-846-g43a32bd

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  43a32bdff6b452016a9b59224cd83e3c79c58e28 (commit)
   via  4b24626e0096f5bf6d57b5861a2eb001067c8f89 (commit)
   via  361c199ff602d492d4261f0387d84913a0989473 (commit)
   via  d790f4feeadc863d47ffec9d901d4bf5519001df (commit)
   via  8c8e53d06011ef476780d10601adac78baf8aead (commit)
   via  d50cbbb03d53da6b990402a482a56b3163807dcb (commit)
   via  31b4700ed640bee962f9db9ce25fa84261a944d2 (commit)
  from  f3fd50ad4b4252c42de55657074ca0b84f97a83c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43a32bdff6b452016a9b59224cd83e3c79c58e28
commit 43a32bdff6b452016a9b59224cd83e3c79c58e28
Merge: f3fd50a 4b24626
Author: Brad King 
AuthorDate: Thu Jan 14 13:30:31 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 14 13:30:31 2016 -0500

Merge topic 'FindDCMTK-update'

4b24626e FindDCMTK: Simplify documentation.
361c199f FindDCMTK: Add reStructuredText formatting.
d790f4fe FindDCMTK: Keep original copyright notice.
8c8e53d0 FindDCMTK: Minor documentation grammatical issues.
d50cbbb0 FindDCMTK: Obey QUIET option for find_package.
31b4700e FindDCMTK: Improve compatibility with DCMTKConfig.cmake.


---

Summary of changes:
 Modules/FindDCMTK.cmake |  275 +++
 1 file changed, 229 insertions(+), 46 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1969-gaea52d2

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  aea52d2033f3e17ba11af70fb6d264e8637a8deb (commit)
   via  43a32bdff6b452016a9b59224cd83e3c79c58e28 (commit)
  from  24fcf2ef037e50eb375f8e0d5e49a7658273f230 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aea52d2033f3e17ba11af70fb6d264e8637a8deb
commit aea52d2033f3e17ba11af70fb6d264e8637a8deb
Merge: 24fcf2e 43a32bd
Author: Brad King 
AuthorDate: Thu Jan 14 13:30:41 2016 -0500
Commit: Brad King 
CommitDate: Thu Jan 14 13:30:41 2016 -0500

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[CMake] finding if feature is supported by host

[Vania Joloboff]

Hi

I can find if an include file exists with CHECK_INCLUDE_FILE
But I want to know if a particular feature is supported
in our case we need to know if the mmap call exists
and whether it supports the MAP_ANONYMOUS feature
With autoconf, I can use AC_TRY_COMPILE to try compiling
a program using the feature.
Is there some equivalent in cmake ?

Or I have to build my own TRY_COMPILE command to check if a feature
is supported by a particular function call ?

Thanks


--

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

[CMake] cdash/ctest question

[Biddiscombe, John A.]

Apologies for posting a cdash question question to the cmake list…

CDash plots the run-time of tests, which is very useful indeed, but it would be 
even more useful if one could output a performance related ‘time’ from a test 
where a specific feature was being benchmarked and one could see how it changes 
over a period of days/weeks/months as changes to code are being made.
The time would be specific to the tested code and not include startup and other 
uninteresting overheads (such as when the filesystem is misbehaving and the 
test starts slowly).

Does such a feature exist in ctest/cdash at all?

Thanks

JB

--
John Biddiscombe,email:biddisco @.at.@ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82

-- 

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

[CMake] Create both Windows UWP project and old Win32 console project in same solution.

[Chad Vernon]

Hello,

Is there a way to create both a Windows UWP project and an old Win32
console project in same solution?  I have a toolchain file that sets
CMAKE_SYSTEM_NAME to WindowsStore in order to create the UWP project, but
then any other add_executable call will also create a Windows 10 project.

I want to add a Native C++ Unit Test project to the solution but it always
ends up as a Windows 10 project.  I tried setting CMAKE_SYSTEM_NAME for the
specific project, but it did not do anything.

Thank you.
-- 

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

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

Re: [CMake] cdash/ctest question

[Alexander Neundorf]

On Thursday, January 14, 2016 21:51:23 Biddiscombe, John A. wrote:
> Apologies for posting a cdash question question to the cmake list…
> 
> CDash plots the run-time of tests, which is very useful indeed, but it would
> be even more useful if one could output a performance related ‘time’ from a
> test where a specific feature was being benchmarked and one could see how
> it changes over a period of days/weeks/months as changes to code are being
> made.
> The time would be specific to the tested code and not include
> startup and other uninteresting overheads (such as when the filesystem is
> misbehaving and the test starts slowly). 
> Does such a feature exist in ctest/cdash at all?

yes, we do exactly that.

You have to generate  tags in the stdoutof the test
42
1.23456

and then in cdash you can configure the tests-overview page to display certain 
such measurements by name, and on the tests page you can also display graphs 
for such named measurements.

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