Re: [cmake-developers] CMake, Ninja and Clang on windows?

[Jean-Michaël Celerier]

Hi,
to do this I currently use the following cross-compiling toolchain :
https://github.com/mstorsjo/llvm-mingw

I was able to build Qt (except webstuff since I don't use them) and a large
CMake-based project with it for instance.
Maybe it can be useful ?

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Nov 6, 2018 at 11:57 AM Tobias Hunger 
wrote:

> Hi CMake Developers,
>
> we are currently trying to support Clang (without the -cl;-) on
> Windows. This fails since CMake adds extra compiler flags to the
> command line which are not in the expected format.
>
> Stackoverflow[1] suggests to set CMAKE_SYSTEM_NAME to "Generic" to
> stop that from happening.
>
> The blog post[2] referenced by StackOverflow suggests setting
> CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to TRUE.
>
> Both approaches seem like big hammers to me. Are there better ways to
> get this going that will have less potential side effects?
>
> Best Regards,
> Tobias
>
> [1]:
> https://stackoverflow.com/questions/46553436/building-with-cmake-ninja-and-clang-on-windows#46593308
> [2]:
> https://metricpanda.com/rival-fortress-update-27-compiling-with-clang-on-windows
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers

[CMake] Reason for deprecation of GenerateExportHeader ?

[Jean-Michaël Celerier]

Hello,

the documentation page
https://cmake.org/cmake/help/v3.11/module/GenerateExportHeader.html has the
mention :

> This function is deprecated. Set the target properties
CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN instead.

Why is that so ? I don't know any library that would export either all or
none of its symbols ; functions & types of the public API must always be
chosen manually by the author of the library anyways. The only use of
CXX_VISIBILITY_PRESET is to set the visibility to hidden by default, so
that code can then use the export macros defined by the generate_export _
header code to make specific symbols visible.

Best,
Jean-Michaël

---
Jean-Michaël Celerier
http://www.jcelerier.name
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] -std=c++17 vs -std=c++1y

[Jean-Michaël Celerier]

Note that c++17 is c++1z. c++1y was C++14.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <
andrew.e.brownsw...@gmail.com> wrote:

> Hi,
>
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.
>
> Thanks,
>Andrew
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Removing Transitively Inherited Properties

[Jean-Michaël Celerier]

For stuff like this one you could add -Wno-error afterwards to A's
compile_options.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Feb 6, 2018 at 11:15 AM, Geogin Varghese <geo...@gmail.com> wrote:

> What is the recommended way of removing transitively inherited
> attributes for a target.
>
> Example:
> target_link_libraries(A PRIVATE B)
> target_compile_options(B PUBLIC -Werror)
>
> How should the -Werror option be removed from target A.
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building cmake: why is openssl linked?

[Jean-Michaël Celerier]

https://cmake.org/cmake/help/latest/module/ExternalProject.html

since CMake can download stuff, it needs to support https, hence SSL, hence
OpenSSL

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Jan 14, 2018 at 12:15 AM, Paul Smith <p...@mad-scientist.net> wrote:

> Hi all.
>
> I build CMake myself.  I've noticed that on GNU/Linux by default cmake
> will be linked with openssl and require these shared libraries to be
> available at runtime.
>
> Why does cmake link with these libraries?  I can't think of a reason it
> might need them.  What do I lose in functionality if I force
> CMAKE_USE_OPENSSL to OFF during the build?
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] kwsysProcess threadsafety

[Jean-Michaël Celerier]

> 3) Abandon the idea to parallelize AUTOMOC/UIC

please no ! moc is a huge bottleneck in my builds (to the point that using
verdigris <https://github.com/woboq/verdigris> instead ends up having
faster build time overall).

Best,
Jean-Michaël



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Jan 5, 2018 at 8:34 PM, Sebastian Holtermann <sebl...@xwmw.org>
wrote:

> Hello!
>
> As you might have noticed I tried to parallelize AUTOMOC/UIC.
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1632
> The issue that's blocking it now is that the kwsysProcess framework
> isn't thread safe. As a consequence it is not possible for threads to
> start processes concurrently using the kwsysProcess framework.
>
> There are three options I see
>
> 1) Make kwsysProcess thread safe
>
> I don't think it's impossible but it's not a small task.
> Looking through the code I found a few issues that
> would block the whole idea for me.
>   - OpenVMS: I have little to no knowledge about OpenVMS.
> Wikipedia says it is basically abandoned.
> Can the OpenVMS code be removed? I couldn't test it anyway.
>
>   - C vs. C++
> There's a lot of C in processUNIX.c (list allocation etc.).
> I would prefer to use C++11 (or higher), especially
> std::array, std::vector, std::thread,  std::mutex, etc..
> Is C++11 acceptable in kwsysProcess?
> This would make processUNIX.c processUNIX.cpp?
>
> 2) Use libuv instead
>
> Using the libuv event loop is overkill and would probably imply that
> more threads are started than necessary
> (the libuv thread pool will be started anyway).
> But it would allow to start multiple concurrent  (moc/uic) processes.
> Is there a reason to not use libuv?
>
> 3) Abandon the idea to parallelize AUTOMOC/UIC
>
> Well, I liked the idea.
>
>
> Any thoughts?
>
> -Sebastian
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Native Compilers

[Jean-Michaël Celerier]

> This compilers are alredy intalled with cmake or it needs to install
separetely?

You need to install them separately.

> Another question, when you specify a for example kdevelop files is it
necessary to run at kdevelop to get the executables files?

Yes. The pipeline is like this :


* Give a description of your project in CMakeLists.txt.
* CMake generates a project file for your IDE / environment of choice (this
is because you would have different environments on Mac and Windows for
instance) from CMakeLists.txt.
* Use your IDE / environment to build your software.

Though cmake has the

cmake --build .

command that you can use, which tries to call your environment's build
function.


Best

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Sep 25, 2017 at 8:39 PM, Ivam Pretti <ivamprett...@gmail.com> wrote:

