Re: [CMake] Parallel moc for Qt files

[Benjamin Ballet via CMake]

I don't know how to parallelize moc with CMake though I previously reduce
moc time (sometimes it's very slow) :

- by replacing as much #include as possible by forward-declaration

- wrapping some #include around #ifndef Q_MOC_RUN ... #endif

2017-07-06 22:00 GMT+02:00 Michael Jackson :

> I have a large list of files that need to have Qt's 'moc' run on them (107
> headers). I use all the normal CMake facilities for Qt based projects. I
> noticed that the generation of the moc files are done serially. Is there a
> flag or anything that I can use to run the generation in Parallel? I ask
> because each file takes about 3 seconds to run through moc. The code is
> heavily C++ templated which I think causes 'moc' to run more slowly. We
> have other places in the code where 'moc' must run and it does each file in
> the "blink of an eye".
>
> Just curious.
>
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jack...@bluequartz.net
> --
>
> 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
>



-- 
Benjamin Ballet
Ingénieur R



19 rue Klock - 92110 Clichy - FRANCE
Standard : +33 1 44 69 37 37

www.activisu.com




-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] cmake install ends with error code 0xC0000022

[Benjamin Ballet via CMake]

Hi,

I'm using install(CODE"... to run windeployqt.exe during installation

It works fine for a few exe or dll then it fails the installation with
error code 0xC022 because of the last execute_process(...
If I remove the incriminating dll, it fails with the next one.

Any hints ?


-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] ExternalProject_Add : set the location of CMakeLists.txt

[Benjamin Ballet via CMake]

It's not listed in changelog though :
https://cmake.org/cmake/help/v3.7/release/3.7.html

2016-10-26 11:34 GMT+02:00 Benjamin Ballet <bbal...@ivsweb.com>:

> Ok I'm quiet lucky : There is what I need in CMake 3.7 (SOURCE_SUBDIR)
>
> 2016-10-25 19:54 GMT+02:00 Konstantin Podsvirov <konstan...@podsvirov.pro>
> :
>
>> Hello again.
>>
>> 25.10.2016, 20:31, "Konstantin Podsvirov" <konstan...@podsvirov.pro>:
>> > Hello, Benjamin.
>> >
>> > 25.10.2016, 19:41, "Benjamin Ballet via CMake" <cmake@cmake.org>:
>> >>  Hi,
>> >>
>> >>  I'm trying to get GLEW (https://github.com/nigels-com/glew) with
>> ExternalProject_Add
>> >>  It's buildable with cmake but the CMakeLists.txt is in build/cmake
>> directory.
>> >>
>> >>  Is there a way to specify the directory of the CMakeLists.txt file ?
>> >>
>> >>  If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and
>> still run the cmake command in repo root.
>> >>
>> >>  --
>> >>  Benjamin BALLET
>> >>  Ingénieur R
>> >>
>> >>  ACTIVISU
>> >>  19, rue Klock - 92110 Clichy
>> >>>  Standard Tél :  01 44 69 37 37
>> >>>  www.activisu.com
>> >>  ,--
>> >
>> > Try it:
>> >
>> > ExternalProject_Add(
>> >   ...
>> >   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
>> >   ...
>> >   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
>> ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
>> >   ...)
>>
>>
>> Or try it:
>>
>> ExternalProject_Add(
>>   ...
>>   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
>>   ...
>>   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
>>-DCMAKE_GENERATOR=${CMAKE_GENERATOR}
>>-DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}
>>-DCMAKE_GENERATOR_TOOLSET=${CMAKE_GENERATOR_TOOLSET}
>> ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
>>   ...)
>>
>> --
>> Regards,
>> Konstantin Podsvirov
>>
>
>
>
> --
> *Benjamin BALLET*
> Ingénieur R
>
> *ACTIVISU*
> 19, rue Klock - 92110 Clichy
> *> Standard Tél* :  01 44 69 37 37
> *>* www.activisu.com
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] ExternalProject_Add : set the location of CMakeLists.txt

[Benjamin Ballet via CMake]

Ok I'm quiet lucky : There is what I need in CMake 3.7 (SOURCE_SUBDIR)

2016-10-25 19:54 GMT+02:00 Konstantin Podsvirov <konstan...@podsvirov.pro>:

> Hello again.
>
> 25.10.2016, 20:31, "Konstantin Podsvirov" <konstan...@podsvirov.pro>:
> > Hello, Benjamin.
> >
> > 25.10.2016, 19:41, "Benjamin Ballet via CMake" <cmake@cmake.org>:
> >>  Hi,
> >>
> >>  I'm trying to get GLEW (https://github.com/nigels-com/glew) with
> ExternalProject_Add
> >>  It's buildable with cmake but the CMakeLists.txt is in build/cmake
> directory.
> >>
> >>  Is there a way to specify the directory of the CMakeLists.txt file ?
> >>
> >>  If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and
> still run the cmake command in repo root.
> >>
> >>  --
> >>  Benjamin BALLET
> >>  Ingénieur R
> >>
> >>  ACTIVISU
> >>  19, rue Klock - 92110 Clichy
> >>>  Standard Tél :  01 44 69 37 37
> >>>  www.activisu.com
> >>  ,--
> >
> > Try it:
> >
> > ExternalProject_Add(
> >   ...
> >   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
> >   ...
> >   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
> ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
> >   ...)
>
>
> Or try it:
>
> ExternalProject_Add(
>   ...
>   SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/source
>   ...
>   CONFIGURE_COMMAND ${CMAKE_COMMAND} [additional args...]
>-DCMAKE_GENERATOR=${CMAKE_GENERATOR}
>-DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}
>-DCMAKE_GENERATOR_TOOLSET=${CMAKE_GENERATOR_TOOLSET}
> ${CMAKE_CURRENT_BINARY_DIR}/source/build/cmake
>   ...)
>
> --
> Regards,
> Konstantin Podsvirov
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] ExternalProject_Add : set the location of CMakeLists.txt

[Benjamin Ballet via CMake]

Hi,

I'm trying to get GLEW (https://github.com/nigels-com/glew) with
ExternalProject_Add
It's buildable with cmake but the CMakeLists.txt is in build/cmake
directory.

Is there a way to specify the directory of the CMakeLists.txt file ?

If I change SOURCE_DIR it will only clone the repo in SOURCE_DIR and still
run the cmake command in repo root.

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] setting clrsupport VS2010

[Benjamin Ballet via CMake]

Hi
here is all the property I had to set to produce C++/CLI (clr) targets with
cmake


target_compile_options(${project_name} PRIVATE /clr)
target_compile_options(${project_name} PRIVATE /fp:precise) #
/fp:strict is incompatible with /clr

set_property(TARGET ${project_name} PROPERTY VS_GLOBAL_ROOTNAMESPACE
${project_name})

set_property(TARGET ${project_name} PROPERTY VS_GLOBAL_KEYWORD
"ManagedCProj")

set_property(TARGET ${project_name} PROPERTY VS_GLOBAL_CLRSupport
"true")

set_property(TARGET ${project_name} PROPERTY
VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.0")

set_property(TARGET ${project_name} PROPERTY VS_DOTNET_REFERENCES
"System" "System.Data" "System.Drawing" "System.Windows.Forms" "System.Xml")

# Note: Modification of compiler flags is required for CLR
compatibility now that we are using .resx files.
string(REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
string(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG
"${CMAKE_CXX_FLAGS_DEBUG}")

2016-10-19 12:08 GMT+02:00 Swetha Sharma :

> I am trying to create a managed c++ code , i want to thes clrsupport to be
> true from cmake. Below is the script which  i have used
>
> SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "/clr")
>  STRING(REPLACE "/EHsc" "/EHa" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
>  STRING(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG})
>  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /clr")
>
> The problem I've found, is that while CMake sets the "Common Language
> RunTime Support" option in the C/C++ section of the configuration
> properties
> if "/clr" is in the CXX_FLAGS, it does not set the "Common Language RunTime
> Support" in the general configuration properties, and that causes problems
> with linking/.NET references.
>
>
> How do I fix this issue?
> -swetha
>
> --
>
> 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
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Using a pathless library in an imported target.

[Benjamin Ballet via CMake]

Create an imported interface instead of a static library. Then you can set
either INTERFACE_COMPILE_OPTIONS or INTERFACE_LINK_LIBRARIES properties.

2016-08-27 21:39 GMT+02:00 Yaron Cohen-Tal :

> Hi,
>
> I try to make an imported target out of OpenGL, and I have some
> difficulty. Usually "OPENGL_gl_LIBRARY" is a full path (found with
> "find_library"), but sometimes (on Windows) it's a pathless library (e.g.
> "opengl32", set with the cmake command "set"). However an imported library
> requires the full path to the library. Any idea how to tackle it?
>
> Thanx,
> Yaron
>
> --
>
> 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
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Benjamin Ballet via CMake]

Very interesting discussion, we have the same issues here.

Florent Castelli, how many third parties libraries do you use ? I think a
super build can be a very good solution but I'm wondering how much third
party code you have to build. Here we use OpenCV, with, boost, and poco,
and other things... So it may be too long.

I was personnaly considering having an hybrid solution : include small
libraries (like jsoncpp) and pre-build the other for each platforms.


2016-08-16 12:52 GMT+02:00 Florent Castelli :

> At Spotify, we use CMake a lot for our large C++ library shared by all the
> clients.
> After trying to build libraries for each platform and variant, we
> basically gave up and we now
> use a super-build approach.
>
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android
> and iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…)
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost,
> we had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build
> it and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the
> flags in your CMake files
> instead, which is still not good enough.
>
> In the end, I looked at how Boost is actually built. And for most
> libraries, it’s plain simple.
> A static library with a few files, some define, sometimes a platform
> specific source file.
> What if instead of having an external build tool, I built it from CMake
> instead?
> It would propagate all the build flags, target, instrumentation and
> compiler information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary
> distribution with the source
> distribution and it’s much easier. When people build our library for a
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and
> patched it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was
> again effortless.
>
> Overall, building boost takes 10s on our developers’ machines. The sources
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but
> that’s quite rare.
>
> We try now to use the same approach for other libraries when we add them.
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier to build a library for another platform that
> wasn’t targeted by the original
> project.
>
> If people are interested, I could share the CMakeLists.txt file we use for
> Boost. It doesn’t build all
> the libraries (some are hard like Context) and uses some internal macros,
> but it should be plain
> simple to tweak for your use.
>
> /Florent
>
> > On 12 Aug 2016, at 21:59, Robert Dailey 
> wrote:
> >
> > Hello,
> >
> > There is an internal C++ product at the company I work for which I
> > have written a series of CMake scripts for. This project actually has
> > dependencies on several open source libraries, such as boost,
> > freetype, openssl, etc.
> >
> > Right now what we do is build each of these third party libraries *by
> > hand*, once for every platform we support (Windows, Linux x86, Android
> > NDK). Then we stuff the includes (headers) and libraries
> > (static/shared) in a submodule and the primary code base's CMake
> > scripts pull them in as interface targets.
> >
> > This works well and is light-weight but is a pain when upgrading or
> > changing libraries. It's a pain because if I want to upgrade boost, I
> > have to build it up to 6 times (once for each platform and once for
> > each configuration).
> >
> > I've been thinking of a different approach for a while. I've done some
> > toying around with the "Super Build" concept, where I have a separate
> > CMake project that does nothing but use the ExternalProject module to
> > build libraries in real time along with our project. So the order of
> > operations would be as follows (for our automated build server):
> >
> > 1. Clone our "Third Party" repository
> > 2. Use CMake to generate & build the "Super Build" project (this
> > builds boost, openssl, freetype, etc for the current platform).
> > 3. Clone the main code base's repository
> > 4. Use 

Re: [cmake-developers] Need ideas/opinions on third party library management

[Benjamin Ballet via cmake-developers]

Very interesting discussion, we have the same issues here.

Florent Castelli, how many third parties libraries do you use ? I think a
super build can be a very good solution but I'm wondering how much third
party code you have to build. Here we use OpenCV, with, boost, and poco,
and other things... So it may be too long.

I was personnaly considering having an hybrid solution : include small
libraries (like jsoncpp) and pre-build the other for each platforms.


2016-08-16 12:52 GMT+02:00 Florent Castelli :