> When you use cmake-gui, below the button configure  there is an option to
> choose the compiler. This compilers are alredy intalled with cmake or it
> needs to install separetely?
>
> Another question, when you specify a for example kdevelop files is it
> necessary to run at kdevelop to get the executables files?
>
> --
>
> 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/opensou
> rce/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] Debugging find_package() search behavior?

[Jean-Michaël Celerier]

> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.

Not always, some people sometimes feel like doing it by hand from scratch
with if(EXISTS ...). Sadly.



On Tue, Aug 29, 2017 at 5:49 PM, Brad King  wrote:

> On 08/29/2017 11:33 AM, David Cole wrote:
> > That's correct:
> >
> > find modules do what they want, and most do not pay attention to
> > CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -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
>
-- 

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] [cmake-developers] Debugging find_package() search behavior?

[Jean-Michaël Celerier]

> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.

Not always, some people sometimes feel like doing it by hand from scratch
with if(EXISTS ...). Sadly.



On Tue, Aug 29, 2017 at 5:49 PM, Brad King  wrote:

> On 08/29/2017 11:33 AM, David Cole wrote:
> > That's correct:
> >
> > find modules do what they want, and most do not pay attention to
> > CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -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
>
-- 

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] Interface Libraries allow include directories but not link directories.. Why?

[Jean-Michaël Celerier]

> Ok got it sorry to hear that certainly because, as soon as I hear
> something that would be useful somehow I end up needing it the next day.
> So sorry for us both.
>
> From what your are saying (and I will take your word for it) the CMake has
> a another problem in not implementing "inherited build properties"
> correctly.  That is of course if that is what CMake is after with
> add_library( targ INTERFACE) in the first place.
>
>
I think that there is just no mechanism for "inherited build properties".
>From the docs (
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries),
INTERFACE targets seems to be meant for header-only libraries.

The "inheritance" mechanism in CMake is mainly setting variables in a given
folder, but this is imho not flexible enough, and leads to problems when
you want to use your library as a subfolder of another since you don't have
an easy way to overwrite "child" variables from a parent scope unless the
child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags
${CMAKE_CXX_FLAGS}") every time.


> Thanks for the heads up on yet more CMake does not do correctly.
>
> I am now climbing upon my "inherited build properties" soap box.  It's
> kinda slippery up here.
>
> On Wed, Aug 23, 2017 at 4:57 PM, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> > Does that work for your needs?
>>
>> Sadly, no (but thanks!). While this is enough for the arguably common use
>> case of include directories, compile flags, etc... there are plenty of
>> things that won't work with this approach.
>>
>> e.g. none of this works for instance:
>>
>> project(foo)
>>
>> add_library(blah INTERFACE)
>> set_property(TARGET blah PROPERTY SUFFIX ".mxe")
>> set_property(TARGET blah PROPERTY CXX_STANDARD 14)
>> set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")
>>
>>
>>
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <bitmi...@gmail.com> wrote:
>>
>>> So there is some odd replies in the cmake mailing list possibly responses 
>>> to wrong message, but this looked like a response to mine even if the 
>>> initial reply to bit is not right from Nicholas.  Anywho here goes:
>>>
>>> @Jean-Michaël Celerier
>>>
>>> -- snip --
>>> >* - Says that custom functions such as add_{project}_library shouldn't be
>>> *used and function definitions should be used as little as possible. Except
>>> this just leads to extremely verbose CMakeLists where repeated properties
>>> are defined again and again and again.
>>> -- snip --
>>>
>>> Yes add_project_library were my own and in the process of being deprecated. 
>>>  These were geared directly at two problems in cmake.
>>>
>>> 1) They were used to get CMake to support the concept of "inherited build 
>>> properties".
>>>
>>> 2) As you stated and is still a problem the verbosity of CMake.  Where IMO 
>>> much could be collaped into one call
>>>
>>>
>>> -- snip --
>>> I also never understood how to handle this.
>>> -- snip --
>>>
>>> I am afraid I don't ultimately have the answer either... I have do some 
>>> ideas on possibly best course of action.
>>>
>>>
>>> -- snip --
>>>  I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
>>> and the SUFFIX property on a specific set of 25 targets amongst ~100
>>> targets. What am I to do ?
>>>
>>> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
>>> would be harder to set / unset on specific targets).
>>> * calling target_compile_options(...) 25 times ... well I mean, everyone
>>> knows it's bad to duplicate code. Especially if the change is meant to be
>>> only when a specific option() is enabled, or for debugging purposes
>>> * creating a function that would set the correct flags, etc and then call
>>> this function for each target is apparently "not modern CMake" either.
>>> * creating and linking to "dummy" INTERFACE targets with the flags and
>>> properties I want have an awful lot of limitations
>>>
>>> So what is the right course of actions here ?
>>> -- snip --
>>>
>>> I have started using add_library( targ INTERFACE ) to imperilment inherited

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

[Jean-Michaël Celerier]

> Does that work for your needs?

Sadly, no (but thanks!). While this is enough for the arguably common use
case of include directories, compile flags, etc... there are plenty of
things that won't work with this approach.

e.g. none of this works for instance:

project(foo)

add_library(blah INTERFACE)
set_property(TARGET blah PROPERTY SUFFIX ".mxe")
set_property(TARGET blah PROPERTY CXX_STANDARD 14)
set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <bitmi...@gmail.com> wrote:

> So there is some odd replies in the cmake mailing list possibly responses to 
> wrong message, but this looked like a response to mine even if the initial 
> reply to bit is not right from Nicholas.  Anywho here goes:
>
> @Jean-Michaël Celerier
>
> -- snip --
> >* - Says that custom functions such as add_{project}_library shouldn't be
> *used and function definitions should be used as little as possible. Except
> this just leads to extremely verbose CMakeLists where repeated properties
> are defined again and again and again.
> -- snip --
>
> Yes add_project_library were my own and in the process of being deprecated.  
> These were geared directly at two problems in cmake.
>
> 1) They were used to get CMake to support the concept of "inherited build 
> properties".
>
> 2) As you stated and is still a problem the verbosity of CMake.  Where IMO 
> much could be collaped into one call
>
>
> -- snip --
> I also never understood how to handle this.
> -- snip --
>
> I am afraid I don't ultimately have the answer either... I have do some ideas 
> on possibly best course of action.
>
>
> -- snip --
>  I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
> and the SUFFIX property on a specific set of 25 targets amongst ~100
> targets. What am I to do ?
>
> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
> would be harder to set / unset on specific targets).
> * calling target_compile_options(...) 25 times ... well I mean, everyone
> knows it's bad to duplicate code. Especially if the change is meant to be
> only when a specific option() is enabled, or for debugging purposes
> * creating a function that would set the correct flags, etc and then call
> this function for each target is apparently "not modern CMake" either.
> * creating and linking to "dummy" INTERFACE targets with the flags and
> properties I want have an awful lot of limitations
>
> So what is the right course of actions here ?
> -- snip --
>
> I have started using add_library( targ INTERFACE ) to imperilment inherited 
> build properties.   Yes the naming convention and use/reuse/misuse of 
> add_library is horrid (library)
>
> I just posted this which may help:
>
> https://cmake.org/pipermail/cmake/2017-August/066119.html
>
> -- snip --
> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin
> for $software", "target Bar is an integration test" and set per-group
> options, flags, properties, etc. Like
>
> add_group(PluginGroup)
> target_compile_definitions(PluginGroup -DBLAH)
> set_property(GROUP PluginGroup PROPERTIES /* whatever in
> cmake-properties*/)
> set_group(myTarget PluginGroup) // applies everything to the target
> -- snip --
>
> I won't have all the syntax for what your trying but possibly try:
>
> add_library( PluginGroupInterface INTERFACE)
> target_compile_definitions(PluginGroupInterface -DBLAH)
> set_property(GROUP PluginGroup PROPERTIES /* whatever in
> cmake-properties*/)
>
> I add interface, Interface, or _interface to my interface targets I use like 
> this.  Note here library in add library does not actually have to have a 
> library (hence my statements to the horrid miss reuse of add_library for this 
> functionality).  It can just have build properties that you want a target to 
> later inherit as far as I understand it or as far as I am miss using it if it 
> is meant to be used some other way.
>
> then...
>
> add_executable( myTarget )
>
> target_link_libraries(
>   myTarget
>   PluginGroupInterface
> )
>
> Does that work for your needs?
>
>
>
> -- snip --
> Best,
>
> ---
> Jean-Michaël Celerier
>
> -- snip --
>
>
> --
>
> 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:
>
> C

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

[Jean-Michaël Celerier]

> - Says that custom functions such as add_{project}_library shouldn't be
used and function definitions should be used as little as possible. Except
this just leads to extremely verbose CMakeLists where repeated properties
are defined again and again and again.

I also never understood how to handle this.

I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
and the SUFFIX property on a specific set of 25 targets amongst ~100
targets. What am I to do ?

* set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
would be harder to set / unset on specific targets).
* calling target_compile_options(...) 25 times ... well I mean, everyone
knows it's bad to duplicate code. Especially if the change is meant to be
only when a specific option() is enabled, or for debugging purposes
* creating a function that would set the correct flags, etc and then call
this function for each target is apparently "not modern CMake" either.
* creating and linking to "dummy" INTERFACE targets with the flags and
properties I want have an awful lot of limitations

So what is the right course of actions here ?

Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin
for $software", "target Bar is an integration test" and set per-group
options, flags, properties, etc. Like

add_group(PluginGroup)
target_compile_definitions(PluginGroup -DBLAH)
set_property(GROUP PluginGroup PROPERTIES /* whatever in
cmake-properties*/)
set_group(myTarget PluginGroup) // applies everything to the target

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Aug 23, 2017 at 1:30 PM, Uwe Koloska <uwe.koloska@voiceinterconnect
.de> wrote:

> On 23.08.2017 11:44, Nicholas Devenish wrote:
> > - But simultaneously advocates rewriting internal functions using the
> > (undocumented?) '_' feature to access "previous definitions". Uses this
> > as one of the few examples of one of the steps as a method to allow a
> > script to change behaviour if being included.
>
> I have raised an issue on this undocumented behavior:
> https://gitlab.kitware.com/cmake/cmake/issues/17199
>
> Regards
> Uwe
>
> --
> Dipl.-Ing. Uwe Koloska
> Chief Software Evangelist
>
> voice INTER connect GmbH   Tel +49 351 407 526 50
> Ammonstraße 35 Fax +49 351 407 526 55
> 01067 Dresden - Germanywww.voiceinterconnect.de
>
> Geschäftsführung:  Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil
> Eingetragen im Handelsregister:   Amtsgericht Dresden HRB 19466
>
> voiceINTERconnect www.voiceinterconnect.de
>  ... smart speech applications from Germany
> --
>
> 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/opensou
> rce/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

Re: [cmake-developers] C++11 all features available?

[Jean-Michaël Celerier]

> Thread support would be nice because Autogen could be parallelized
perfectly.

oh please yes. moc generation is almost 10% of my build time.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann <sebl...@xwmw.org>
wrote:

> Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie:
> > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote:
> > > it looks like C++11 is now a requirement for CMake itself.
> >
> > Yes.  We just merged this:
> >
> >   https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
> >
> > but you beat us to the announcement.
>
> I saw the MR last week and was delighted. The iterator type naming in `for`
> loops drove me mad.
>
> > > But does this mean *all* the nice features from the std library can be
> > > used?
> > Not all.  We're still limited by some of the older C++11 compilers.
> > We'll have to see how things go on nightly builds.  As limitations
> > are found they can be documented in `Help/dev/source.rst`.
> >
> > We will require std::unique_ptr at least.
> >
> > >  - std::array
> >
> > I think so but haven't tried it.
> >
> > >  - std::basic_regex (and friends)
> >
> > We still support GCC 4.8.  IIRC its standard library doesn't have
> > the implementations in place.
>
> That's a pitty, because cmsys::RegularExpression isn't thread safe.
> Although it might be possible to make it so in a reasonable amount of time
>
> > >  - std::thread (and friends)
> >
> > No, at least not yet.  For now we're using libuv's thread primitives
> > instead.  Either way anything that needs to build during bootstrap
> > may not be able to use this.
> >
> > >  - std::atomic_flag
>
> Thread support would be nice because Autogen could be parallelized
> perfectly.
> Only it would require several utility methods to be thread safe as well.
> Many
> likely aren't though. I'll have a look at libuv.
>
> -Sebastian
>
>
> --
>
> 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] C++ IDE

[Jean-Michaël Celerier]

> Visual Studio 2017 has the best C/C++ experience with CMake

IMHO, Visual Studio's CMake integration is a joke in comparison to
QtCreator and CLion.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Aug 18, 2017 at 12:04 PM, Nagy-Egri Máté Ferenc via
cmake-developers <cmake-developers@cmake.org> wrote:

> Impressed with VSCode?? If I saw this post anywhere else than the CMake
> mailing list, I’d understand, but VSCode with CMake is horrible. The fact
> that in 2017 I have to set include directories, compiler definitions and
> target paths manually to have proper IntelliSense (Code navigation and
> syntax higlight) is absurd.
>
>
>
> As far as I saw Visual Studio 2017 has the best C/C++ experience with
> CMake. (Google: Visual Studio Open Folder support with CMake)
>
>
>
> *Feladó: *Wesley Smith <wesley.h...@gmail.com>
> *Elküldve: *2017. augusztus 10., csütörtök 6:38
> *Címzett: *Ivam Pretti <ivamprett...@gmail.com>
> *Másolatot kap: *cmake-developers@cmake.org
> *Tárgy: *Re: [cmake-developers] C++ IDE
>
>
>
> I have been really impressed with VSCode <https://code.visualstudio.com/>.
>
>
>
>
> On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti <ivamprett...@gmail.com>
> wrote:
>
> Can you recomend an IDE to code in C/C++?
>
>
> --
>
> 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] Future of ccmake and cmake-gui

[Jean-Michaël Celerier]

> For example, I've seen way too many
projects screw up with Brew because they fail to ship a binary that
can work on a clean user system who is not going to install Brew.

I must be lucky then, because just using macdeployqt copies all the
dependencies for me and
updates all the install paths correctly whether I use Qt's own build or
brew's.

> It pulls a new version of gcc instead of using Xcode/clang on
your system and builds an entire dependency chain based on GNU tools.

this is false. brew uses xcode & clang on your system.

> Similar problem for Windows...Visual Studio is the requirement.

I don't know if you are talking about Chocolatey or Qt but neither require
Visual Studio on windows.
Qt even comes with MinGW if you wish.

> And Mac doesn't have configure/autotools by defaul.

but... "configure" has nothing to do with autotools.
It's just a shell script (which is sometimes generated *from* autotools;
this is not the case with Qt AFAIK).

> and I never figured why Qt's RAM consumption footprint is so high...based
on all the DLL binary code it
has to load, or something more intrinsic to its implementation.

science can help us here :p two tools are very nice for this :

* bloaty mcbloatface for binary bloat

for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep
-A3 'text') ; done

tells us stuff like

/usr/lib/libQt5Core.so
  55.4%  2.75Mi .text  2.75Mi  55.5%
  23.5%  1.16Mi .rodata1.16Mi  23.5%
   7.3%   372Ki .eh_frame   372Ki   7.4%
   4.1%   210Ki .dynstr 210Ki   4.2%
/usr/lib/libQt5Gui.so
  70.0%  3.82Mi .text   3.82Mi  70.2%
   7.8%   438Ki .eh_frame438Ki   7.9%
   6.1%   342Ki .dynstr  342Ki   6.1%
   5.1%   286Ki .rodata  286Ki   5.1%

A bit surprising to see .eh_frame; I thought Qt was compiled with
-fno-exceptions but maybe that's just my distro.
Quite a bunch of .rodata in Qt5Core too, I wonder why.
Further examination through
readelf -x .rodata /usr/lib/libQt5Core.so | less
seems to show up a lot of locale-specific calendar text & such, e.g. names
of the months in twenty languages, currencies, time zones, etc

* And then, runtime examination: for this I tried making a minimal gui
program:
#include 
#include 
int main(int argc, char**argv)
{
  QApplication app(argc, argv);
  QMainWindow w;
  w.show();
  return app.exec();
}

compiled with
g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore
-I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core
-lQt5Widgets

and then use the wonderful Heaptrack (https://github.com/KDE/heaptrack) :

heaptrack ./a.out

which then greets us with http://imgur.com/a/eYjaL

As you can see, "peak heap memory consumption" is at a bit less than 400
*kilobytes*. So the Qt memory usage that you see is clearly due only to
binary bloat.
And indeed (sorry for shitty bash skills):

$ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}'  | xargs
readlink |  awk '{print "/usr/lib/" $1;}'  | xargs du -csh  | sort -h
16K/usr/lib/libdl-2.25.so
16K/usr/lib/libXau.so.6.0.0
24K/usr/lib/libXdmcp.so.6.0.0
32K/usr/lib/librt-2.25.so
64K/usr/lib/libdouble-conversion.so.1.0.0
68K/usr/lib/libbz2.so.1.0.6
72K/usr/lib/libGLX.so.0.0.0
72K/usr/lib/libXext.so.6.4.0
80K/usr/lib/liblz4.so.1.7.5
84K/usr/lib/libgpg-error.so.0.22.0
92K/usr/lib/libz.so.1.2.11
144K/usr/lib/libpthread-2.25.so
152K/usr/lib/liblzma.so.5.2.3
164K/usr/lib/libxcb.so.1.1.0
176K/usr/lib/libgraphite2.so.3.0.1
216K/usr/lib/libpng16.so.16.31.0
444K/usr/lib/libpcre2-16.so.0.5.0
460K/usr/lib/libpcre.so.1.2.9
536K/usr/lib/libsystemd.so.0.19.0
548K/usr/lib/libharfbuzz.so.0.10400.5
552K/usr/lib/libGL.so.1.0.0
600K/usr/lib/libGLdispatch.so.0.0.0
796K/usr/lib/libfreetype.so.6.14.0
1,1M/usr/lib/libglib-2.0.so.0.5200.3
1,1M/usr/lib/libm-2.25.so
1,2M/usr/lib/libgcrypt.so.20.2.0
1,3M/usr/lib/libX11.so.6.3.0
1,7M/usr/lib/libicuuc.so.59.1
1,9M/usr/lib/libc-2.25.so
2,5M/usr/lib/libicui18n.so.59.1
5,0M/usr/lib/libQt5Core.so.5.9.1
5,5M/usr/lib/libQt5Gui.so.5.9.1
6,4M/usr/lib/libQt5Widgets.so.5.9.1
12M/usr/lib/libstdc++.so.6.0.24
26M/usr/lib/libicudata.so.59.1
69Mtotal

So there's 17 megabytes of Qt in here; hopefully the rest would already be
loaded by your system.

Best,
Jean-Michaël

On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing <ewmail...@gmail.com> wrote:

> On 8/16/17, Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> wrote:
> > @Eric Wing
> >> I am not making a strong push for this, but I want to bring it up to
> > at least get people thinking about this... I am disturbed by the size
> > and complexity of Qt. My past experiences have not been good and I
> > find it a massive chore to get an environment setup (especially on Mac
> > and Win

Re: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam

[Jean-Michaël Celerier]

That's a very useful feature to have! Ideally CMake would also try to load
it recursively up to the "/" folder just like for instance clang-format or
clang-tidy look for their configuration folders upwards. This would allow
for instance to easily build all the projects in a certain folder in
release mode by default or stuff like this.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Aug 9, 2017 at 12:20 PM, Cristian Adam <cristian.a...@gmail.com>
wrote:

>
>
> On Tue, Aug 8, 2017 at 8:08 PM, Brian Davis <bitmi...@gmail.com> wrote:
>
>>
>> Is there a CMake equivalent to a site-config.jam or user-config.jam
>>
>> http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html
>>
>> basically a CMake file the user can put in a project directory that CMake
>> will read first when using cmake-gui that allows user to specify stuff they
>> don't want to have to keep specifying in cmake-gui each "delete cache"
>>
>> such as
>>
>> set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING ""
>> FORCE)
>> set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE )
>>
>>
>> There is cmake.exe
>>
>> -C 
>>
>> but requires command line
>>
>> come to think of it would be nice if
>> set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" )
>>
>> in desired user config file and CMake would just "make it so" on clicking
>> Generate.
>>
>> I can do this with my own projects, by implementing it myself, but when
>> checking out 3rd party projs they can be all over the map on config
>> allowing a user-config.cmake would provide mechanism to tame the config
>> problems.
>>
>> Desired workflow
>>
>> 1) Checkout 3rd party proj
>>
>> 2) put a CMakeUser.txt or whatever file per project
>>
>> 3) Run CMake GUI Generate
>>
>> 4) Click Open Project
>>
>> 5) Change whatever manual bits in in gui
>>
>> 6) Update project suing git witch branches versions
>>
>> 7) Delete Cache
>>
>> 8) Return to 3
>>
>> 9) Doopy doopy doo whatever else
>>
>
> There is the (undocumented) PreLoad.cmake
> <https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmake.cxx#L1507>,
> which acts like giving a precache file with -C command line argument.
>
> But, as it turns out, it doesn't work with server mode :(
>
> Cheers,
> Cristian.
>
>
> --
>
> 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

Re: [CMake] Can't get CMake to link pthreads to my lib

[Jean-Michaël Celerier]

I've tried this and also
set(THREADS_PREFER_PTHREAD_FLAG TRUE)

but this didn't work either.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Aug 8, 2017 at 4:01 PM, Rolf Eike Beer <e...@sf-mail.de> wrote:

> Am 2017-08-08 15:45, schrieb Jean-Michaël Celerier:
>
>> Here's my CMakeLists.txt :
>>
>>
>>>>>>>>>
>> cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
>> project(oscour)
>> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>>
>> set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined")
>> set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address
>> -fsanitize=undefined")
>>
>> add_subdirectory(uWebSockets)
>>
>
> set(CMAKE_THREAD_PREFER_PTHREAD On)
>
> find_package(Threads REQUIRED)
>>
>
> Greetings,
>
> Eike
> --
> --
>
> 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/opensou
> rce/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] Can't get CMake to link pthreads to my lib

[Jean-Michaël Celerier]

Here's my CMakeLists.txt :

>>>>>>>

cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
project(oscour)
set(CMAKE_INCLUDE_CURRENT_DIR ON)

set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined")
set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address
-fsanitize=undefined")

add_subdirectory(uWebSockets)

find_package(Threads REQUIRED)

add_library(oscour INTERFACE)
target_sources(oscour INTERFACE
  ${CMAKE_CURRENT_SOURCE_DIR}/oscour/oscour.hpp)

target_include_directories(oscour INTERFACE oscour/)
target_link_libraries(oscour INTERFACE uWS Threads::Threads)
target_compile_options(oscour INTERFACE -std=c++17)

add_executable(udp examples/udp.cpp)
target_link_libraries(udp PRIVATE oscour)

add_executable(tcp examples/tcp.cpp)
target_link_libraries(tcp PRIVATE oscour)

<<<<<<<<

As you can see, I call
find_package(Threads REQUIRED)
but at no point my example executables, named udp and tcp, link to -pthread
(or -lpthread) (which of course makes my build fails).
I also tried to link them explicitely to Threads::Threads. This did not
work either.

e.g. when doing make in verbose mode, the link invocation is :

 /usr/bin/g++ -fconcepts -fsanitize=address -fsanitize=undefined -std=c++17
-fconcepts -fsanitize=address -fsanitize=undefined
CMakeFiles/complete.dir/examples/udp.cpp.o  -o udp  uWebSockets/libuWS.a
/usr/lib/libssl.so /usr/lib/libcrypto.so /usr/lib/libz.so

there is no hint of pthreads in there... what can I do ?

Best

Jean-Michaël Celerier
http://www.jcelerier.name
-- 

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] C++ IDE

[Jean-Michaël Celerier]

QtCreator is nice.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Aug 6, 2017 at 10:57 PM, Rolf Eike Beer <e...@sf-mail.de> wrote:

> Am Sonntag, 6. August 2017, 17:52:13 schrieb Ivam Pretti:
> > Can you recomend an IDE to code in C/C++?
>
> KDevelop.
> --
>
> 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] Module macros/function names with single leading underscore

[Jean-Michaël Celerier]

> It's probably going to be an uncommon situation

https://www.google.fr/search?q="macro(_"+site%3A%3Ahttps%3A%2F%2Fgithub.com

A lot are namespaced but skimming a bit through the result, there is also
stuff like *_*INTERNAL_PARSE_FLAGS_ARGS, *_*fixup_target, *_*LSB_RELEASE,
*_*plugin_target_name
which may be at risk for the problem you're exposing.


Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Aug 1, 2017 at 10:42 PM, Brad King <brad.k...@kitware.com> wrote:

> On 07/23/2017 10:20 AM, Craig Scott wrote:
> > maybe it's worth considering renaming these single underscore
> > internal macros and functions?
>
> Projects that rely on the undocumented feature depend on being
> able to call the original function by prepending the single
> underscore.  We can't change the renaming convention without
> breaking them.  Even a policy for this may be tricky due to
> function definitions being visible globally and therefore
> skipping across policy scopes.
>
> The infinite recursion case you mentioned has long been known
> and may have a few issue tracker entries.  We haven't really
> dealt with it because the feature is undocumented and meant
> for debugging.  If anyone can come up with a compatible fix
> (e.g. explicit diagnostic) that would be great.
>
> Side note: One day I'd like to see a policy that changes
> function/macro definition scopes to be directory-based.
> I haven't thought about the correctness or side-effects of
> that in detail though.
>
> -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
>
-- 

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] ;-list in docs

[Jean-Michaël Celerier]

On Sat, May 13, 2017 at 5:39 AM, Craig Scott 
wrote:

> ;-list


It's a shorthand for semicolon-separated list :
https://cmake.org/cmake/help/v3.8/command/separate_arguments.html?highlight=semicolon
-- 

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] Splitting CMakeLib

[Jean-Michaël Celerier]

On Wed, May 10, 2017 at 4:56 PM, Egor Pugin  wrote:

> but CMakeLib looks too fat.



In this age of link-time whole-program optimizations is this really a
problem ?
-- 

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] Support for version suffixes

[Jean-Michaël Celerier]

I remember asking for the same thing a few weeks ago on IRC because of a
small behaviour change in cmake 3.8.0 rc2 that I wanted to put behind an
if(version_less).

Alphanumeric ordering would certainly work for most projects : alpha < beta
< rc. (I generally use a0, a1, a2... b0, b1, b2...)

Best
Jean-Michaël

On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh  wrote:

> Hi folks,
>
> I'd like to bring this issue to your attention to canvas some feedback
> regarding the use of version suffixes:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16716
>
> This is basically a proposal to allow an optional version suffix like
> "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak
> pattern, for better interoperability with systems and software releases
> already using such suffixes, and also to permit the use of such suffixes by
> CMake projects for their own purposes.  A version suffix would be usable
> anywhere currently using 4 digit versions, with all the necessary
> functionality in CMake being updated to handle this.
>
> The proposal linked above contains a much more detailed rationale and
> suggested implementation strategy.  I'd be very happy to hear any thoughts
> anyone has regarding this either on the above issue, or here.
>
>
> Thanks all,
> Roger
> --
>
> 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/opensou
> rce/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] [Discussion] Add python support for CMakeLists

[Jean-Michaël Celerier]

(My simple user opinion):

I'm not a fan of the idea.
Not particularly because of Python, but because with this, now
if I want to use a library that someone made with a CMakeLists.py in my
project
(for instance as a submodule) :
* I also have to install Python on the machines where the build happens,
* tell my users to install Python,
* add it to their PATH...

Many already have trouble just installing and running CMake, and this adds
another
potential layer of complexity, and a fragmentation of the ecosystem.
Unless CMake would ship with its own Python interpreter ?

I know, this is a non-problem on Linux and OS X (or is it ? On my machine
/usr/bin/python is python 3 but on others it is python 2),
but there are some poor people out there stuck with Windows machines, and I
wouldn't like their lives to be even harder.

Best regards
Jean-Michaël

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H,  wrote:

> Hello,
>
> First of all, I have been using CMake for a few years now, it is awesome
> tool, thank you.
>
> The only problem I currently have with CMake is its language, which has
> not really intended to be one. After reading a few endless discussions
> about this topic, I decided to give it a try and do something practical.
>
> My current design is using Python as an extension for the regular
> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>
> It should not be too hard to maintain, the current API design uses only
> 1-3 function that should be implemented in cmake.
>
> For more information, see the [closed] merge request #389
> .
>
> I would be happy to hear your opinion about this idea.
>
> Best regards,
> Shmuel H.
>
> --
>
> 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/opensou
> rce/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] Current deficiencies of automoc

[Jean-Michaël Celerier]

On Fri, Oct 21, 2016 at 10:10 AM, Sebastian Holtermann 
wrote:

>
> A quick fix for the example would be to explicitly add the
> headers-to-moc to the sources list.


This has the nice side-effect of making your project much easier to use in
IDEs.
-- 

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] Dependency mechanism of CMake

[Jean-Michaël Celerier]

Hi,

Did you read this page ? The "Build Specification & Usage Requirements"
section clearly explains how it works imho.

https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html
and
https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements

Best
Jean-Michaël

On Thu, Aug 18, 2016 at 10:11 AM, Costean Adrian via cmake-developers <
cmake-developers@cmake.org> wrote:

> Hello CMake developers,
> I've been trying to figure out how CMake works ( so far no chance, the
> documentation of "behind the scenes of CMake" is kind of limited).
> I am interested in how CMake calculates the dependencies, if it does it
> efficient and correct.
> Could anyone brief me with a quick overview?
> Thanks and regards,
> Adrian C.
> --
>
> 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] RFC: CMake precompiled header support and custom compiler based implementation

[Jean-Michaël Celerier]

Hi,

could you give a try to the branch ?
:)

Jean-Michaël Celerier

On Sat, Dec 5, 2015 at 1:39 PM, David Cole via cmake-developers <
cmake-developers@cmake.org> wrote:

> Yes, that looks like it should work. I'll pull your branch and give it a
> try sometime in the coming week.
>
> Thanks,
> David
>
> On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de>
> wrote:
>
>> On Fri, Dec 4, 2015 at 11:32 PM, David Cole <dlrd...@aol.com> wrote:
>> > Makes sense.
>> >
>> > Can I inject my own "#include " into
>> > the generated stream, or otherwise inject something into it?
>>
>> You should be able to do:
>>
>> target_include_directories(your_target
>>   PUBLIC public
>>   PRIVATE private
>>   )
>> target_precompile_headers(your_target
>>   PUBLIC
>> public_header1.h
>> public_header2.h
>>   PRIVATE
>> private_header1.h
>> private_header2.h
>>   )
>>
>> Does that answer your question? Do you think this could solve your
>> use-case?
>>
>> > Specifically, for me, I want to include some, but not ALL VTK headers
>> > for a VTK-based project.
>>
>> I don't see a problem for that.
>>
>> > Thanks for working on this.
>>
>> You are welcome. :-)
>>
>> > Let me know if you want me to be a Visual Studio tester for you.
>>
>> Yes, please. My main working environment is Linux. I appreciate any
>> feedback from different platforms.
>>
>
> --
>
> 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] C# support ready for review

[Jean-Michaël Celerier]

Simple question : do you think that this would be useable in order to
have a single build pipeline based on CMake for a Unity3D project that
also requires some native C++ libs ?

Thanks !


On Mon, Mar 21, 2016 at 8:09 AM, Stuermer, Michael  SP/HZA-ZSEP
 wrote:
> Sorry for asking, but do you mean
>
> 1. without support for ninja/nmake/make there is no use having C# support in 
> cmake
>
> or
>
> 2. using the current approach this could also work with the other generators 
> without too much additional work
>
> ?
>
> I'm just a little confused and try to find out what's on my todo list until 
> C# support may reach a mature level.
>
> best regards,
> Michael
>
>> -Original Message-
>> From: David Cole [mailto:dlrd...@aol.com]
>> Sent: Tuesday, March 08, 2016 12:51 AM
>> To: Brad King
>> Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
>> Subject: Re: [cmake-developers] C# support ready for review
>>
>> Seems to me like C# support should work just fine with other generators:
>> ninja, nmake, and UNIX Makefiles included. Especially with mono on
>> Linux/Mac.
>>
>>
>> David
>>
>> > On Mar 7, 2016, at 2:12 PM, Brad King  wrote:
>> >
>> >> On 02/25/2016 05:51 AM, Stuermer, Michael  SP/HZA-ZSEP wrote:
>> >> The part that probably needs most additional work is all the C#
>> >> detection and configuration part in the module scripts.
>> >
>> > In your branch Modules/CMakeDetermineCSharpCompiler.cmake
>> currently
>> > has a lot of logic and environment checks for this.  It shouldn't need
>> > to be that complicated.  Anything requiring deep introspection of the
>> > system (especially the registry) should be something done in the C++
>> > generator implementation and provided to CMake platform files as a
>> > variable.
>> >
>> > For example, the VS generators always provide msbuild:
>> >
>> >
>> https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM
>> AND.ht
>> > ml
>> >
>> > For the path to the compiler tool, take a look at
>> >
>> > Modules/CompilerId/VS-10.vcxproj.in
>> >
>> > and use of it by Modules/CMakeDetermineCompilerId.cmake.  That all
>> > runs while detecting the compiler id using a small test project.
>> > It has a custom command that searches the PATH in the IDE project
>> > build environment to print out the path to the compiler.  You should
>> > create one like this for CSharp too.
>> >
>> > We'll also need to define behavior when CSharp is enabled by projects
>> > under a non-VS generator.  Other generators should reject any such
>> > attempt with an error message.
>> >
>> > 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
> --
>
> 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

[Jean-Michaël Celerier]

There is also https://www.cevelop.com/ which is an Eclipse derivative, they
may be interested ?

Best,

Jean-Michaël
www.i-score.org

On Fri, Feb 19, 2016 at 11:36 AM, Stephen Kelly  wrote:

> Alexander Neundorf wrote:
>
> > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
> >> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> >> > Hi Dominik,
> >> >
> >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"
> >> >  >> >
> >> > >:
> >> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
> >> >
> >> > I'd be in, but I do not have the time to organize one. I could
> >> > probably get a room in our office though (in Berlin).
> >>
> >> I'd be up for a sprint in Berlin too, but given the muted response so
> >> far here, it's not clear who would want to join and what we could
> >> achieve.
> >
> > just out of curiosity, did you get any feedback from anybody from
> > Eclipse/CDT ?
>
> Nope. No response from there at all despite reaching out to them.
>
> > Or CodeBlocks maybe ?
>
> I didn't reach out to them, so no.
>
> 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
>
-- 

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]

Throw in a


> list(GET MyList ${i} ElementA)
> list(GET MyOtherListOfSameSizeThanMyList ${i} ElementB)
> foobazify(${ElementA} ${ElementB})

(I did not want to put a ginormous code snippet, just to outline the amount
of code necessary to do simple things)

On Fri, Jan 15, 2016 at 1:28 AM, J Decker <d3c...@gmail.com> wrote:

> On Thu, Jan 14, 2016 at 3:09 PM, Jean-Michaël Celerier
> <jeanmichael.celer...@gmail.com> 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 <charles.h...@gmail.com>
> > 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 <neund...@kde.org
> >
> >>> 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] 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

[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 <charles.h...@gmail.com>
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 <neund...@kde.org>
>> 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] [ANNOUNCE] CMake 3.4.0 Released

[Jean-Michaël Celerier]

> * The "CPackDeb" module now correctly excludes symlinks during
  package checksum calculation.

> * The "CPackDeb" no longer uses fakeroot and system tar program for
  packaging.

Does this mean that the ubuntu package manager will stop complaining of
CPack DEBs ?

Thanks for the great work :)

Jean-Michaël


On Thu, Nov 12, 2015 at 9:47 PM, Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:

> 12.11.2015, 21:57, "Robert Maynard" :
> > I am proud to announce that CMake 3.4.0 is now available for download at:
> > https://cmake.org/download/
> >
> > Documentation is available at:
> > https://cmake.org/cmake/help/v3.4
> >
> > Release notes appear below and are also published at
> > https://cmake.org/cmake/help/v3.4/release/3.4.html
>
> Good job! Thank you!
>
> I could not miss this event. This is a good occasion to remind about
> the existence of CPack "IFW" generator :-)
>
> https://cmake.org/cmake/help/v3.4/module/CPackIFW.html
>
> Here is a fresh not official offline installers for CMake 3.4.0 on Windows:
>
> http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.0-win32-x86.exe
>
> and
>
> http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.0-win64-x64.exe
>
> But I want to assure you that they are honestly built me personally of the
> official code of branch 'release' recently :-)
>
> I'll be glad if somebody test these installers for themselves and to share
> their comments and suggestions.
>
> Good luck to everyone!
>
> --
> 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
>
-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

 Qt 5 provides a macro for this context which expands to either 'const' or
'constexpr' depending on whether cxx_constexpr is available, and another
macro which expands to either 'const' or 'constexpr' depending on whether
cxx_relaxed_constexpr is available.

Thinking of it, since C++14 constexpr does not imply const anymore, so
isn't this macro ambiguous wrt standard c++ ?



On Wed, Jul 8, 2015 at 10:42 PM, Stephen Kelly steve...@gmail.com wrote:

 Jean-Michaël Celerier wrote:

  I think there should be a test for the different allowed contexts of the
  ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
  you extend Tests/Module/WriteCompilerDetectionHeader with a test for
 that?
 
  For sure, I'll do this asap.
 

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

-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

I'm referring to the const used after methods (struct { int f() const; }).

Here is an example : https://ideone.com/C28SMn

Best regards :)




On Mon, Aug 3, 2015 at 7:20 PM, Stephen Kelly steve...@gmail.com wrote:

 Jean-Michaël Celerier wrote:

  Qt 5 provides a macro for this context which expands to either 'const'
 or
  'constexpr' depending on whether cxx_constexpr is available, and another
  macro which expands to either 'const' or 'constexpr' depending on whether
  cxx_relaxed_constexpr is available.
 
  Thinking of it, since C++14 constexpr does not imply const anymore, so
  isn't this macro ambiguous wrt standard c++ ?
 

 The 'const' keyword can be used in multiple contexts. Can you clarify which
 you mean with a reference to some document?

 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

-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

Hello,

At the ned of this mail is a patch that adds generation of a macro for
the relaxed (c++14) constexpr in WriteCompilerDetectionHeader.

This is intended for compilers that support c++11 constexpr (with
everything on a single return statement) like GCC-4.9 and the upcoming
MSVC, but not extended constexpr which allows for more complete
functions. This way, code bases can reap the benefits of most recent
compilers at no cost.

Best regards
Jean-Michaël Celerier


diff --git a/Modules/WriteCompilerDetectionHeader.cmake
b/Modules/WriteCompilerDetectionHeader.cmake
index a3b73bb..f7af7ec 100644
--- a/Modules/WriteCompilerDetectionHeader.cmake
+++ b/Modules/WriteCompilerDetectionHeader.cmake
@@ -144,6 +144,7 @@
 # == ===
=
 # ``c_restrict``  ``PREFIX_RESTRICT``   ``restrict``
 # ``cxx_constexpr``   ``PREFIX_CONSTEXPR``  ``constexpr``
+# ``cxx_relaxed_constexpr``   ``PREFIX_RELAXED_CONSTEXPR``  ``constexpr``
 # ``cxx_deleted_functions``   ``PREFIX_DELETED_FUNCTION``   ``= delete``
 # ``cxx_extern_templates````PREFIX_EXTERN_TEMPLATE````extern``
 # ``cxx_final``   ``PREFIX_FINAL``  ``final``
@@ -494,6 +495,16 @@ function(write_compiler_detection_header
 #  endif
 \n)
   endif()
+  if (feature STREQUAL cxx_relaxed_constexpr)
+set(def_value ${prefix_arg}_RELAXED_CONSTEXPR)
+set(file_content ${file_content}
+#  if ${def_name}
+#define ${def_value} constexpr
+#  else
+#define ${def_value}
+#  endif
+\n)
+  endif()
   if (feature STREQUAL cxx_final)
 set(def_value ${prefix_arg}_FINAL)
 set(file_content ${file_content}
-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

 I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?

For sure, I'll do this asap.

 constexpr foo = ...;

If I read http://en.cppreference.com/w/cpp/language/constexpr
correctly, there should be no differences in variable handling between
C++11 and 14 for constexpr, the changes are only for function bodies.



Jean-Michaël


On Wed, Jul 8, 2015 at 9:49 PM, Stephen Kelly steve...@gmail.com wrote:
 Stephen Kelly wrote:

 * A method marked constexpr will fail to compile with a compiler which
 does not support relaxed constexpr if the method uses language which
 requires relaxed mode (such as a for loop), even if the method is
 evaluated in a non- constant expression. I tested GCC and Clang.

 Are there any values of '...' where

  constexpr foo = ...;

 would compile or not depending only on whether using cxx11-constexpr or
 cxx14-constexpr?

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

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