> At Spotify, we use CMake a lot for our large C++ library shared by all the
> clients.
> After trying to build libraries for each platform and variant, we
> basically gave up and we now
> use a super-build approach.
>
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android
> and iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…)
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost,
> we had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build
> it and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the
> flags in your CMake files
> instead, which is still not good enough.
>
> In the end, I looked at how Boost is actually built. And for most
> libraries, it’s plain simple.
> A static library with a few files, some define, sometimes a platform
> specific source file.
> What if instead of having an external build tool, I built it from CMake
> instead?
> It would propagate all the build flags, target, instrumentation and
> compiler information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary
> distribution with the source
> distribution and it’s much easier. When people build our library for a
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and
> patched it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was
> again effortless.
>
> Overall, building boost takes 10s on our developers’ machines. The sources
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but
> that’s quite rare.
>
> We try now to use the same approach for other libraries when we add them.
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier to build a library for another platform that
> wasn’t targeted by the original
> project.
>
> If people are interested, I could share the CMakeLists.txt file we use for
> Boost. It doesn’t build all
> the libraries (some are hard like Context) and uses some internal macros,
> but it should be plain
> simple to tweak for your use.
>
> /Florent
>
> > On 12 Aug 2016, at 21:59, Robert Dailey 
> wrote:
> >
> > Hello,
> >
> > There is an internal C++ product at the company I work for which I
> > have written a series of CMake scripts for. This project actually has
> > dependencies on several open source libraries, such as boost,
> > freetype, openssl, etc.
> >
> > Right now what we do is build each of these third party libraries *by
> > hand*, once for every platform we support (Windows, Linux x86, Android
> > NDK). Then we stuff the includes (headers) and libraries
> > (static/shared) in a submodule and the primary code base's CMake
> > scripts pull them in as interface targets.
> >
> > This works well and is light-weight but is a pain when upgrading or
> > changing libraries. It's a pain because if I want to upgrade boost, I
> > have to build it up to 6 times (once for each platform and once for
> > each configuration).
> >
> > I've been thinking of a different approach for a while. I've done some
> > toying around with the "Super Build" concept, where I have a separate
> > CMake project that does nothing but use the ExternalProject module to
> > build libraries in real time along with our project. So the order of
> > operations would be as follows (for our automated build server):
> >
> > 1. Clone our "Third Party" repository
> > 2. Use CMake to generate & build the "Super Build" project (this
> > builds boost, openssl, freetype, etc for the current platform).
> > 3. Clone the main code base's repository
> > 4. Use 

[CMake] cmake-3.5.2-win32-x86.exe : broken download link

[Benjamin Ballet via CMake]

Hi

On https://cmake.org/download/

It should be cmake-3.5.2-win32-x86.msi
 I guess

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[cmake-developers] patch bugfix : CMAKE_VS_PLATFORM_TOOLSET not defined for VisualStudio 2010

[Benjamin Ballet via cmake-developers]

Hi,

I stumbled on a bug : CMAKE_VS_PLATFORM_TOOLSET is empty when generating
for VisualStudio 2010

Here is a patch

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com


0001-VS-set-DefaultPlatformToolset-to-v100-for-VisualStud.patch
Description: Binary data
-- 

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 VS2010 generator : handle VS_GLOBAL_RootNamespace as well as VS_GLOBAL_ROOTNAMESPACE

[Benjamin Ballet via cmake-developers]

Hi folks,

As user I'm currently working on migrating C++CLI projects to CMake.

I wasted a few hours because I used VS_GLOBAL_RootNamespace (a specialized
version of VS_GLOBAL_ property) instead of
VS_GLOBAL_ROOTNAMESPACE.

So here is a patch to save the next one from wasting those same hours.

In my opinion, VS_GLOBAL_ROOTNAMESPACE with VS_GLOBAL_PROJECT_TYPE and
VS_GLOBAL_KEYWORD should be tagged as deprecated and users should be
redirected to VS_GLOBAL_. It would be simpler.


-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com


0001-VisualStudio10-generator-the-RootNamespace-property-.patch
Description: Binary data
-- 

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] [Visual Studio] Is it possible to specify a different target architecture?

[Benjamin Ballet via CMake]

Hi

Look at the CMAKE_VS_PLATFORM_TOOLSET

 variable

2016-06-28 15:51 GMT+02:00 Adam Rankin :

> Hello all,
>
>
>
> I am wondering if there exist CMake commands/variables to specify for
> Visual Studio to have the project file(s) generated target a different
> architecture than the one associated with that version of Visual Studio.
>
>
>
> For example, I develop in VS2015, but would like to target the VS2012
> redistributable (v110).
>
>
>
> Is this possible?
>
>
>
> Kind regards,
>
> Adam
>
> --
>
> 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
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Visual Studio : can I add a references to a cmake generated vcxproj ?

[Benjamin Ballet via CMake]

Hi folks

Is there a reason not to add a references to a cmake generated project from
a classic visual studio project ?

Anyone does it on a daily basis ?

I'm worrying about the generated ProjectGUID :
The guid of the project is stored in the classic visual studio project as
well as in the generated vcxproj.
I guess that guid may be different between two cmake generation ? If then
what will happen ?

Thank you !

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] issue with target_link_libraries and MSVC

[Benjamin Ballet via CMake]

I'v found a way to enable openmp for a few target only with
target_link_libraries :
I created an imported interface OpenMP and setted the property
INTERFACE_COMPILE_OPTIONS

2016-04-13 12:16 GMT+02:00 Matějů Miroslav, Ing. <mateju.miros...@azd.cz>:

> The page I linked says /openmp is a compiler flag (not linker flag), so
> adding it to CMAKE_CXX_FLAGS instead of LINK_FLAGS makes perfect sense.
>
>
>
> Miroslav
>
>
>
> *From:* Benjamin Ballet [mailto:bbal...@ivsweb.com]
> *Sent:* Wednesday, April 13, 2016 11:28 AM
> *To:* Matějů Miroslav, Ing.
> *Cc:* cmake@cmake.org
> *Subject:* Re: [CMake] issue with target_link_libraries and MSVC
>
>
>
> Ho yes, my bad, however there is still the same issue with forward slashes
>
>
>
> I receive the flag with FindOpenMP module. It's sad we can't do :
>
> target_link_libraries(... ${OpenMP_CXX_FLAGS}) for a few target
>
>
>
> In the end I add the flags for the whole project :
>
> set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
>
>
>
> 2016-04-13 7:54 GMT+02:00 Matějů Miroslav, Ing. <mateju.miros...@azd.cz>:
>
> Hi Benjamin,
>
>
>
> MSVC flags start with “forward” slashes: / (However, MSVC also accepts
> hyphens (-) in my experience.)
>
> Documentation for /openmp flag:
> https://msdn.microsoft.com/library/fw509c3b.aspx
>
>
>
> Best regards,
>
> Miroslav
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Benjamin
> Ballet via CMake
> *Sent:* Tuesday, April 12, 2016 5:30 PM
> *To:* cmake@cmake.org
> *Subject:* [CMake] issue with target_link_libraries and MSVC
>
>
>
> I'm trying to add the openmp flag to a target with target_link_libraries.
>
> \openmp is interpreted as a file name and visual try to link to \openmp.obj
>
>
>
> The documentation state that target_link_libraries see an item as a flag
> if it start with - but MSVC flags start with \
>
>
>
> Is there a way to add a link flags to a target with target_link_libraries
> and MSVC ?
>
>
>
> Thank you all
>
>
>
> --
>
> *Benjamin BALLET*
> Ingénieur R
>
>
> *ACTIVISU*
>
> 19, rue Klock - 92110 Clichy
>
> *> Standard Tél* :  01 44 69 37 37
>
> *>* www.activisu.com
>
>
>
>
>
> --
>
> *Benjamin BALLET*
> Ingénieur R
>
>
> *ACTIVISU*
>
> 19, rue Klock - 92110 Clichy
>
> *> Standard Tél* :  01 44 69 37 37
>
> *>* www.activisu.com
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] issue with target_link_libraries and MSVC

[Benjamin Ballet via CMake]

Ho yes, my bad, however there is still the same issue with forward slashes

I receive the flag with FindOpenMP module. It's sad we can't do :
target_link_libraries(... ${OpenMP_CXX_FLAGS}) for a few target

In the end I add the flags for the whole project :
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")

2016-04-13 7:54 GMT+02:00 Matějů Miroslav, Ing. <mateju.miros...@azd.cz>:

> Hi Benjamin,
>
>
>
> MSVC flags start with “forward” slashes: / (However, MSVC also accepts
> hyphens (-) in my experience.)
>
> Documentation for /openmp flag:
> https://msdn.microsoft.com/library/fw509c3b.aspx
>
>
>
> Best regards,
>
> Miroslav
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Benjamin
> Ballet via CMake
> *Sent:* Tuesday, April 12, 2016 5:30 PM
> *To:* cmake@cmake.org
> *Subject:* [CMake] issue with target_link_libraries and MSVC
>
>
>
> I'm trying to add the openmp flag to a target with target_link_libraries.
>
> \openmp is interpreted as a file name and visual try to link to \openmp.obj
>
>
>
> The documentation state that target_link_libraries see an item as a flag
> if it start with - but MSVC flags start with \
>
>
>
> Is there a way to add a link flags to a target with target_link_libraries
> and MSVC ?
>
>
>
> Thank you all
>
>
>
> --
>
> *Benjamin BALLET*
> Ingénieur R
>
>
> *ACTIVISU*
>
> 19, rue Klock - 92110 Clichy
>
> *> Standard Tél* :  01 44 69 37 37
>
> *>* www.activisu.com
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] issue with target_link_libraries and MSVC

[Benjamin Ballet via CMake]

I'm trying to add the openmp flag to a target with target_link_libraries.
\openmp is interpreted as a file name and visual try to link to \openmp.obj

The documentation state that target_link_libraries see an item as a flag if
it start with - but MSVC flags start with \

Is there a way to add a link flags to a target with target_link_libraries
and MSVC ?

Thank you all

-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake