Re: [CMake] CMake 3.7.1 gui fails to launch

[Alan W. Irwin]

On 2017-01-06 12:41-0500 da...@daryllee.com wrote:

As it turns out, no, I can't use Qt5.  In fact, I'd love to hear from anyone 
who actually has.


My "ldd -r" results for cmake-gui show my recent bootstrap builds (of
cmake-3.7.0) have been built with Qt5 without linking issues.  I
didn't do anything special for Qt5 other than to install its
development packages (for Debian Jessie in my case).  So I think if
you did the same, it would just work.  That said, ~6 months or so ago,
I didn't have Qt5 installed on my system so my cmake-gui builds back
then were done (without issues) using Qt4.

Also, I have used the combination of cmake and Qt5 in other contexts.  The
issue that is likely confusing you (since it confused me at first
encounter as well) is Qt5 cmake support is provided directly by Qt5
(see  which is provided by
Qt5 developers and not cmake developers).

So, for example, the PLplot build system uses either Qt4 (based on
CMake support provided by CMake) or Qt5 (based on CMake support provided
by Qt5) and my recent (6 months ago and now) experience with CMake
builds is they also work fine for either Qt4 or Qt5.

So like others here have commented, I suspect you have some Qt4
installation issue (e.g., a mixture of private and system versions)
that is causing your present difficulties.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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 3.7.1 gui fails to launch

[daryl]

As it turns out, no, I can't use Qt5.  In fact, I'd love to hear from  
anyone who actually has.  I find this in Modules/FindQt.make:


===
if (Qt_FIND_VERSION)
  if (Qt_FIND_VERSION MATCHES "^([34])(\\.[0-9]+.*)?$")
set(DESIRED_QT_VERSION ${CMAKE_MATCH_1})
  else ()
message(FATAL_ERROR "FindQt was called with invalid version  
'${Qt_FIND_VERSION}'. Only Qt major versions 3 or 4 are supported. If  
you do not need to support both Qt3 and Qt4 in your source consider  
calling find_package(Qt3) or find_package(Qt4) instead of  
find_package(Qt) instead.")

  endif ()
endif ()
===

So I re-installed Qt4, rebuilt CMake (./bootstrap --qt-gui, make, sudo  
make install) and still got the same runtime failure.


Quoting David Cole <dlrd...@aol.com>:


Can you use Qt5? CMake 3.7 is typically built using Qt5: perhaps a Qt5
**requirement** has crept in since it's the commonly used one now.


HTH,
David C.



On Fri, Jan 6, 2017 at 10:41 AM,  <da...@daryllee.com> wrote:

I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake
to run.  (The apt-get version is 2.8).

I installed Qt4 (version 4.8.6) with

  $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools

I installed cmake

  $ ./bootstrap & make & sudo make install

all seemed to run without issue.  Running "cmake-gui --version" reported
version 3.7.1, but running "cmake-gui" failed:

=
daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version
cmake version 3.7.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).
daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui
cmake-gui: symbol lookup error: cmake-gui: undefined symbol:
_ZN9QListData11detach_growEPii
==

That looks like a Qt linkage error.  Any suggestions on resolving this?
--

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] CMake 3.7.1 gui fails to launch

[Andreas Pakulat]

Hi,

On Fri, Jan 6, 2017 at 4:41 PM,  <da...@daryllee.com> wrote:
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui
> cmake-gui: symbol lookup error: cmake-gui: undefined symbol:
> _ZN9QListData11detach_growEPii
> ==
>
> That looks like a Qt linkage error.  Any suggestions on resolving this?

Right, in particular it means that cmake-gui uses that symbol but none
of the libraries loaded into the executable have it. I'd start with
checking what ldd says is being loaded for your cmake-gui executable.
Maybe there's another Qt installation in LD_LIBRARY_PATH that is being
used for running cmake-gui even though its been built against the Qt
in /usr/. The other common cause could be the inverse of that, its
trying to run against your system Qt but the build process has picked
up a Qt from elsewhere compiled with different flags that change the
symbols name.

Andreas
-- 

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 3.7.1 gui fails to launch

[Konstantin Podsvirov]

Hm...18:52, 6 january 2017 г., David Cole via CMake <cmake@cmake.org>:Can you use Qt5? CMake 3.7 is typically built using Qt5: perhaps a Qt5**requirement** has crept in since it's the commonly used one now.It's work for me with RedHat and Qt 4.8.6.No problem cmake-gui work.HTH,David C.On Fri, Jan 6, 2017 at 10:41 AM,  <da...@daryllee.com> wrote: I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake to run.  (The apt-get version is 2.8). I installed Qt4 (version 4.8.6) with   $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools I installed cmake   $ ./bootstrap & make & sudo make install all seemed to run without issue.  Running "cmake-gui --version" reported version 3.7.1, but running "cmake-gui" failed: = daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version cmake version 3.7.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui cmake-gui: symbol lookup error: cmake-gui: undefined symbol: _ZN9QListData11detach_growEPii == That looks like a Qt linkage error.  Any suggestions on resolving this? -- 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.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlFollow this link to subscribe/unsubscribe:http://public.kitware.com/mailman/listinfo/cmakeОтправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail
-- 

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 3.7.1 gui fails to launch

[David Cole via CMake]

Can you use Qt5? CMake 3.7 is typically built using Qt5: perhaps a Qt5
**requirement** has crept in since it's the commonly used one now.


HTH,
David C.



On Fri, Jan 6, 2017 at 10:41 AM,  <da...@daryllee.com> wrote:
> I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake
> to run.  (The apt-get version is 2.8).
>
> I installed Qt4 (version 4.8.6) with
>
>   $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools
>
> I installed cmake
>
>   $ ./bootstrap & make & sudo make install
>
> all seemed to run without issue.  Running "cmake-gui --version" reported
> version 3.7.1, but running "cmake-gui" failed:
>
> =
> daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version
> cmake version 3.7.1
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui
> cmake-gui: symbol lookup error: cmake-gui: undefined symbol:
> _ZN9QListData11detach_growEPii
> ==
>
> That looks like a Qt linkage error.  Any suggestions on resolving this?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake 3.7.1 gui fails to launch

[daryl]

I'm running Ubuntu 14.04 and I'm trying to get the current version of  
CMake to run.  (The apt-get version is 2.8).


I installed Qt4 (version 4.8.6) with

  $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools

I installed cmake

  $ ./bootstrap & make & sudo make install

all seemed to run without issue.  Running "cmake-gui --version"  
reported version 3.7.1, but running "cmake-gui" failed:


=====
daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version
cmake version 3.7.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).
daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui
cmake-gui: symbol lookup error: cmake-gui: undefined symbol:  
_ZN9QListData11detach_growEPii

==

That looks like a Qt linkage error.  Any suggestions on resolving this?
--

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 project with fpp preprocessed Fortran source file failed

[turbulent]

Hi,

I'm trying to use fpp preprocessor in a Fortran project built with CMake. For 
example, 
I have two source files. The file x.f90 defines module x:

module x
#ifdef ENABLE_Z
  use z
#endif
  implicit none
end module x

The module z used in module x is defined in z.f90 as followed:

module z
  implicit none
  integer :: z_a
end module z

Below is the CMakeLists.txt:

cmake_minimum_required(VERSION 3.1)

project(foo Fortran)

set_source_files_properties(x.f90
  PROPERTIES
  COMPILE_DEFINITIONS "ENABLE_Z"
  )

add_library(mylib
  x.f90
  z.f90
  )

I use "MinGW Makefile" generator and Intel Parallel Studio XE 2015 to build 
mylib 
under windows 7 command console: 

D:\dev\cmake\fortran_depend_fpp\build>cmake -G"MinGW Makefiles" -DCMAKE_Fortran_
COMPILER=ifort ..\src
-- The Fortran compiler identification is Intel 15.0.2.20150121
-- Check for working Fortran compiler: C:/Intel/Composer XE 2015/bin/intel64/ifo
rt.exe
-- Check for working Fortran compiler: C:/Intel/Composer XE 2015/bin/intel64/ifo
rt.exe  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether C:/Intel/Composer XE 2015/bin/intel64/ifort.exe supports For
tran 90
-- Checking whether C:/Intel/Composer XE 2015/bin/intel64/ifort.exe supports For
tran 90 -- yes
-- Configuring done
-- Generating done
-- Build files have been written to: D:/dev/cmake/fortran_depend_fpp/build

When building library mylib, it failed:

D:\dev\cmake\fortran_depend_fpp\build>mingw32-make mylib
Scanning dependencies of target mylib
[ 33%] Building Fortran object CMakeFiles/mylib.dir/x.f90.obj
D:\dev\cmake\fortran_depend_fpp\src\x.f90(4): error #7002: Error in opening the
compiled module file.  Check INCLUDE paths.   [Z]
  use z
--^
compilation aborted for D:\dev\cmake\fortran_depend_fpp\src\x.f90 (code 1)
CMakeFiles\mylib.dir\build.make:61: recipe for target 'CMakeFiles/mylib.dir/x.f9
0.obj' failed
mingw32-make[3]: *** [CMakeFiles/mylib.dir/x.f90.obj] Error 1
CMakeFiles\Makefile2:104: recipe for target 'CMakeFiles/mylib.dir/all' failed
mingw32-make[2]: *** [CMakeFiles/mylib.dir/all] Error 2
CMakeFiles\Makefile2:117: recipe for target 'CMakeFiles/mylib.dir/rule' failed
mingw32-make[1]: *** [CMakeFiles/mylib.dir/rule] Error 2
Makefile:130: recipe for target 'mylib' failed
mingw32-make: *** [mylib] Error 2

The reason is that x.f90 is compiled before z.f90. It seems that the makefile 
doesn't 
contain the rule about module x's dependency on module z. How could I correct 
it? 
Thanks in advance for your suggestions.

BTW: the "Visual Studio 12 2013" generator works fine.-- 

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 vs. Python 3.4

[Levente]

Yes. That did the trick. Sorry for the noise.

On 23 Dec 2016 23:52, "Dan Liew"  wrote:

>
>
> On 23 Dec 2016 7:58 pm, "Lev"  wrote:
>
> Hi list,
>
>
> I have this:
>
> FIND_PACKAGE(PythonInterp)
>
> and cmake finds this:
>
> -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
>
> However, 3.4 is also installed. How can I specify to find 3.4?
>
> If I say:
>
> set(Python_ADDITIONAL_VERSIONS 3.4)
> FIND_PACKAGE(PythonInterp 3 REQUIRED)
>
> still no luck.
>
> When you did that did you wipe the CMake cache (e.g. delete any existing
> binary build directory)? In many cases where CMake is asked to find a
> binary it will create a cache variable if it was found so that on
> subsequent runs of CMake it doesn't have to search for it again. You may be
> hitting this.
>
>
>
-- 

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 vs. Python 3.4

[Rolf Eike Beer]

Am Samstag, 24. Dezember 2016, 12:06:10 schrieb Rolf Eike Beer:
> Am Freitag, 23. Dezember 2016, 20:57:49 schrieb Lev:
> > Hi list,
> > 
> > 
> > I have this:
> > 
> > FIND_PACKAGE(PythonInterp)
> > 
> > and cmake finds this:
> > 
> > -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
> > 
> > However, 3.4 is also installed. How can I specify to find 3.4?
> > 
> > If I say:
> > 
> > set(Python_ADDITIONAL_VERSIONS 3.4)
> > FIND_PACKAGE(PythonInterp 3 REQUIRED)
> 
> The problem here is the "REQUIRED". Older CMake versions did not let "3.4"
> satisfy "3" as required version, what newer versions do. However they let it
> pass as a minimum version. And you don't need to add 3.4 to the list of
> supported versions, if I read the log correct then 3.4 is already in the
> list for CMake 3.0.

Ehm, the "3" would not satisfy EXACT, but it of course satisfies REQUIRED. And 
it works for me, btw.

Eike

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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake vs. Python 3.4

[Rolf Eike Beer]

Am Freitag, 23. Dezember 2016, 20:57:49 schrieb Lev:
> Hi list,
> 
> 
> I have this:
> 
> FIND_PACKAGE(PythonInterp)
> 
> and cmake finds this:
> 
> -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
> 
> However, 3.4 is also installed. How can I specify to find 3.4?
> 
> If I say:
> 
> set(Python_ADDITIONAL_VERSIONS 3.4)
> FIND_PACKAGE(PythonInterp 3 REQUIRED)

The problem here is the "REQUIRED". Older CMake versions did not let "3.4" 
satisfy "3" as required version, what newer versions do. However they let it 
pass as a minimum version. And you don't need to add 3.4 to the list of 
supported versions, if I read the log correct then 3.4 is already in the list 
for CMake 3.0.

Eike, having done most of this version detection stuff

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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake vs. Python 3.4

[Dan Liew]

On 23 Dec 2016 7:58 pm, "Lev"  wrote:

Hi list,


I have this:

FIND_PACKAGE(PythonInterp)

and cmake finds this:

-- Found PythonInterp: /usr/bin/python (found version "2.7.9")

However, 3.4 is also installed. How can I specify to find 3.4?

If I say:

set(Python_ADDITIONAL_VERSIONS 3.4)
FIND_PACKAGE(PythonInterp 3 REQUIRED)

still no luck.

When you did that did you wipe the CMake cache (e.g. delete any existing
binary build directory)? In many cases where CMake is asked to find a
binary it will create a cache variable if it was found so that on
subsequent runs of CMake it doesn't have to search for it again. You may be
hitting this.
-- 

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 vs. Python 3.4

[Elizabeth A. Fischer]

>
> Try using the update-alternatives command so that "python" becomes
> symbolically linked to python-3.4 rather than python-2.7.9
>
> Or uninstall python 2.7.9.
>

The standard Python distribution for versions 3 or greater installs a
binary called `python3`, not `python`.  That is the standard.  If you are
running Python3 from a binary called `python`, that is not standard.  I
know that distros do this (or can do it with tweaking); but that doesn't
make it standard.  If you want to be sure you're getting Python3, you
should look for a binary called `python3`.

Does FindPython not have logic to check the versioned pythonx.y
> alternatives when doing these checks?  Why isn't it checking the python3
> and python3.x commands in this circumstance?


Have you tried the FindPython I referenced above?  It would solve the
problems you brought to this thread (and maybe even some you didn't yet
know you have).
-- 

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 vs. Python 3.4

[Lev]

On Fri, 23 Dec 2016 12:53:30 -0800 (PST)
"Alan W. Irwin"  wrote:

> Try using the update-alternatives command so that "python" becomes
> symbolically linked to python-3.4 rather than python-2.7.9
> 
> Or uninstall python 2.7.9.

Ok. Thanks both of you.


Merry XMAS,
Levente

-- 
73 de HA5OGL
Op.: Levente
-- 

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 vs. Python 3.4

[Scott Kitterman]

On Friday, December 23, 2016 12:53:30 PM Alan W. Irwin wrote:
> On 2016-12-23 20:57+0100 Lev wrote:
> > Hi list,
> > 
> > 
> > I have this:
> > 
> > FIND_PACKAGE(PythonInterp)
> > 
> > and cmake finds this:
> > 
> > -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
> > 
> > However, 3.4 is also installed. How can I specify to find 3.4?
> > 
> > If I say:
> > 
> > set(Python_ADDITIONAL_VERSIONS 3.4)
> > FIND_PACKAGE(PythonInterp 3 REQUIRED)
> > 
> > still no luck.
> > 
> > This is on a Debian stable, so
> > 
> > $ cmake --version
> > cmake version 3.0.2
> 
> Try using the update-alternatives command so that "python" becomes
> symbolically linked to python-3.4 rather than python-2.7.9
> 
> Or uninstall python 2.7.9.

No.  Don't do that.  Debian (and its derivatives don't work that way).

The way I've done this before (when building for multiple python and python3 
versions is to set:

PYTHON_EXECUTABLE=/usr/bin/python$v

Where $v would, in your case, be 3.4.

Scott K
-- 

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 vs. Python 3.4

[Roger Leigh]

On 23/12/16 20:53, Alan W. Irwin wrote:

On 2016-12-23 20:57+0100 Lev wrote:


Hi list,


I have this:

FIND_PACKAGE(PythonInterp)

and cmake finds this:

-- Found PythonInterp: /usr/bin/python (found version "2.7.9")

However, 3.4 is also installed. How can I specify to find 3.4?

If I say:

set(Python_ADDITIONAL_VERSIONS 3.4)
FIND_PACKAGE(PythonInterp 3 REQUIRED)

still no luck.

This is on a Debian stable, so

$ cmake --version
cmake version 3.0.2


Try using the update-alternatives command so that "python" becomes
symbolically linked to python-3.4 rather than python-2.7.9

Or uninstall python 2.7.9.


This seems a little drastic; I wouldn't expect to have to alter the 
system for cmake to do what I want.  Does FindPython not have logic to 
check the versioned pythonx.y alternatives when doing these checks?  Why 
isn't it checking the python3 and python3.x commands in this circumstance?


Or, give the incompatibility here, do we need a separate 
FindPython3Interp and equivalents so that we can find Python 2 and 3 
version of the executable and libs independently.  This is something 
which has been bugging me for a while since the current behaviour seems 
somewhat unsatisfactory.



Regards,
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/opensource/opensource.html

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

Re: [CMake] cmake vs. Python 3.4

[Alan W. Irwin]

On 2016-12-23 20:57+0100 Lev wrote:


Hi list,


I have this:

FIND_PACKAGE(PythonInterp)

and cmake finds this:

-- Found PythonInterp: /usr/bin/python (found version "2.7.9")

However, 3.4 is also installed. How can I specify to find 3.4?

If I say:

set(Python_ADDITIONAL_VERSIONS 3.4)
FIND_PACKAGE(PythonInterp 3 REQUIRED)

still no luck.

This is on a Debian stable, so

$ cmake --version
cmake version 3.0.2


Try using the update-alternatives command so that "python" becomes
symbolically linked to python-3.4 rather than python-2.7.9

Or uninstall python 2.7.9.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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 vs. Python 3.4

[Lev]

Hi list,


I have this:

FIND_PACKAGE(PythonInterp)

and cmake finds this:

-- Found PythonInterp: /usr/bin/python (found version "2.7.9")

However, 3.4 is also installed. How can I specify to find 3.4?

If I say:

set(Python_ADDITIONAL_VERSIONS 3.4)
FIND_PACKAGE(PythonInterp 3 REQUIRED)

still no luck.

This is on a Debian stable, so

$ cmake --version
cmake version 3.0.2


Thanks,
Levente

--
73 de HA5OGL
Op.: Levente
-- 

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

[Dan Liew]

Hi Aishwarya,

On 21 December 2016 at 11:51, aishwarya selvaraj
 wrote:
> Hi Everyone,
> Myself Aishwarya .I wanted to make use of Cmake , but I'm really new to this
> and doesn't have a clear idea about it.
>
> 1) My Goal :
> I'm using Praat a speech Processing Software to create plug - in for my
> Algorithm on Pitch and Time scaling .(I have the .cpp file)
> In order to do that I need to use the binary file obtained by compiling .cpp
> file
> in my Praat Script .
> I intent to share this plug - in with others ,Hence I want it to be machine
> independent .The binary file I obtained is using gcc in Linux (16.0.2),
> which clearly wont work in Mac or Windows or even in lower Linux Version.
> To solve this Problem I understand that I need to make use of Cmake files .

CMake is not going make your binaries machine independent. It can give
a way to build your application that will successfully compile on
different platforms but you will have to compile the binary on each
platform that you are targeting.

> 2) My .cpp file called TSM_CODE_V3.cpp is compiled as
> g++ TSM_CODE_V3.cpp -larmadillo -lsndfile -o TSM
>
> where armadillo and sndfile are two depended libraries.
>
> 3) What I have done :
> I have gone through a loot of tutorials for cmake .I have wage idea , but
> I'm not able to solve my problem mentioned above .
> My folder TSM consists of
> build - the folder which consists the final executable binary file and the
> related cmake files required to create binary file
> src - consists of my TSM_CODE_V3.cpp code
> CMakeLists.txt - The top level Cmake file :
>
>  cmake_minimum_required(VERSION 2.8.9)
>  project(directory_TSM)
>  include_directories(include)
>  file(GLOB SOURCES "src/*.cpp")
>  add_executable(tsm ${SOURCES})

Do not use `file(GLOB ...)` to find source files. It is very bad
practice because it prevents CMake from re-generating itself
automatically. You should list the source files explicitly. That way
when you add/remove a source file the fact you updated the
`CMakeLists.txt` file will trigger a re-configure of the build system.

>
> I need to include the library armadillo and lidsndfile .
> I dont know how to include it into my cmakefile .
> I have come across find_package ,find_library  but I am sure about it .
>  To create my Praat Plug - in I need to compile the source code no matter in
> which system it is ,which may or may not have these two libraries already
> installed.
> So how how do I add libraries using cmake ?

Use `target_link_libraries()` to link libraries into your target. If
you're not sure how to use it I highly recommend you read the
documentation for it [1].

In terms of finding the library if there is no package for those
libraries you can use the `find_library()` command. Again if you're
not sure how to use it check out the documentation [2].

Seeing as you are very new to CMake I would also recommend reading [3]
which explains some important high level concepts in CMake.

[1] https://cmake.org/cmake/help/v3.6/command/target_link_libraries.html
[2] https://cmake.org/cmake/help/v3.6/command/find_library.html
[3] https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html
-- 

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

[Stuermer, Michael SP/HZA-ZSEP]

Hello,

To add your mentioned libraries to the executable you have to link against 
them. For this the cmake command

target_link_libraries() is used: 
https://cmake.org/cmake/help/v3.7/command/target_link_libraries.html

In your case the cmake code should look similar to this:

target_link_libraries(tsm armadillo lidsndfile)

best regards,
Michael

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of aishwarya selvaraj
Sent: Wednesday, December 21, 2016 12:52 PM
To: cmake@cmake.org
Subject: [CMake] Cmake

Hi Everyone,
Myself Aishwarya .I wanted to make use of Cmake , but I'm really new to this 
and doesn't have a clear idea about it.
1) My Goal :
I'm using Praat a speech Processing Software to create plug - in for my 
Algorithm on Pitch and Time scaling .(I have the .cpp file)
In order to do that I need to use the binary file obtained by compiling .cpp 
file
​in my Praat Script .
I intent to share this plug - in with others ,Hence I want it to be machine 
independent .The binary file I obtained is using gcc in Linux (16.0.2), which 
clearly wont work in Mac or Windows or even in lower Linux Version.
To solve this Problem I understand that I need to make use of Cmake files .
2) My .cpp file called TSM_CODE_V3.cpp is compiled as
g++ TSM_CODE_V3.cpp -larmadillo -lsndfile -o TSM
where armadillo and sndfile are two depended libraries.

3) What I have done :
​I have gone through a loot of tutorials for cmake .I have wage idea , but I'm 
not able to solve my problem mentioned above .
​My folder TSM consists of
build - the folder which consists the final executable binary file and the 
related cmake files required to create binary file
src - consists of my TSM_CODE_V3.cpp code
CMakeLists.txt - The top level Cmake file :

 cmake_minimum_required(VERSION 2.8.9)
 project(directory_TSM)
 include_directories(include)
 file(GLOB SOURCES "src/*.cpp")
 add_executable(tsm ${SOURCES})

I need to include the library armadillo and lidsndfile .
I dont know how to include it into my cmakefile .
I have come across find_package ,find_library  but I am sure about it .
 To create my Praat Plug - in I need to compile the source code no matter in 
which system it is ,which may or may not have these two libraries already 
installed.
So how how do I add libraries using cmake ?
I hope you got my point .
Could help me ?

Hoping for your reply .

--
Regards,
Aishwarya Selvaraj
-- 

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

[aishwarya selvaraj]

Hi Everyone,
Myself Aishwarya .I wanted to make use of Cmake , but I'm really new to
this and doesn't have a clear idea about it.

1) *My Goal :*
I'm using Praat a speech Processing Software to create plug - in for my
Algorithm on Pitch and Time scaling .(I have the .cpp file)
In order to do that I need to use the binary file obtained by compiling
.cpp file
​in my Praat Script .
I intent to share this plug - in with others ,Hence I want it to be machine
independent .The binary file I obtained is using gcc in Linux (16.0.2),
which clearly wont work in Mac or Windows or even in lower Linux Version.
To solve this Problem I understand that I need to make use of Cmake files .

2) My .cpp file called TSM_CODE_V3.cpp is compiled as
g++ TSM_CODE_V3.cpp -larmadillo -lsndfile -o TSM

where armadillo and sndfile are two depended libraries.

3)* What I have done :*
​I have gone through a loot of tutorials for cmake .I have wage idea , but
I'm not able to solve my problem mentioned above .
​My folder TSM consists of
build - the folder which consists the final executable binary file and the
related cmake files required to create binary file
src - consists of my TSM_CODE_V3.cpp code
CMakeLists.txt - The top level Cmake file :

 cmake_minimum_required(VERSION 2.8.9)
 project(directory_TSM)
 include_directories(include)
 file(GLOB SOURCES "src/*.cpp")
 add_executable(tsm ${SOURCES})


I need to include the library armadillo and lidsndfile .
I dont know how to include it into my cmakefile .
I have come across find_package ,find_library  but I am sure about it .
 To create my Praat Plug - in I need to compile the source code no matter
in which system it is ,which may or may not have these two libraries
already installed.
So how how do I add libraries using cmake ?
I hope you got my point .
Could help me ?


Hoping for your reply .

-- 
Regards,
Aishwarya Selvaraj
-- 

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 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[John Drescher]

On Tue, Nov 8, 2016 at 10:28 AM,   wrote:
>
>
> - On Nov 8, 2016, at 8:13 AM, Taylor Braun-Jones tay...@braun-jones.org 
> wrote:
>
>> On Fri, Nov 4, 2016 at 2:55 PM, Brad King  wrote:
>>>
>>> On 11/03/2016 06:04 PM, John Drescher wrote:
>>> > I opened a project in cmake-gui using the open project button from a
>>> > vc 2010 build of a project. The open project opened the project in
>>> > Visual Studio 2010. Later I opened the same project but a different
>>> > build tree for Visual Studio 2013 CMake-gui had all of the correct
>>> > information for the Visual Studio 2013 build but open project tried to
>>> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
>>> > the expected Visual Studio 2013.
>
> I'm unable to reproduce this problem.  I have multiple Visual Studio 
> installations of different versions.
> I'm not sure whether it could be specific to a project, or specific to 
> installations of visual studio.
>
>>
>> I'm guessing you established MSVS2010 as the default application for
>> opening .sln files the first time you used the open project button.
>> What happens if you double click on that MSVS2013 .sln file?

Sorry for the delay. I went on vacation a few days after emailing
about this issue then forgot to check back when I returned.. If I
click on a .sln it picks the wrong version of Visual Studio as well so
this is not a CMake issue.

Thanks,
John
-- 

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, VS, Nsight Tegra, NDK, mixed C/C++ - applies C++ options to C source

[Scott Eberline]

I suspect that if the first source in a target is C++, every source in
that targets gets CMAKE_CXX_FLAGS, otherwise CMAKE_C_FLAGS. So for
now, mixing C and C++ sources in the same target is broken.

I worked around this issue by putting C sources in their own static
library, and linking that into the main shared library.

Florent, thanks for the response and especially the links. We use the
VS generator for some platforms, Ninja for Android and a couple
others. I'm tasked with improving our edit-build-debug workflow by
specifically migrating to Visual Studio for Android. We have a
modified taka-no-me toolchain file, but current employees don't know
its exact provenance so getting/merging updates is problematic. I
thought the stock toolchain file provided by the latest NDK would give
us the best results, at least until Kitware/CMake,
Microsoft/CMake/VCMDDAndroid, Nsight Tegra VS Edition and the NDK work
out their differences.


On Wed, Dec 14, 2016 at 7:57 PM, Florent Castelli
 wrote:
> I'm pretty sure that the toolchain bundled with the NDK, made by Google,
> hasn't been tested with other generators than Ninja or possibly Make.
> Also, there are some known bugs with it, including the one related to
> CMAKE_CXX_STANDARD (see
> https://code.google.com/p/android/issues/detail?id=227915 and
> https://github.com/android-ndk/ndk/issues/222 ).
>
> I'd recommend using other generators if you want to use this toolchain or
> maybe try the Android support released with CMake 3.7.1 instead, though I
> have no idea if it's supposed to work with the Visual Studio generators
> either!
>
> /Florent
-- 

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, VS, Nsight Tegra, NDK, mixed C/C++ - applies C++ options to C source

[Florent Castelli]

I'm pretty sure that the toolchain bundled with the NDK, made by Google, 
hasn't been tested with other generators than Ninja or possibly Make.
Also, there are some known bugs with it, including the one related to 
CMAKE_CXX_STANDARD (see 
https://code.google.com/p/android/issues/detail?id=227915 and 
https://github.com/android-ndk/ndk/issues/222 ).


I'd recommend using other generators if you want to use this toolchain 
or maybe try the Android support released with CMake 3.7.1 instead, 
though I have no idea if it's supposed to work with the Visual Studio 
generators either!


/Florent

On 15/12/2016 01:44, Scott Eberline wrote:

We have a large project library of mostly C++, mixed with a handful of
C. The C++ compilation commands look correct and work fine. But C
files are passed to clang++.exe -x c, rather than clang.exe. Which
should work, except that CMAKE_CXX_FLAGS is applied while
CMAKE_C_FLAGS is ignored. CMAKE_CXX_FLAGS includes options not
supported for C, so the build fails with messages like,

TRACKEDTOOLTASKWRAPPER`1 : error : invalid argument '-std=c++11' not
allowed with 'C/ObjC'

I've tried overriding the C++ options with C-compatible options, for
example set_source_files_properties(${C_SOURCES} PROPERTIES
COMPILE_FLAGS "-std=c99"). But I've found that per-file COMPILE_FLAGS
precede CMAKE_CXX_FLAGS on the resulting compiler command line, so the
C++ flags still get priority.

I've searched CMake list archives, Stack Overflow, Nvidia's
development tool forums etc. but not found any solution.

(Caveat - I'm trying to use NDK r13b which is not yet supported by
Nsight Tegra. So far, this just involves falsifying the NDK's revision
in its source.properties file, and creating a couple of directory
symbolic links so LLVM libc++ headers can be found where they lived in
NDK r12b. If falsifying the NDK version eventually causes problems,
I'll reconsider it, but for now it seems promising.)

CMake 3.7.1
Visual Studio 2015 Update 3
Nsight Tegra Visual Studio Edition 3.4
NDK r13b

cmake.exe ^
 -DANDROID_PLATFORM=android-24 ^
 -DANDROID_STL=c++_static ^
 -DCMAKE_C_FLAGS="-std=c99" ^
 -DCMAKE_C_STANDARD=99 ^
 -DCMAKE_C_STANDARD_REQUIRED=ON ^
 -DCMAKE_CXX_STANDARD=14 ^
 -DCMAKE_CXX_STANDARD_REQUIRED=ON ^
 
-DCMAKE_TOOLCHAIN_FILE=C:\Android\NDK-r13b\build\cmake\android.toolchain.cmake
^
 -G"Visual Studio 14 2015" ^
 -T"DefaultClang" ^

The generated CMakeCCompiler.cmake looks mostly correct, in particular
CMAKE_C_COMPILER and CMAKE_C_SOURCE_FILE_EXTENSIONS, although
CMAKE__IMPLICIT_LINK_LIBRARIES and
CMAKE__IMPLICIT_LINK_DIRECTORIES are set for android-9 and GNU
libstdc++ rather than the values specified in ANDROID_PLATFORM and
ANDROID_STL. As an aside, it seems ANDROID_PLATFORM, ANDROID_STL,
CMAKE_C_STANDARD and CMAKE_CXX_STANDARD are completely ignored in the
generated VS project. I assume that's a topic for a different thread.

Thanks for taking the time to read; any advice is appreciated.



--

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, VS, Nsight Tegra, NDK, mixed C/C++ - applies C++ options to C source

[Scott Eberline]

We have a large project library of mostly C++, mixed with a handful of
C. The C++ compilation commands look correct and work fine. But C
files are passed to clang++.exe -x c, rather than clang.exe. Which
should work, except that CMAKE_CXX_FLAGS is applied while
CMAKE_C_FLAGS is ignored. CMAKE_CXX_FLAGS includes options not
supported for C, so the build fails with messages like,

TRACKEDTOOLTASKWRAPPER`1 : error : invalid argument '-std=c++11' not
allowed with 'C/ObjC'

I've tried overriding the C++ options with C-compatible options, for
example set_source_files_properties(${C_SOURCES} PROPERTIES
COMPILE_FLAGS "-std=c99"). But I've found that per-file COMPILE_FLAGS
precede CMAKE_CXX_FLAGS on the resulting compiler command line, so the
C++ flags still get priority.

I've searched CMake list archives, Stack Overflow, Nvidia's
development tool forums etc. but not found any solution.

(Caveat - I'm trying to use NDK r13b which is not yet supported by
Nsight Tegra. So far, this just involves falsifying the NDK's revision
in its source.properties file, and creating a couple of directory
symbolic links so LLVM libc++ headers can be found where they lived in
NDK r12b. If falsifying the NDK version eventually causes problems,
I'll reconsider it, but for now it seems promising.)

CMake 3.7.1
Visual Studio 2015 Update 3
Nsight Tegra Visual Studio Edition 3.4
NDK r13b

cmake.exe ^
-DANDROID_PLATFORM=android-24 ^
-DANDROID_STL=c++_static ^
-DCMAKE_C_FLAGS="-std=c99" ^
-DCMAKE_C_STANDARD=99 ^
-DCMAKE_C_STANDARD_REQUIRED=ON ^
-DCMAKE_CXX_STANDARD=14 ^
-DCMAKE_CXX_STANDARD_REQUIRED=ON ^

-DCMAKE_TOOLCHAIN_FILE=C:\Android\NDK-r13b\build\cmake\android.toolchain.cmake
^
-G"Visual Studio 14 2015" ^
-T"DefaultClang" ^

The generated CMakeCCompiler.cmake looks mostly correct, in particular
CMAKE_C_COMPILER and CMAKE_C_SOURCE_FILE_EXTENSIONS, although
CMAKE__IMPLICIT_LINK_LIBRARIES and
CMAKE__IMPLICIT_LINK_DIRECTORIES are set for android-9 and GNU
libstdc++ rather than the values specified in ANDROID_PLATFORM and
ANDROID_STL. As an aside, it seems ANDROID_PLATFORM, ANDROID_STL,
CMAKE_C_STANDARD and CMAKE_CXX_STANDARD are completely ignored in the
generated VS project. I assume that's a topic for a different thread.

Thanks for taking the time to read; any advice is appreciated.
-- 

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] C++11/C++14 doesn't work in check_cxx_source_compiles

[Brad King]

On 11/24/2016 01:43 PM, Roman Wüger wrote:
> Shouldn't this be done by CMAKE_CXX_STANDARD?

Yes, this is a known problem with try_compile.  It needs to learn to honor
the CMAKE__STANDARD.  CMake itself works around this problem in some
cases, e.g.

* 
https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0/Source/Checks/cm_cxx14_cstdio.cmake#L8

Here is a new issue for this:

* https://gitlab.kitware.com/cmake/cmake/issues/16456

-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

Re: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

[Craig Scott]

Sorry, bad link in that last email. The try_compile() docs I meant to link
to are here:

https://cmake.org/cmake/help/latest/command/try_compile.html#other-behavior-settings


On Sat, Nov 26, 2016 at 9:23 AM, Craig Scott <craig.sc...@crascit.com>
wrote:

> Sorry, I misunderstood. I had a look through the
> check_cxx_source_compiles() implementation and it basically forwards
> through to a try_compile() call. Looking at the docs for try_compile(),
> it says only the following are passed through to the temporary CMake
> project created for the test compilation:
>
>
>- CMAKE_ENABLE_EXPORTS
>- CMAKE_LINK_SEARCH_START_STATIC
>- CMAKE_LINK_SEARCH_END_STATIC
>- CMAKE_POSITION_INDEPENDENT_CODE
>
> A few more can be passed through depending on policy settings, but it
> looks like CMAKE_CXX_STANDARD, CMAKE_CXX_STANDARD_REQUIRED and
> CMAKE_CXX_EXTENSIONS don't get passed through. So it looks like, at the
> moment, you would have to manually pass through the relevant compiler and
> linker flags to get sources built via try_compile() and therefore via
> check_cxx_source_compiles(). I've recorded a new issue
> <https://gitlab.kitware.com/cmake/cmake/issues/16456> in the issue
> tracker for this.
>
>
>
>
>
> On Fri, Nov 25, 2016 at 9:25 PM, Roman Wüger <roman.wue...@gmx.at> wrote:
>
>> but it does not set/add the required library
>>
>> Am 24.11.2016 um 22:01 schrieb Craig Scott <craig.sc...@crascit.com>:
>>
>> You might also need to set CMAKE_CXX_EXTENSIONS
>> <https://cmake.org/cmake/help/latest/variable/CMAKE_CXX_EXTENSIONS.html>
>> to OFF (it's ON by default). This controls which c++ library is linked for
>> some compilers, with clang and gcc being two cases where it does this. You
>> may also find this article
>> <https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/> about the
>> related CMake variables and commands to be of interest.
>>
>> On Fri, Nov 25, 2016 at 5:43 AM, Roman Wüger <roman.wue...@gmx.at> wrote:
>>
>>> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES
>>> before the check_cxx_source_compiles() call.
>>>
>>> Shouldn't this be done by CMAKE_CXX_STANDARD?
>>>
>>> Best Regards
>>> Roman
>>>
>>> Am 24.11.2016 um 19:08 schrieb Roman Wüger <roman.wue...@gmx.at>:
>>>
>>> Hello,
>>>
>>>
>>>
>>> If I use a small piece of code which uses , then it fails with
>>> check_cxx_source_compiles. If I copy the piece of code into a file and run
>>> the following on the command line, then it works:
>>>
>>>
>>>
>>> clang++ main.cpp -std=c++14 -stdlib=libc++
>>>
>>>
>>>
>>> Here is the piece of code:
>>>
>>>
>>>
>>> #include 
>>>
>>> #include 
>>>
>>>
>>>
>>> int main() {
>>>
>>> const std::string text = "Roses are #ff, other flowers have
>>> other colors.";
>>>
>>> const std::regex pattern("#([a-f0-9]{2})");
>>>
>>>
>>>
>>> std::smatch match;
>>>
>>> std::regex_search(text, match, pattern);
>>>
>>>
>>>
>>> return 0;
>>>
>>> }
>>>
>>>
>>>
>>> I use this code in CMake as a platform check as followed:
>>>
>>>
>>>
>>> # C++11 Regular Expression
>>>
>>> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}")
>>>
>>> check_cxx_source_compiles(
>>>
>>>   "#include 
>>>
>>>#include 
>>>
>>>
>>>
>>>int main() {
>>>
>>>const std::string text = \"Roses are #ff, other flowers have
>>> other colors.\";
>>>
>>>const std::regex pattern(\"#([a-f0-9]{2})\");
>>>
>>>
>>>
>>>std::smatch match;
>>>
>>>std::regex_search(text, match, pattern);
>>>
>>>
>>>
>>>return 0;
>>>
>>>}"
>>>
>>>   HAVE_CXX11_REGULAR_EXPRESSIONS
>>>
>>> )
>>>
>>> set(CMAKE_REQUIRED_FLAGS "")
>>>
>>>
>>>
>>> CMakeFiles/CMakeError.log shows:
>>>
>>>
>>>
>>> Undefined symbols for architecture x86_64:
>>>
>>>   "std::__1::basic_string<char, std::__1::

Re: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

[Craig Scott]

Sorry, I misunderstood. I had a look through the
check_cxx_source_compiles() implementation and it basically forwards
through to a try_compile() call. Looking at the docs for try_compile()
,
it says only the following are passed through to the temporary CMake
project created for the test compilation:


   - CMAKE_ENABLE_EXPORTS
   - CMAKE_LINK_SEARCH_START_STATIC
   - CMAKE_LINK_SEARCH_END_STATIC
   - CMAKE_POSITION_INDEPENDENT_CODE

A few more can be passed through depending on policy settings, but it looks
like CMAKE_CXX_STANDARD, CMAKE_CXX_STANDARD_REQUIRED and
CMAKE_CXX_EXTENSIONS don't get passed through. So it looks like, at the
moment, you would have to manually pass through the relevant compiler and
linker flags to get sources built via try_compile() and therefore via
check_cxx_source_compiles(). I've recorded a new issue
<https://gitlab.kitware.com/cmake/cmake/issues/16456> in the issue tracker
for this.





On Fri, Nov 25, 2016 at 9:25 PM, Roman Wüger <roman.wue...@gmx.at> wrote:

> but it does not set/add the required library
>
> Am 24.11.2016 um 22:01 schrieb Craig Scott <craig.sc...@crascit.com>:
>
> You might also need to set CMAKE_CXX_EXTENSIONS
> <https://cmake.org/cmake/help/latest/variable/CMAKE_CXX_EXTENSIONS.html>
> to OFF (it's ON by default). This controls which c++ library is linked for
> some compilers, with clang and gcc being two cases where it does this. You
> may also find this article
> <https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/> about the
> related CMake variables and commands to be of interest.
>
> On Fri, Nov 25, 2016 at 5:43 AM, Roman Wüger <roman.wue...@gmx.at> wrote:
>
>> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before
>> the check_cxx_source_compiles() call.
>>
>> Shouldn't this be done by CMAKE_CXX_STANDARD?
>>
>> Best Regards
>> Roman
>>
>> Am 24.11.2016 um 19:08 schrieb Roman Wüger <roman.wue...@gmx.at>:
>>
>> Hello,
>>
>>
>>
>> If I use a small piece of code which uses , then it fails with
>> check_cxx_source_compiles. If I copy the piece of code into a file and run
>> the following on the command line, then it works:
>>
>>
>>
>> clang++ main.cpp -std=c++14 -stdlib=libc++
>>
>>
>>
>> Here is the piece of code:
>>
>>
>>
>> #include 
>>
>> #include 
>>
>>
>>
>> int main() {
>>
>> const std::string text = "Roses are #ff, other flowers have other
>> colors.";
>>
>> const std::regex pattern("#([a-f0-9]{2})");
>>
>>
>>
>> std::smatch match;
>>
>> std::regex_search(text, match, pattern);
>>
>>
>>
>> return 0;
>>
>> }
>>
>>
>>
>> I use this code in CMake as a platform check as followed:
>>
>>
>>
>> # C++11 Regular Expression
>>
>> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}")
>>
>> check_cxx_source_compiles(
>>
>>   "#include 
>>
>>#include 
>>
>>
>>
>>int main() {
>>
>>const std::string text = \"Roses are #ff, other flowers have
>> other colors.\";
>>
>>const std::regex pattern(\"#([a-f0-9]{2})\");
>>
>>
>>
>>std::smatch match;
>>
>>std::regex_search(text, match, pattern);
>>
>>
>>
>>return 0;
>>
>>}"
>>
>>   HAVE_CXX11_REGULAR_EXPRESSIONS
>>
>> )
>>
>> set(CMAKE_REQUIRED_FLAGS "")
>>
>>
>>
>> CMakeFiles/CMakeError.log shows:
>>
>>
>>
>> Undefined symbols for architecture x86_64:
>>
>>   "std::__1::basic_string<char, std::__1::char_traits,
>> std::__1::allocator >::compare(char const*) const", referenced from:
>>
>>   std::__1::basic_regex<char, std::__1::regex_traits
>> >::__start_matching_list(bool) in src.o
>>
>>   "std::__1::__vector_base_common::__throw_length_error() const",
>> referenced from:
>>
>>   std::__1::vector<std::__1::sub_match,
>> std::__1::allocator<std::__1::sub_match >
>> >::assign(unsigned long, std::__1::sub_match const&) in src.o
>>
>>   std::__1::vector<std::__1::sub_match,
>> std::__1::allocator<std::__1::sub_match >
>> >::allocate(unsigned long) in src.o
>>
>>   void std::__1::vector<std::__1::__state,
>> std::__1::allocator<std::__1::__state >
>> >::__push_b

Re: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

[Roman Wüger]

but it does not set/add the required library

> Am 24.11.2016 um 22:01 schrieb Craig Scott :
> 
> You might also need to set CMAKE_CXX_EXTENSIONS to OFF (it's ON by default). 
> This controls which c++ library is linked for some compilers, with clang and 
> gcc being two cases where it does this. You may also find this article about 
> the related CMake variables and commands to be of interest.
> 
>> On Fri, Nov 25, 2016 at 5:43 AM, Roman Wüger  wrote:
>> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before 
>> the check_cxx_source_compiles() call.
>> 
>> Shouldn't this be done by CMAKE_CXX_STANDARD?
>> 
>> Best Regards
>> Roman
>> 
>>> Am 24.11.2016 um 19:08 schrieb Roman Wüger :
>>> 
>>> Hello,
>>> 
>>>  
>>> 
>>> If I use a small piece of code which uses , then it fails with 
>>> check_cxx_source_compiles. If I copy the piece of code into a file and run 
>>> the following on the command line, then it works:
>>> 
>>>  
>>> 
>>> clang++ main.cpp -std=c++14 -stdlib=libc++
>>> 
>>>  
>>> 
>>> Here is the piece of code:
>>> 
>>>  
>>> 
>>> #include 
>>> 
>>> #include 
>>> 
>>>  
>>> 
>>> int main() {
>>> 
>>> const std::string text = "Roses are #ff, other flowers have other 
>>> colors.";
>>> 
>>> const std::regex pattern("#([a-f0-9]{2})");
>>> 
>>>  
>>> 
>>> std::smatch match;
>>> 
>>> std::regex_search(text, match, pattern);
>>> 
>>>  
>>> 
>>> return 0;
>>> 
>>> }
>>> 
>>>  
>>> 
>>> I use this code in CMake as a platform check as followed:
>>> 
>>>  
>>> 
>>> # C++11 Regular Expression
>>> 
>>> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}")
>>> 
>>> check_cxx_source_compiles(
>>> 
>>>   "#include 
>>> 
>>>#include 
>>> 
>>>  
>>> 
>>>int main() {
>>> 
>>>const std::string text = \"Roses are #ff, other flowers have 
>>> other colors.\";
>>> 
>>>const std::regex pattern(\"#([a-f0-9]{2})\");
>>> 
>>>  
>>> 
>>>std::smatch match;
>>> 
>>>std::regex_search(text, match, pattern);
>>> 
>>>  
>>> 
>>>return 0;
>>> 
>>>}"
>>> 
>>>   HAVE_CXX11_REGULAR_EXPRESSIONS
>>> 
>>> )
>>> 
>>> set(CMAKE_REQUIRED_FLAGS "")
>>> 
>>>  
>>> 
>>> CMakeFiles/CMakeError.log shows:
>>> 
>>>  
>>> 
>>> Undefined symbols for architecture x86_64:
>>> 
>>>   "std::__1::basic_string>> std::__1::allocator >::compare(char const*) const", referenced from:
>>> 
>>>   std::__1::basic_regex>> >::__start_matching_list(bool) in src.o
>>> 
>>>   "std::__1::__vector_base_common::__throw_length_error() const", 
>>> referenced from:
>>> 
>>>   std::__1::vector>> std::__1::allocator >::assign(unsigned 
>>> long, std::__1::sub_match const&) in src.o
>>> 
>>>   std::__1::vector>> std::__1::allocator >::allocate(unsigned 
>>> long) in src.o
>>> 
>>>   void std::__1::vector>> std::__1::allocator 
>>> >::__push_back_slow_path>> >(std::__1::__state&&) in src.o
>>> 
>>>   std::__1::vector>> std::__1::allocator >::__append(unsigned 
>>> long, std::__1::sub_match const&) in src.o
>>> 
>>>   std::__1::vector>> std::__1::allocator 
>>> >::__append(unsigned long) in src.o
>>> 
>>>   std::__1::vector>> std::__1::allocator 
>>> >::allocate(unsigned long) in src.o
>>> 
>>>   void std::__1::vector>> >::__push_back_slow_path(char&&) in src.o
>>> 
>>>   ...
>>> 
>>>   "std::__1::__basic_string_common::__throw_length_error() const", 
>>> referenced from:
>>> 
>>>   std::__1::enable_if<__is_forward_iterator::value, void>::type 
>>> std::__1::basic_string>> std::__1::allocator >::__init(char*, char*) in src.o
>>> 
>>>   std::__1::enable_if<__is_forward_iterator::value, 
>>> void>::type std::__1::basic_string>> std::__1::allocator >::__init(char const*, char const*) 
>>> in src.o
>>> 
>>>   
>>> std::__1::enable_if<__is_forward_iterator 
>>> >::value, void>::type std::__1::basic_string>> std::__1::char_traits, std::__1::allocator 
>>> >::__init >(std::__1::__wrap_iter, 
>>> std::__1::__wrap_iter) in src.o
>>> 
>>>   
>>> "std::__1::__match_any_but_newline::__exec(std::__1::__state&) 
>>> const", referenced from:
>>> 
>>>   vtable for std::__1::__match_any_but_newline in src.o
>>> 
>>>   "std::__1::locale::name() const", referenced from:
>>> 
>>>   std::__1::basic_regex>> >::__start_matching_list(bool) in src.o
>>> 
>>>   "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced 
>>> from:

Re: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

[Craig Scott]

You might also need to set CMAKE_CXX_EXTENSIONS
 to
OFF (it's ON by default). This controls which c++ library is linked for
some compilers, with clang and gcc being two cases where it does this. You
may also find this article
 about the related
CMake variables and commands to be of interest.

On Fri, Nov 25, 2016 at 5:43 AM, Roman Wüger  wrote:

> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before
> the check_cxx_source_compiles() call.
>
> Shouldn't this be done by CMAKE_CXX_STANDARD?
>
> Best Regards
> Roman
>
> Am 24.11.2016 um 19:08 schrieb Roman Wüger :
>
> Hello,
>
>
>
> If I use a small piece of code which uses , then it fails with
> check_cxx_source_compiles. If I copy the piece of code into a file and run
> the following on the command line, then it works:
>
>
>
> clang++ main.cpp -std=c++14 -stdlib=libc++
>
>
>
> Here is the piece of code:
>
>
>
> #include 
>
> #include 
>
>
>
> int main() {
>
> const std::string text = "Roses are #ff, other flowers have other
> colors.";
>
> const std::regex pattern("#([a-f0-9]{2})");
>
>
>
> std::smatch match;
>
> std::regex_search(text, match, pattern);
>
>
>
> return 0;
>
> }
>
>
>
> I use this code in CMake as a platform check as followed:
>
>
>
> # C++11 Regular Expression
>
> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}")
>
> check_cxx_source_compiles(
>
>   "#include 
>
>#include 
>
>
>
>int main() {
>
>const std::string text = \"Roses are #ff, other flowers have
> other colors.\";
>
>const std::regex pattern(\"#([a-f0-9]{2})\");
>
>
>
>std::smatch match;
>
>std::regex_search(text, match, pattern);
>
>
>
>return 0;
>
>}"
>
>   HAVE_CXX11_REGULAR_EXPRESSIONS
>
> )
>
> set(CMAKE_REQUIRED_FLAGS "")
>
>
>
> CMakeFiles/CMakeError.log shows:
>
>
>
> Undefined symbols for architecture x86_64:
>
>   "std::__1::basic_string std::__1::allocator >::compare(char const*) const", referenced from:
>
>   std::__1::basic_regex >::__start_matching_list(bool) in src.o
>
>   "std::__1::__vector_base_common::__throw_length_error() const",
> referenced from:
>
>   std::__1::vector std::__1::allocator >::assign(unsigned
> long, std::__1::sub_match const&) in src.o
>
>   std::__1::vector std::__1::allocator
> >::allocate(unsigned long) in src.o
>
>   void std::__1::vector std::__1::allocator
> >::__push_back_slow_path >(std::__1::__state&&) in src.o
>
>   std::__1::vector std::__1::allocator
> >::__append(unsigned long, std::__1::sub_match const&) in src.o
>
>   std::__1::vector std::__1::allocator
> >::__append(unsigned long) in src.o
>
>   std::__1::vector std::__1::allocator
> >::allocate(unsigned long) in src.o
>
>   void std::__1::vector >::__push_back_slow_path(char&&) in src.o
>
>   ...
>
>   "std::__1::__basic_string_common::__throw_length_error() const",
> referenced from:
>
>   std::__1::enable_if<__is_forward_iterator::value,
> void>::type std::__1::basic_string std::__1::allocator >::__init(char*, char*) in src.o
>
>   std::__1::enable_if<__is_forward_iterator::value,
> void>::type std::__1::basic_string std::__1::allocator >::__init(char const*, char const*)
> in src.o
>
>   std::__1::enable_if<__is_forward_iterator
> >::value, void>::type std::__1::basic_string std::__1::char_traits, std::__1::allocator
> >::__init >(std::__1::__wrap_iter,
> std::__1::__wrap_iter) in src.o
>
>   "std::__1::__match_any_but_newline::__exec(std::__1::__state&)
> const", referenced from:
>
>   vtable for std::__1::__match_any_but_newline in src.o
>
>   "std::__1::locale::name() const", referenced from:
>
>   std::__1::basic_regex >::__start_matching_list(bool) in src.o
>
>   "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced
> from:
>
>   std::__1::regex_traits::__init() in src.o
>
>   "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)",
> referenced from:
>
>   char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o
>
>   char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o
>
>   char const* std::__1::basic_regex 

Re: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles

[Roman Wüger]

It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before the 
check_cxx_source_compiles() call.

Shouldn't this be done by CMAKE_CXX_STANDARD?

Best Regards
Roman

> Am 24.11.2016 um 19:08 schrieb Roman Wüger :
> 
> Hello,
>  
> If I use a small piece of code which uses , then it fails with 
> check_cxx_source_compiles. If I copy the piece of code into a file and run 
> the following on the command line, then it works:
>  
> clang++ main.cpp -std=c++14 -stdlib=libc++
>  
> Here is the piece of code:
>  
> #include 
> #include 
>  
> int main() {
> const std::string text = "Roses are #ff, other flowers have other 
> colors.";
> const std::regex pattern("#([a-f0-9]{2})");
>  
> std::smatch match;
> std::regex_search(text, match, pattern);
>  
> return 0;
> }
>  
> I use this code in CMake as a platform check as followed:
>  
> # C++11 Regular Expression
> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}")
> check_cxx_source_compiles(
>   "#include 
>#include 
>  
>int main() {
>const std::string text = \"Roses are #ff, other flowers have other 
> colors.\";
>const std::regex pattern(\"#([a-f0-9]{2})\");
>  
>std::smatch match;
>std::regex_search(text, match, pattern);
>  
>return 0;
>}"
>   HAVE_CXX11_REGULAR_EXPRESSIONS
> )
> set(CMAKE_REQUIRED_FLAGS "")
>  
> CMakeFiles/CMakeError.log shows:
>  
> Undefined symbols for architecture x86_64:
>   "std::__1::basic_string std::__1::allocator >::compare(char const*) const", referenced from:
>   std::__1::basic_regex >::__start_matching_list(bool) in src.o
>   "std::__1::__vector_base_common::__throw_length_error() const", 
> referenced from:
>   std::__1::vector std::__1::allocator >::assign(unsigned 
> long, std::__1::sub_match const&) in src.o
>   std::__1::vector std::__1::allocator >::allocate(unsigned 
> long) in src.o
>   void std::__1::vector std::__1::allocator 
> >::__push_back_slow_path(std::__1::__state&&) 
> in src.o
>   std::__1::vector std::__1::allocator >::__append(unsigned 
> long, std::__1::sub_match const&) in src.o
>   std::__1::vector std::__1::allocator 
> >::__append(unsigned long) in src.o
>   std::__1::vector std::__1::allocator 
> >::allocate(unsigned long) in src.o
>   void std::__1::vector >::__push_back_slow_path(char&&) in src.o
>   ...
>   "std::__1::__basic_string_common::__throw_length_error() const", 
> referenced from:
>   std::__1::enable_if<__is_forward_iterator::value, void>::type 
> std::__1::basic_string std::__1::allocator >::__init(char*, char*) in src.o
>   std::__1::enable_if<__is_forward_iterator::value, 
> void>::type std::__1::basic_string std::__1::allocator >::__init(char const*, char const*) in 
> src.o
>   std::__1::enable_if<__is_forward_iterator 
> >::value, void>::type std::__1::basic_string std::__1::char_traits, std::__1::allocator 
> >::__init >(std::__1::__wrap_iter, 
> std::__1::__wrap_iter) in src.o
>   "std::__1::__match_any_but_newline::__exec(std::__1::__state&) 
> const", referenced from:
>   vtable for std::__1::__match_any_but_newline in src.o
>   "std::__1::locale::name() const", referenced from:
>   std::__1::basic_regex >::__start_matching_list(bool) in src.o
>   "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from:
>   std::__1::regex_traits::__init() in src.o
>   
> "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", 
> referenced from:
>   char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o
>   char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o
>   char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o
>   char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o
>   char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o
>   char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, 
> std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o
>   bool std::__1::basic_regex 

[CMake] CMake and Code Signing in XCode 8 for iOS projects

[Frank]

Hi all,

CMake was able to configure automatic code signing for XCode <=7 and iOS 
projects with a target property setting like


set_target_properties(app PROPERTIES XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY 
"PROPER IDENTIFIER")


XCode 8 changed the signing process. It now is required that the option 
"Automatically manage signing" in the project settings "General tab -> 
Signing" is checked. If I check this options manually for a cmake 
generated project, signing works well. But I did not find a way to 
enable this option from the cmake project by default. Can this be done 
for cmake (>=3.7.0)?


Thanks for any help,
Frank
--

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 Project Generation Speedup

[Damian]

Hi all,

We are still in the process of switching our large Make-based build to
CMake. One of the issues we're running into is the time it takes to reparse
and regenerate the CMake project (whether ninja, VS, or make) after
touching any CMake file. To give you an idea, we have about 1000 targets
and that takes a good 2 min for CMake to rerun.

Are there any plans to speed this up? Maybe parallelize it in some way or
do a better job regenerating only what needs regenerating? Is there
anything we can do on our side to reduce our regeneration times?

For example, if using a VS generator, each directory in the source that has
a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch one
of those CMakeLists.txt, only that .sln/.vcproj would get regenerated.

Thanks for any help.
-- 

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 3.7: Test #379: RunCMake.CPack_RPM fails

[Domen Vrankar]

2016-11-15 15:16 GMT+01:00 Christoph Grüninger :

> Hi Domen,
> thanks for your answer.
>
> > > CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails,
> see
> > > the error below from OBS. I had a brief look at our patches and I am
> apt
> > > to think they are unrelated.
> > > Can someone have a look and give some hint?
> >
> >
> > I'll test it today in the afternoon but for now since sources are
> > missing from the package I'm guessing that debuginfo rpm packaging
> > rpmbuild macro on openSUSE has some differences compared to the one in
> > other distros. CPack/RPM overrides it to compensate for the fact that
> > sources can be generated during build (rpmbuild debuginfo macro only
> > supports packaging of sources located in source dir during packaging so
> > that works only for insource builds...).
>
> I don't know enough about openSuse rpmbuild macro. But I know it works
> for CMake 3.6.2 and broke for 3.7.0. Is test #379 new or was it changed?
>

This is a new test for new functionality - CPackRPM can now generate
debuginfo rpm and source rpm packages (and in git repository there is also
single debuginfo package for all components which missed the 3.7 release
schedule so even more tests that will fail on openSUSE :)).

Yesterday I managed to confirm that the issue is with overriding debuginfo
template macro but failed to find the reason why (openSUSE seems to
generate debuginfo packages without using that macro - it is defined in
main rpm macros file but as far as I can tell it's not used).
I'll try to find a solution for that but since other tests pass the only
drawback is that people won't be able to use this new feature so this
shouldn't be a showstopper for you packaging a new CMake release.

Regards,
Domen
-- 

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 3.7: Test #379: RunCMake.CPack_RPM fails

[Christoph Grüninger]

Hi Domen,
thanks for your answer.

> > CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see
> > the error below from OBS. I had a brief look at our patches and I am apt
> > to think they are unrelated.
> > Can someone have a look and give some hint?
> 
> 
> I'll test it today in the afternoon but for now since sources are
> missing from the package I'm guessing that debuginfo rpm packaging
> rpmbuild macro on openSUSE has some differences compared to the one in
> other distros. CPack/RPM overrides it to compensate for the fact that
> sources can be generated during build (rpmbuild debuginfo macro only
> supports packaging of sources located in source dir during packaging so
> that works only for insource builds...).

I don't know enough about openSuse rpmbuild macro. But I know it works
for CMake 3.6.2 and broke for 3.7.0. Is test #379 new or was it changed?

Bye
Christoph
-- 

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 3.7: Test #379: RunCMake.CPack_RPM fails

[Domen Vrankar]

2016-11-12 14:38 GMT+01:00 Christoph Grüninger :

> Dear CMake folks,
> I am trying to package CMake for openSuse. I was a bit surprised that
> the new dependency libuv was nowhere mentioned. Can it be disabled by a
> configure switch for older systems?
>

If I remember correctly libuv is only used for cmake server mode so if you
don't want libuv dependency you just loose that optional functionality but
this would probably be better to ask in a separate mail as I'm not certain
how many people will look into CPack/RPM specific mail.


> CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see
> the error below from OBS. I had a brief look at our patches and I am apt
> to think they are unrelated.
> Can someone have a look and give some hint?
>

I'll test it today in the afternoon but for now since sources are missing
from the package I'm guessing that debuginfo rpm packaging rpmbuild macro
on openSUSE has some differences compared to the one in other distros.
CPack/RPM overrides it to compensate for the fact that sources can be
generated during build (rpmbuild debuginfo macro only supports packaging of
sources located in source dir during packaging so that works only for
insource builds...).

Regards,
Domen
-- 

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 3.7: Test #379: RunCMake.CPack_RPM fails

[Christoph Grüninger]

Dear CMake folks,
I am trying to package CMake for openSuse. I was a bit surprised that
the new dependency libuv was nowhere mentioned. Can it be disabled by a
configure switch for older systems?

CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see
the error below from OBS. I had a brief look at our patches and I am apt
to think they are unrelated.
Can someone have a look and give some hint?

Sorry that I didn't test already the RCs.

Bye
Christoph



> [ 1041s] 412/413 Test #413: CMake.GetPrerequisites 
> ...   Passed0.61 sec
> [ 1067s] 413/413 Test #379: RunCMake.CPack_RPM 
> ...***Failed   48.75 sec
> [ 1067s] -- MINIMAL - PASSED
> [ 1067s] -- RPM/MINIMAL - PASSED
> [ 1067s] -- SOURCE_PACKAGE - PASSED
> [ 1067s] -- SOURCE_PACKAGE-Build - PASSED
> [ 1067s] -- RPM/SOURCE_PACKAGE - PASSED
> [ 1067s] -- PARTIALLY_RELOCATABLE_WARNING - PASSED
> [ 1067s] -- RPM/PARTIALLY_RELOCATABLE_WARNING - PASSED
> [ 1067s] -- DEPENDENCIES - PASSED
> [ 1067s] -- DEPENDENCIES-Build - PASSED
> [ 1067s] -- RPM/DEPENDENCIES - PASSED
> [ 1067s] -- EMPTY_DIR - PASSED
> [ 1067s] -- EMPTY_DIR-Build - PASSED
> [ 1067s] -- RPM/EMPTY_DIR - PASSED
> [ 1067s] -- COMPONENTS_EMPTY_DIR - PASSED
> [ 1067s] -- COMPONENTS_EMPTY_DIR-Build - PASSED
> [ 1067s] -- RPM/COMPONENTS_EMPTY_DIR - PASSED
> [ 1067s] -- CUSTOM_NAMES - PASSED
> [ 1067s] -- CUSTOM_NAMES-Build - PASSED
> [ 1067s] -- RPM/CUSTOM_NAMES - PASSED
> [ 1067s] -- PER_COMPONENT_FIELDS - PASSED
> [ 1067s] -- RPM/PER_COMPONENT_FIELDS - PASSED
> [ 1067s] -- RPM_DIST - PASSED
> [ 1067s] -- RPM/RPM_DIST - PASSED
> [ 1067s] -- INSTALL_SCRIPTS - PASSED
> [ 1067s] -- RPM/INSTALL_SCRIPTS - PASSED
> [ 1067s] -- DEBUGINFO - PASSED
> [ 1067s] -- DEBUGINFO-Build - PASSED
> [ 1067s] CMake Error at RunCMake.cmake:130 (message):
> [ 1067s]   RPM/DEBUGINFO - FAILED:
> [ 1067s] 
> [ 1067s]   Result is [1], not [0].
> [ 1067s] 
> [ 1067s]   stderr does not match that expected.
> [ 1067s] 
> [ 1067s]   Command was:
> [ 1067s] 
> [ 1067s]command> "/home/abuild/rpmbuild/BUILD/cmake-3.7.0/bin/cmake" 
> "-DRunCMake_TEST=DEBUGINFO" "-DRunCMake_TEST_FILE_PREFIX=DEBUGINFO" 
> "-DRunCMake_SUBTEST_SUFFIX=" "-DGENERATOR_TYPE=RPM" 
> "-Dsrc_dir=/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack" 
> "-Dbin_dir=/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build"
>  
> "-Dconfig_file=/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack/conf/RPM_config.cmake"
>  "-P" 
> "/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack/VerifyResult.cmake"
> [ 1067s] 
> [ 1067s]   Actual stdout:
> [ 1067s] 
> [ 1067s]actual-out> 
> [ 1067s] 
> [ 1067s]   Expected stderr to match:
> [ 1067s] 
> [ 1067s]expect-err> ^CPackRPM: Will use GENERATED spec file: 
> .*/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/.*/RPM/SPECS/debuginfo-applications.spec
> [ 1067s]expect-err> CPackRPM: Will use GENERATED spec file: 
> .*/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/.*/RPM/SPECS/debuginfo-headers.spec
> [ 1067s]expect-err> CPackRPM: Will use GENERATED spec file: 
> .*/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/.*/RPM/SPECS/debuginfo-libs.spec$
> [ 1067s] 
> [ 1067s]   Actual stderr:
> [ 1067s] 
> [ 1067s]actual-err> CMake Error at 
> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack/VerifyResult.cmake:30
>  (message):
> [ 1067s]actual-err>   Unexpected file content for file No.  '4'!
> [ 1067s]actual-err> 
> [ 1067s]actual-err>Content: '/usr/lib/debug
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   /usr/lib/debug/.build-id
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   
> /usr/lib/debug/.build-id/66/e61cff8c1b481720b2f65873db6c559fe1138a
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   
> /usr/lib/debug/.build-id/66/e61cff8c1b481720b2f65873db6c559fe1138a.debug
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   /usr/lib/debug/usr/foo/test_prog.debug'
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   
> [ 1067s]actual-err> 
> [ 1067s]actual-err>Expected: '.*/src[ 
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   
>  ]*/src/src_1[
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   
>  ]*/src/src_1/main.cpp.*'
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack output: 'CPack: Create package using RPM
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack: Install projects
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack: - Run preinstall target for: DEBUGINFO
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack: - Install project: DEBUGINFO
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack: - Install component: applications
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack: - Install component: headers
> [ 1067s]actual-err> 
> [ 1067s]actual-err>   CPack: - Install component: libs
> [ 1067s]

Re: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[clinton]

- On Nov 8, 2016, at 8:13 AM, Taylor Braun-Jones tay...@braun-jones.org 
wrote:

> On Fri, Nov 4, 2016 at 2:55 PM, Brad King <brad.k...@kitware.com> wrote:
>>
>> On 11/03/2016 06:04 PM, John Drescher wrote:
>> > I opened a project in cmake-gui using the open project button from a
>> > vc 2010 build of a project. The open project opened the project in
>> > Visual Studio 2010. Later I opened the same project but a different
>> > build tree for Visual Studio 2013 CMake-gui had all of the correct
>> > information for the Visual Studio 2013 build but open project tried to
>> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
>> > the expected Visual Studio 2013.

I'm unable to reproduce this problem.  I have multiple Visual Studio 
installations of different versions.
I'm not sure whether it could be specific to a project, or specific to 
installations of visual studio.

> 
> I'm guessing you established MSVS2010 as the default application for
> opening .sln files the first time you used the open project button.
> What happens if you double click on that MSVS2013 .sln file?
> 
>> The feature is new in 3.7 and was contributed here:
>>
>>  cmake-gui: Add button to open the generated project
>>  https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1
>>
>> I'm not particularly familiar with how it works, but from a quick
>> glance at the code it may be using file associations.
> 
> Yes, it's just using Windows file file associations, but it shouldn't.
> Since it's possible (and fairly common) to have more than one version
> of Visual Studio installed on a system the Open Project button should
> be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file.
> It should be something like this:
> 
> MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com
> MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com
> MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com
> MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com
> 
> If the correct devenv.exe path does not exist or can't be determined
> for some reason, then I guess it makes sense to fall back to using
> `QDesktopServices::openUrl` to try to open the .sln file with the
> Windows file associations.


It is already using QDesktopServices::openUrl(QUrl::fromLocalFile(...))
AFAIK, that is the correct way to do it.  The .sln file should already know 
what version of Visual Studio it wants to be opened in.

Clint
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[Taylor Braun-Jones]

On Fri, Nov 4, 2016 at 2:55 PM, Brad King <brad.k...@kitware.com> wrote:
>
> On 11/03/2016 06:04 PM, John Drescher wrote:
> > I opened a project in cmake-gui using the open project button from a
> > vc 2010 build of a project. The open project opened the project in
> > Visual Studio 2010. Later I opened the same project but a different
> > build tree for Visual Studio 2013 CMake-gui had all of the correct
> > information for the Visual Studio 2013 build but open project tried to
> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
> > the expected Visual Studio 2013.

I'm guessing you established MSVS2010 as the default application for
opening .sln files the first time you used the open project button.
What happens if you double click on that MSVS2013 .sln file?

> The feature is new in 3.7 and was contributed here:
>
>  cmake-gui: Add button to open the generated project
>  https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1
>
> I'm not particularly familiar with how it works, but from a quick
> glance at the code it may be using file associations.

Yes, it's just using Windows file file associations, but it shouldn't.
Since it's possible (and fairly common) to have more than one version
of Visual Studio installed on a system the Open Project button should
be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file.
It should be something like this:

MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com
MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com
MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com
MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com

If the correct devenv.exe path does not exist or can't be determined
for some reason, then I guess it makes sense to fall back to using
`QDesktopServices::openUrl` to try to open the .sln file with the
Windows file associations.

Taylor
-- 

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 3.6 and OSX

[Gregor Jasny via CMake]

Hello,

On 02/11/2016 06:01, Robert Ramey wrote:
> Here is what I'm seeing:
> 
> a) it looks like CMake is looking for boost_filesystem rather than
> libboost as I expect. (same for system).
> 
> b) even if I tweak findBoost to force the system to look for libboost...
> it still fails
> 
> b) If I follow the suggestion and set BOOST_ROOT to the boost root, it
> still doesn't work.  The BOOST_ROOT variable is discarded when I invoke
> "Configure"
> 
> So again, any suggestions you can offer will be appreciated.

It looks like you use a self-compiled boost library. I never did that
but used homebrew instead. If you download the precompiled tarball from
boost, does it work? (I'm asking because I see a 'Debug' in one of your
paths).

The next thing I would do is to run opensnoop and look what files CMake
tries to access() / open() / stat(). Maybe that gives you a hint.

Hope this helps,
Gregor
-- 

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 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[Brad King]

On 11/03/2016 06:04 PM, John Drescher wrote:
> I opened a project in cmake-gui using the open project button from a
> vc 2010 build of a project. The open project opened the project in
> Visual Studio 2010. Later I opened the same project but a different
> build tree for Visual Studio 2013 CMake-gui had all of the correct
> information for the Visual Studio 2013 build but open project tried to
> open the Visual Studio 2013 solution in Visual Studio 2010 instead of
> the expected Visual Studio 2013. Is there a way to get/force this
> feature to reliably use the correct ide?

The feature is new in 3.7 and was contributed here:

 cmake-gui: Add button to open the generated project
 https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1

I'm not particularly familiar with how it works, but from a quick
glance at the code it may be using file associations.

If all that happened during a single cmake-gui session perhaps some
state is not being cleaned up when changing build trees.

-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

[CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[John Drescher]

I opened a project in cmake-gui using the open project button from a
vc 2010 build of a project. The open project opened the project in
Visual Studio 2010. Later I opened the same project but a different
build tree for Visual Studio 2013 CMake-gui had all of the correct
information for the Visual Studio 2013 build but open project tried to
open the Visual Studio 2013 solution in Visual Studio 2010 instead of
the expected Visual Studio 2013. Is there a way to get/force this
feature to reliably use the correct ide?

Thanks,
John
-- 

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 3.6 and OSX

[Robert Ramey]

Thanks for your help.  I've managed to get past the original problem by 
editing FindBoost so that it checks for version 1.62.  But I'm done yet! 
Now I'm getting


compiler is AppleClang
compiler is AppleClang
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:960 
] _boost_TEST_VERSIONS = 
1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:962 
] Boost_USE_MULTITHREADED = ON
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:964 
] Boost_USE_STATIC_LIBS = ON
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:966 
] Boost_USE_STATIC_RUNTIME =
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:968 
] Boost_ADDITIONAL_VERSIONS =
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:970 
] Boost_NO_SYSTEM_PATHS =
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1038 
] Declared as CMake or Environmental Variables:
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1040 
]   BOOST_ROOT = /Users/robertramey/WorkingProjects/modular-boost
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1042 
]   BOOST_INCLUDEDIR =
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1044 
]   BOOST_LIBRARYDIR = 
/Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1046 
] _boost_TEST_VERSIONS = 
1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1139 
] location of version.hpp: 
/Users/robertramey/WorkingProjects/modular-boost/boost/version.hpp
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1163 
] version.hpp reveals boost 1.62.0
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1249 
] guessed _boost_COMPILER =
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1259 
] _boost_MULTITHREADED = -mt
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1302 
] _boost_RELEASE_ABI_TAG = -
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1304 
] _boost_DEBUG_ABI_TAG = -d
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1358 
] _boost_LIBRARY_SEARCH_DIRS_RELEASE = 
/Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/../lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib_boost_LIBRARY_SEARCH_DIRS_DEBUG 
  = 
/Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/../lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1497 
] Searching for SYSTEM_LIBRARY_RELEASE: 
boost_system-mt-1_62;boost_system-mt;boost_system-mt-1_62;boost_system-mt;boost_system
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1539 
] Searching for SYSTEM_LIBRARY_DEBUG: 
boost_system-mt-d-1_62;boost_system-mt-d;boost_system-mt-d-1_62;boost_system-mt-d;boost_system-mt;boost_system
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1497 
] Searching for FILESYSTEM_LIBRARY_RELEASE: 
boost_filesystem-mt-1_62;boost_filesystem-mt;boost_filesystem-mt-1_62;boost_filesystem-mt;boost_filesystem
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1539 
] Searching for FILESYSTEM_LIBRARY_DEBUG: 
boost_filesystem-mt-d-1_62;boost_filesystem-mt-d;boost_filesystem-mt-d-1_62;boost_filesystem-mt-d;boost_filesystem-mt;boost_filesystem
[ 
/Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1609 
] Boost_FOUND 

Re: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio)

[Cong Monkey]

I have got many compliant that cmake support is not work with even the new
Android Studio, but it is really works for me.

I try ldd on cmake which Android SDK provided, all the so is resolved
correct, which break before.

So, I can imagine that maybe something related to my host environment , I
use DEBIAN Stretch which updates very frequently.

For debian Stretched, the libssl is 1.0.2
For debian Jessie, the libssl is 1.0.0

Is this the source problem? So why minor version change break it?

As the upstream like cmake release fast, I really advice release static
linked version to escape the library break problem which  jetbrains product
followed.

Hope this help!

2016年10月31日 22:13，"Robert Dailey" 写道：

> I'm sorry but that doesn't really answer my questions.
>
> On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey 
> wrote:
> > Try to update your Android SDK from android studio?
> >
> >
> > 2016年10月31日 21:31，"Robert Dailey" 写道：
> >
> > Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> > talking about dev/beta builds?
> >
> > On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey 
> wrote:
> >> The latest release of android studio work with CMAKE well.
> >>
> >> you can create a new project with c++ support to test CMAKE support!
> >>
> >> You can follow https://code.google.com/p/android/issues/detail?id=
> 212007
> >> to get the details.
> >>
> >> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
> >>> I'm at a bit of a loss on finding more information. Can anyone at
> >>> least confirm that this isn't a reliable place to find the answers I'm
> >>> looking for? Does anyone have real experience with android + gradle +
> >>> cmake integration and can provide some pointers?
> >>>
> >>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <
> rcdailey.li...@gmail.com>
> >>> wrote:
>  I'm not sure if the CMake mailing lists are the right place to ask
>  this question but I thought I'd ask just in case someone has gone down
>  this path or has experience with what Google/Gradle is actually trying
>  to accomplish with what seems to be a hand-built version of CMake with
>  custom patches that are not in upstream repositories.
> 
>  Prior to switching to Android Studio / Gradle, I was using Eclipse /
>  Ant. The way I did CMake integration was not really integration at
>  all: I generated Ninja build scripts using CMake and implemented
>  custom targets to run "ant release" after all the C++ projects were
>  built. I made sure that CMake copied relevant *.so files to
>  appropriate directories in the Ant structure so they are packaged with
>  built APKs. That's how I did my Android development.
> 
>  Now that I'm integrating CMake into Gradle, first annoyance I noticed
>  is that I can't use CMake 3.7 (or any external installation of CMake)
>  with Android Studio. It requires a version of CMake installed through
>  SDK Manager. This means I can't use the new Android toolchain
>  functionality built into CMake 3.7 (sad face). But this is something I
>  can work around...
> 
>  Next I found out that stuff I'm setting in my CMake scripts, such as
>  CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>  For whatever reason, Gradle is overriding these from the command line
>  (I'm guessing?). So this requires me to duplicate the toolchain /
>  compiler flag setup I already do in my CMake scripts now in the Gradle
>  build scripts. This seems completely unnecessary and a maintenance
>  burden.
> 
>  What I was expecting Gradle to do was essentially provide me some
>  toolchain file so that CMake can find the compiler and linker to use
>  and then the rest would be determined by CMake itself.
> 
>  Is there a way I can tell Gradle to not take so much control over
>  compiler flags? I want my CMake scripts to do this. I can't imagine
>  they had a good reason to do this. What have others done in this
>  situation with their own Gradle + CMake integration? Looking for
>  advice here, since information is sparse, especially since the Android
>  Studio 2.2 CMake integration is relatively new stuff.
> >>> --
> >>>
> >>> 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 

Re: [CMake] CMake integration in Gradle (Android Studio)

[Cong Monkey]

I have got many compliant that cmake support is not work with even the new
Android Studio, but it is really works for me.

I try ldd on cmake which Android SDK provided, all the so is resolved
correct, which break before.

So, I can imagine that maybe something related to my host environment , I
use DEBIAN Stretch which updates very frequently.

For debian Stretched, the libssl is 1.0.2
For debian Jessie, the libssl is 1.0.0

Is this the source problem? So why minor version change break it?

As the upstream like cmake release fast, I really advice release static
linked version to escape the library break problem which  jetbrains product
followed.

Hope this help!

2016年10月31日 22:13，"Robert Dailey" 写道：

> I'm sorry but that doesn't really answer my questions.
>
> On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey 
> wrote:
> > Try to update your Android SDK from android studio?
> >
> >
> > 2016年10月31日 21:31，"Robert Dailey" 写道：
> >
> > Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> > talking about dev/beta builds?
> >
> > On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey 
> wrote:
> >> The latest release of android studio work with CMAKE well.
> >>
> >> you can create a new project with c++ support to test CMAKE support!
> >>
> >> You can follow https://code.google.com/p/android/issues/detail?id=
> 212007
> >> to get the details.
> >>
> >> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
> >>> I'm at a bit of a loss on finding more information. Can anyone at
> >>> least confirm that this isn't a reliable place to find the answers I'm
> >>> looking for? Does anyone have real experience with android + gradle +
> >>> cmake integration and can provide some pointers?
> >>>
> >>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <
> rcdailey.li...@gmail.com>
> >>> wrote:
>  I'm not sure if the CMake mailing lists are the right place to ask
>  this question but I thought I'd ask just in case someone has gone down
>  this path or has experience with what Google/Gradle is actually trying
>  to accomplish with what seems to be a hand-built version of CMake with
>  custom patches that are not in upstream repositories.
> 
>  Prior to switching to Android Studio / Gradle, I was using Eclipse /
>  Ant. The way I did CMake integration was not really integration at
>  all: I generated Ninja build scripts using CMake and implemented
>  custom targets to run "ant release" after all the C++ projects were
>  built. I made sure that CMake copied relevant *.so files to
>  appropriate directories in the Ant structure so they are packaged with
>  built APKs. That's how I did my Android development.
> 
>  Now that I'm integrating CMake into Gradle, first annoyance I noticed
>  is that I can't use CMake 3.7 (or any external installation of CMake)
>  with Android Studio. It requires a version of CMake installed through
>  SDK Manager. This means I can't use the new Android toolchain
>  functionality built into CMake 3.7 (sad face). But this is something I
>  can work around...
> 
>  Next I found out that stuff I'm setting in my CMake scripts, such as
>  CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>  For whatever reason, Gradle is overriding these from the command line
>  (I'm guessing?). So this requires me to duplicate the toolchain /
>  compiler flag setup I already do in my CMake scripts now in the Gradle
>  build scripts. This seems completely unnecessary and a maintenance
>  burden.
> 
>  What I was expecting Gradle to do was essentially provide me some
>  toolchain file so that CMake can find the compiler and linker to use
>  and then the rest would be determined by CMake itself.
> 
>  Is there a way I can tell Gradle to not take so much control over
>  compiler flags? I want my CMake scripts to do this. I can't imagine
>  they had a good reason to do this. What have others done in this
>  situation with their own Gradle + CMake integration? Looking for
>  advice here, since information is sparse, especially since the Android
>  Studio 2.2 CMake integration is relatively new stuff.
> >>> --
> >>>
> >>> 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 

Re: [CMake] [cmake-developers] CMake integration in Gradle (Android Studio)

[Cong Monkey]

It's my experience which maybe help.

I love Android Studio for its jetbrains style coding experience, but
with some bad style I don't like, like so frequency update and so many
experiment feature which sometimes is a good part like CMake support!

I just love coding and focus my project, but the none product ready
feature make me must fix some ide problem, SDK problem, config problem
is really bad!

So I use CLion to do most c++ related idea test which is mainly focus
c++ native part, and test mix program in a simple java program, all
the technology I use is CMake with CMake Swig support and CMake Java
support which works well in CLion

After the c++ part test is finish, I rewrite some code( mostly just
copy from clion project)  in Android Studio(this make c++ related
works easy in the c++ unfriendly support environment), and then focus
on java side.

If c++ part has problem I will reenter the workflow to test idea in CLion again.

My current working android project use CMake with CMake Swig support,
it's really works great!

Hope this help:)

2016-11-01 21:38 GMT+08:00 Robert Dailey :
> Florent, I had the same thoughts. It seems that the CMake generate +
> build step happen silently as a prerequisite step when doing the
> 'gradle build' command somewhere. It makes it appear as if CMake is
> not running at all, but instead the Java piece of the build is just
> taking forever.
>
> Really I want to get away from ant / eclipse, but unlike Android
> Studio, at least in Eclipse I can view C++ code and edit it. I don't
> know of any other IDE I can use to edit both java & android code. My
> last shining hope is perhaps Visual Studio 2015 and their Android
> support. They have a fork of the CMake repository with some changes
> for generating Android IDE projects for VS, I have not tried it
> though.
>
> What a giant mess this has become... I have no idea what direction to
> go on this. Advice on tooling combinations you guys are using would be
> very helpful though.
>
> On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli
>  wrote:
>> I tried the Gradle + CMake integration and I'm not really impressed.
>> I would recommend not using it right now until they fix the rough edges.
>>
>> The prime concern is that it is REALLY hard to get the CMake output and
>> compilation output,
>> even within Android Studio. If you compile from command line, you won't see
>> much.
>> This is a no go for CI environments where you need to see what went wrong
>> and also some
>> output once in a while (or builds are usually considered stuck and canceled
>> if they take too long).
>> See the issue: https://code.google.com/p/android/issues/detail?id=210930
>>
>> Installing CMake within the SDK is not trivial. There's an open bug with a
>> proposed solution,
>> it's not pretty stuff but does the work:
>> https://code.google.com/p/android/issues/detail?id=221907
>> An alternative would be to repackage your SDK folder after running Android
>> Studio and installing
>> everything you need and distribute that to your CI build machines /
>> developer machines.
>>
>> But essentially, what you want is probably just use their toolchain file,
>> which is much better
>> than the OpenCV one. You can find it bundled in the latest NDK and I guess
>> you could be using
>> that directly with CMake. If it is doing weird things, I guess you could
>> have a look at it and debug it.
>> It's not as complicated as the OpenCV one and I hope you'll find the
>> solution to your issues!
>>
>> As for CMake 3.7, when I asked about it in this mailing list, someone said
>> there will be
>> a compatibility layer to the toolchain to reuse the upstream support when
>> it's available
>> if I remember correctly.
>>
>> /Florent
>>
>>
>> On 25/10/2016 15:48, Robert Dailey wrote:
>>>
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into 

Re: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio)

[Cong Monkey]

My Android Studio Version Info:

Android Studio 2.2.1
Build #AI-145.3330264, built on October 6, 2016

May be the more import part is cmake version, I have two which all works:

~/Android/Sdk/cmake/3.6.3155560
~/Android/Sdk/cmake/3.6.3133135

hope this will be help:)



2016-10-31 22:13 GMT+08:00 Robert Dailey :
> I'm sorry but that doesn't really answer my questions.
>
> On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey  wrote:
>> Try to update your Android SDK from android studio?
>>
>>
>> 2016年10月31日 21:31，"Robert Dailey" 写道：
>>
>> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
>> talking about dev/beta builds?
>>
>> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
>>> The latest release of android studio work with CMAKE well.
>>>
>>> you can create a new project with c++ support to test CMAKE support!
>>>
>>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>>> to get the details.
>>>
>>> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
 I'm at a bit of a loss on finding more information. Can anyone at
 least confirm that this isn't a reliable place to find the answers I'm
 looking for? Does anyone have real experience with android + gradle +
 cmake integration and can provide some pointers?

 On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey 
 wrote:
> I'm not sure if the CMake mailing lists are the right place to ask
> this question but I thought I'd ask just in case someone has gone down
> this path or has experience with what Google/Gradle is actually trying
> to accomplish with what seems to be a hand-built version of CMake with
> custom patches that are not in upstream repositories.
>
> Prior to switching to Android Studio / Gradle, I was using Eclipse /
> Ant. The way I did CMake integration was not really integration at
> all: I generated Ninja build scripts using CMake and implemented
> custom targets to run "ant release" after all the C++ projects were
> built. I made sure that CMake copied relevant *.so files to
> appropriate directories in the Ant structure so they are packaged with
> built APKs. That's how I did my Android development.
>
> Now that I'm integrating CMake into Gradle, first annoyance I noticed
> is that I can't use CMake 3.7 (or any external installation of CMake)
> with Android Studio. It requires a version of CMake installed through
> SDK Manager. This means I can't use the new Android toolchain
> functionality built into CMake 3.7 (sad face). But this is something I
> can work around...
>
> Next I found out that stuff I'm setting in my CMake scripts, such as
> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
> For whatever reason, Gradle is overriding these from the command line
> (I'm guessing?). So this requires me to duplicate the toolchain /
> compiler flag setup I already do in my CMake scripts now in the Gradle
> build scripts. This seems completely unnecessary and a maintenance
> burden.
>
> What I was expecting Gradle to do was essentially provide me some
> toolchain file so that CMake can find the compiler and linker to use
> and then the rest would be determined by CMake itself.
>
> Is there a way I can tell Gradle to not take so much control over
> compiler flags? I want my CMake scripts to do this. I can't imagine
> they had a good reason to do this. What have others done in this
> situation with their own Gradle + CMake integration? Looking for
> advice here, since information is sparse, especially since the Android
> Studio 2.2 CMake integration is relatively new stuff.
 --

 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: 

Re: [CMake] CMake integration in Gradle (Android Studio)

[Cong Monkey]

My Android Studio Version Info:

Android Studio 2.2.1
Build #AI-145.3330264, built on October 6, 2016

May be the more import part is cmake version, I have two which all works:

~/Android/Sdk/cmake/3.6.3155560
~/Android/Sdk/cmake/3.6.3133135

hope this will be help:)



2016-10-31 22:13 GMT+08:00 Robert Dailey :
> I'm sorry but that doesn't really answer my questions.
>
> On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey  wrote:
>> Try to update your Android SDK from android studio?
>>
>>
>> 2016年10月31日 21:31，"Robert Dailey" 写道：
>>
>> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
>> talking about dev/beta builds?
>>
>> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
>>> The latest release of android studio work with CMAKE well.
>>>
>>> you can create a new project with c++ support to test CMAKE support!
>>>
>>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>>> to get the details.
>>>
>>> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
 I'm at a bit of a loss on finding more information. Can anyone at
 least confirm that this isn't a reliable place to find the answers I'm
 looking for? Does anyone have real experience with android + gradle +
 cmake integration and can provide some pointers?

 On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey 
 wrote:
> I'm not sure if the CMake mailing lists are the right place to ask
> this question but I thought I'd ask just in case someone has gone down
> this path or has experience with what Google/Gradle is actually trying
> to accomplish with what seems to be a hand-built version of CMake with
> custom patches that are not in upstream repositories.
>
> Prior to switching to Android Studio / Gradle, I was using Eclipse /
> Ant. The way I did CMake integration was not really integration at
> all: I generated Ninja build scripts using CMake and implemented
> custom targets to run "ant release" after all the C++ projects were
> built. I made sure that CMake copied relevant *.so files to
> appropriate directories in the Ant structure so they are packaged with
> built APKs. That's how I did my Android development.
>
> Now that I'm integrating CMake into Gradle, first annoyance I noticed
> is that I can't use CMake 3.7 (or any external installation of CMake)
> with Android Studio. It requires a version of CMake installed through
> SDK Manager. This means I can't use the new Android toolchain
> functionality built into CMake 3.7 (sad face). But this is something I
> can work around...
>
> Next I found out that stuff I'm setting in my CMake scripts, such as
> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
> For whatever reason, Gradle is overriding these from the command line
> (I'm guessing?). So this requires me to duplicate the toolchain /
> compiler flag setup I already do in my CMake scripts now in the Gradle
> build scripts. This seems completely unnecessary and a maintenance
> burden.
>
> What I was expecting Gradle to do was essentially provide me some
> toolchain file so that CMake can find the compiler and linker to use
> and then the rest would be determined by CMake itself.
>
> Is there a way I can tell Gradle to not take so much control over
> compiler flags? I want my CMake scripts to do this. I can't imagine
> they had a good reason to do this. What have others done in this
> situation with their own Gradle + CMake integration? Looking for
> advice here, since information is sparse, especially since the Android
> Studio 2.2 CMake integration is relatively new stuff.
 --

 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: 

Re: [CMake] [cmake-developers] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Florent, I had the same thoughts. It seems that the CMake generate +
build step happen silently as a prerequisite step when doing the
'gradle build' command somewhere. It makes it appear as if CMake is
not running at all, but instead the Java piece of the build is just
taking forever.

Really I want to get away from ant / eclipse, but unlike Android
Studio, at least in Eclipse I can view C++ code and edit it. I don't
know of any other IDE I can use to edit both java & android code. My
last shining hope is perhaps Visual Studio 2015 and their Android
support. They have a fork of the CMake repository with some changes
for generating Android IDE projects for VS, I have not tried it
though.

What a giant mess this has become... I have no idea what direction to
go on this. Advice on tooling combinations you guys are using would be
very helpful though.

On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli
 wrote:
> I tried the Gradle + CMake integration and I'm not really impressed.
> I would recommend not using it right now until they fix the rough edges.
>
> The prime concern is that it is REALLY hard to get the CMake output and
> compilation output,
> even within Android Studio. If you compile from command line, you won't see
> much.
> This is a no go for CI environments where you need to see what went wrong
> and also some
> output once in a while (or builds are usually considered stuck and canceled
> if they take too long).
> See the issue: https://code.google.com/p/android/issues/detail?id=210930
>
> Installing CMake within the SDK is not trivial. There's an open bug with a
> proposed solution,
> it's not pretty stuff but does the work:
> https://code.google.com/p/android/issues/detail?id=221907
> An alternative would be to repackage your SDK folder after running Android
> Studio and installing
> everything you need and distribute that to your CI build machines /
> developer machines.
>
> But essentially, what you want is probably just use their toolchain file,
> which is much better
> than the OpenCV one. You can find it bundled in the latest NDK and I guess
> you could be using
> that directly with CMake. If it is doing weird things, I guess you could
> have a look at it and debug it.
> It's not as complicated as the OpenCV one and I hope you'll find the
> solution to your issues!
>
> As for CMake 3.7, when I asked about it in this mailing list, someone said
> there will be
> a compatibility layer to the toolchain to reuse the upstream support when
> it's available
> if I remember correctly.
>
> /Florent
>
>
> On 25/10/2016 15:48, Robert Dailey wrote:
>>
>> I'm not sure if the CMake mailing lists are the right place to ask
>> this question but I thought I'd ask just in case someone has gone down
>> this path or has experience with what Google/Gradle is actually trying
>> to accomplish with what seems to be a hand-built version of CMake with
>> custom patches that are not in upstream repositories.
>>
>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>> Ant. The way I did CMake integration was not really integration at
>> all: I generated Ninja build scripts using CMake and implemented
>> custom targets to run "ant release" after all the C++ projects were
>> built. I made sure that CMake copied relevant *.so files to
>> appropriate directories in the Ant structure so they are packaged with
>> built APKs. That's how I did my Android development.
>>
>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>> is that I can't use CMake 3.7 (or any external installation of CMake)
>> with Android Studio. It requires a version of CMake installed through
>> SDK Manager. This means I can't use the new Android toolchain
>> functionality built into CMake 3.7 (sad face). But this is something I
>> can work around...
>>
>> Next I found out that stuff I'm setting in my CMake scripts, such as
>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>> For whatever reason, Gradle is overriding these from the command line
>> (I'm guessing?). So this requires me to duplicate the toolchain /
>> compiler flag setup I already do in my CMake scripts now in the Gradle
>> build scripts. This seems completely unnecessary and a maintenance
>> burden.
>>
>> What I was expecting Gradle to do was essentially provide me some
>> toolchain file so that CMake can find the compiler and linker to use
>> and then the rest would be determined by CMake itself.
>>
>> Is there a way I can tell Gradle to not take so much control over
>> compiler flags? I want my CMake scripts to do this. I can't imagine
>> they had a good reason to do this. What have others done in this
>> situation with their own Gradle + CMake integration? Looking for
>> advice here, since information is sparse, especially since the Android
>> Studio 2.2 CMake integration is relatively new stuff.
>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 

Re: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio)

[Eric Wing]

So I have been using (a custom) CMake + Android Studio/Gradle for some
years now. I only recently saw that both official CMake is adding
Android support, and that the official Android tools are supporting
CMake. I’m actually still confused on the differences between the two
and what each offers in terms of features.

My custom/jury-rigged CMake is derived from the OpenCV Android
toolchain which has forked around for many years. Currently, I have a
combination of custom shell scripts + modified toolchain + modified
CMake to make things work.


My cross-platform requirements have been:

- Must generate be able to generate a new Android Studio/Gradle
project, like how Xcode, Visual Studio, etc. are generated.

- Must handle multiple Android architectures (armv5, armv7, x86, arm64, x86_64)

- Must be able to handle both the native code stuff, and the annoying
Android specific Java code in order to build a complete/working
Android application that can be installed/run through the normal
Android Studio/Gradle user interface.

- Should work on Mac, Linux, and Android



The way it currently works is:

- I have a front end scripts you must run which ultimately invoke
cmake -G “Unix Makefiles” for the Android NDK. These scripts feed my
android toolchain as well as provide the locations to the Android NDK
and SDK. Also, these scripts will generate Gradle and Android Studio
projects. (I basically brute force stripped down a real Gradle/Studio
project and figured out what values I need to inject into it to use as
a template. Many of the injected values are provided from CMake
variables I define in my project CMakeLists.txt)

- The Gradle/Studio project generated has a custom Groovy script phase
that when building, invokes an external shell script as part of the
build process. This external script ultimately calls CMake to build
the native components of the project.

- Because CMake doesn’t handle multiple architectures for Android, my
script actually generates multiple CMake projects, one for each
architecture, separated into directory structures that try to mimic
the official names of the different Android architectures. (This is
kind of brute force, and is not currently easy to opt-out of different
architectures.)

- At the end of the script phase, I use a CMake “install” to copy the
build products for each architecture to the correct location in the
Gradle/Studio Java layout, so the Java part of the build will continue
on doing the right thing.

- The rest of the Gradle/Studio build will continue on and build the
Android Java parts of the project. (I have a specific convention for
where the Android/Java files go in my project structure. Unlike the
annoying thing that Google forced us to do with ndk-build, the Java
stuff is no longer at the root of the source tree, but parked in a
special Android subdirectory. The former was a stupid/evil requirement
for every pre-existing cross-platform project out there, and an
arrogant presumption for new projects, so I did away with it.)



Here are a few videos that show the workflow (in my SDK called Blurrr)

"Workflow" in Swift: The Android Addendum (shows just the Android part)
https://www.youtube.com/watch?v=w6FY_qSi8yY


Workflow": Cross-platform Dev in Swift
(This shows the same project as above, but for the non-Android
platforms, showing it is indeed a single, unified CMake project that
can drive Linux, OS X, iOS, Windows, and Raspberry Pi (and Android).
https://www.youtube.com/watch?v=w8ftI9mpGdY


Blurrr Introduction Part 3 (Shows the different build platforms in a
little more detail. This video is the oldest, so things have improved
a bit.)
https://www.youtube.com/watch?v=exPtM-02YRY



So my wish list for the new CMake versions is that is handles all of
this. (Multi-arch and Gradle/Studio generation especially.)

I have not yet investigated how hard it will be to migrate to one of
the two other versions of CMake. Since Swift is one of my supported
languages, this currently requires me to use a forked CMake I’ve been
working on. However, I am happy to work with people who want to try to
integrate some of my features directly into CMake if they are still
missing (such as the Gradle/Studio generation).

Thanks,
Eric
-- 

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 integration in Gradle (Android Studio)

[Eric Wing]

So I have been using (a custom) CMake + Android Studio/Gradle for some
years now. I only recently saw that both official CMake is adding
Android support, and that the official Android tools are supporting
CMake. I’m actually still confused on the differences between the two
and what each offers in terms of features.

My custom/jury-rigged CMake is derived from the OpenCV Android
toolchain which has forked around for many years. Currently, I have a
combination of custom shell scripts + modified toolchain + modified
CMake to make things work.


My cross-platform requirements have been:

- Must generate be able to generate a new Android Studio/Gradle
project, like how Xcode, Visual Studio, etc. are generated.

- Must handle multiple Android architectures (armv5, armv7, x86, arm64, x86_64)

- Must be able to handle both the native code stuff, and the annoying
Android specific Java code in order to build a complete/working
Android application that can be installed/run through the normal
Android Studio/Gradle user interface.

- Should work on Mac, Linux, and Android



The way it currently works is:

- I have a front end scripts you must run which ultimately invoke
cmake -G “Unix Makefiles” for the Android NDK. These scripts feed my
android toolchain as well as provide the locations to the Android NDK
and SDK. Also, these scripts will generate Gradle and Android Studio
projects. (I basically brute force stripped down a real Gradle/Studio
project and figured out what values I need to inject into it to use as
a template. Many of the injected values are provided from CMake
variables I define in my project CMakeLists.txt)

- The Gradle/Studio project generated has a custom Groovy script phase
that when building, invokes an external shell script as part of the
build process. This external script ultimately calls CMake to build
the native components of the project.

- Because CMake doesn’t handle multiple architectures for Android, my
script actually generates multiple CMake projects, one for each
architecture, separated into directory structures that try to mimic
the official names of the different Android architectures. (This is
kind of brute force, and is not currently easy to opt-out of different
architectures.)

- At the end of the script phase, I use a CMake “install” to copy the
build products for each architecture to the correct location in the
Gradle/Studio Java layout, so the Java part of the build will continue
on doing the right thing.

- The rest of the Gradle/Studio build will continue on and build the
Android Java parts of the project. (I have a specific convention for
where the Android/Java files go in my project structure. Unlike the
annoying thing that Google forced us to do with ndk-build, the Java
stuff is no longer at the root of the source tree, but parked in a
special Android subdirectory. The former was a stupid/evil requirement
for every pre-existing cross-platform project out there, and an
arrogant presumption for new projects, so I did away with it.)



Here are a few videos that show the workflow (in my SDK called Blurrr)

"Workflow" in Swift: The Android Addendum (shows just the Android part)
https://www.youtube.com/watch?v=w6FY_qSi8yY


Workflow": Cross-platform Dev in Swift
(This shows the same project as above, but for the non-Android
platforms, showing it is indeed a single, unified CMake project that
can drive Linux, OS X, iOS, Windows, and Raspberry Pi (and Android).
https://www.youtube.com/watch?v=w8ftI9mpGdY


Blurrr Introduction Part 3 (Shows the different build platforms in a
little more detail. This video is the oldest, so things have improved
a bit.)
https://www.youtube.com/watch?v=exPtM-02YRY



So my wish list for the new CMake versions is that is handles all of
this. (Multi-arch and Gradle/Studio generation especially.)

I have not yet investigated how hard it will be to migrate to one of
the two other versions of CMake. Since Swift is one of my supported
languages, this currently requires me to use a forked CMake I’ve been
working on. However, I am happy to work with people who want to try to
integrate some of my features directly into CMake if they are still
missing (such as the Gradle/Studio generation).

Thanks,
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

I'm sorry but that doesn't really answer my questions.

On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey  wrote:
> Try to update your Android SDK from android studio?
>
>
> 2016年10月31日 21:31，"Robert Dailey" 写道：
>
> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> talking about dev/beta builds?
>
> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
>> The latest release of android studio work with CMAKE well.
>>
>> you can create a new project with c++ support to test CMAKE support!
>>
>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>> to get the details.
>>
>> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
>>> I'm at a bit of a loss on finding more information. Can anyone at
>>> least confirm that this isn't a reliable place to find the answers I'm
>>> looking for? Does anyone have real experience with android + gradle +
>>> cmake integration and can provide some pointers?
>>>
>>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey 
>>> wrote:
 I'm not sure if the CMake mailing lists are the right place to ask
 this question but I thought I'd ask just in case someone has gone down
 this path or has experience with what Google/Gradle is actually trying
 to accomplish with what seems to be a hand-built version of CMake with
 custom patches that are not in upstream repositories.

 Prior to switching to Android Studio / Gradle, I was using Eclipse /
 Ant. The way I did CMake integration was not really integration at
 all: I generated Ninja build scripts using CMake and implemented
 custom targets to run "ant release" after all the C++ projects were
 built. I made sure that CMake copied relevant *.so files to
 appropriate directories in the Ant structure so they are packaged with
 built APKs. That's how I did my Android development.

 Now that I'm integrating CMake into Gradle, first annoyance I noticed
 is that I can't use CMake 3.7 (or any external installation of CMake)
 with Android Studio. It requires a version of CMake installed through
 SDK Manager. This means I can't use the new Android toolchain
 functionality built into CMake 3.7 (sad face). But this is something I
 can work around...

 Next I found out that stuff I'm setting in my CMake scripts, such as
 CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
 For whatever reason, Gradle is overriding these from the command line
 (I'm guessing?). So this requires me to duplicate the toolchain /
 compiler flag setup I already do in my CMake scripts now in the Gradle
 build scripts. This seems completely unnecessary and a maintenance
 burden.

 What I was expecting Gradle to do was essentially provide me some
 toolchain file so that CMake can find the compiler and linker to use
 and then the rest would be determined by CMake itself.

 Is there a way I can tell Gradle to not take so much control over
 compiler flags? I want my CMake scripts to do this. I can't imagine
 they had a good reason to do this. What have others done in this
 situation with their own Gradle + CMake integration? Looking for
 advice here, since information is sparse, especially since the Android
 Studio 2.2 CMake integration is relatively new stuff.
>>> --
>>>
>>> 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-developers

Re: [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

I'm sorry but that doesn't really answer my questions.

On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey  wrote:
> Try to update your Android SDK from android studio?
>
>
> 2016年10月31日 21:31，"Robert Dailey" 写道：
>
> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> talking about dev/beta builds?
>
> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
>> The latest release of android studio work with CMAKE well.
>>
>> you can create a new project with c++ support to test CMAKE support!
>>
>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>> to get the details.
>>
>> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
>>> I'm at a bit of a loss on finding more information. Can anyone at
>>> least confirm that this isn't a reliable place to find the answers I'm
>>> looking for? Does anyone have real experience with android + gradle +
>>> cmake integration and can provide some pointers?
>>>
>>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey 
>>> wrote:
 I'm not sure if the CMake mailing lists are the right place to ask
 this question but I thought I'd ask just in case someone has gone down
 this path or has experience with what Google/Gradle is actually trying
 to accomplish with what seems to be a hand-built version of CMake with
 custom patches that are not in upstream repositories.

 Prior to switching to Android Studio / Gradle, I was using Eclipse /
 Ant. The way I did CMake integration was not really integration at
 all: I generated Ninja build scripts using CMake and implemented
 custom targets to run "ant release" after all the C++ projects were
 built. I made sure that CMake copied relevant *.so files to
 appropriate directories in the Ant structure so they are packaged with
 built APKs. That's how I did my Android development.

 Now that I'm integrating CMake into Gradle, first annoyance I noticed
 is that I can't use CMake 3.7 (or any external installation of CMake)
 with Android Studio. It requires a version of CMake installed through
 SDK Manager. This means I can't use the new Android toolchain
 functionality built into CMake 3.7 (sad face). But this is something I
 can work around...

 Next I found out that stuff I'm setting in my CMake scripts, such as
 CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
 For whatever reason, Gradle is overriding these from the command line
 (I'm guessing?). So this requires me to duplicate the toolchain /
 compiler flag setup I already do in my CMake scripts now in the Gradle
 build scripts. This seems completely unnecessary and a maintenance
 burden.

 What I was expecting Gradle to do was essentially provide me some
 toolchain file so that CMake can find the compiler and linker to use
 and then the rest would be determined by CMake itself.

 Is there a way I can tell Gradle to not take so much control over
 compiler flags? I want my CMake scripts to do this. I can't imagine
 they had a good reason to do this. What have others done in this
 situation with their own Gradle + CMake integration? Looking for
 advice here, since information is sparse, especially since the Android
 Studio 2.2 CMake integration is relatively new stuff.
>>> --
>>>
>>> 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] CMake integration in Gradle (Android Studio)

[Cong Monkey]

Try to update your Android SDK from android studio?

2016年10月31日 21:31，"Robert Dailey" 写道：

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey 
wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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-developers] [CMake] CMake integration in Gradle (Android Studio)

[Cong Monkey]

Try to update your Android SDK from android studio?

2016年10月31日 21:31，"Robert Dailey" 写道：

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey 
wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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-developers

Re: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey  
>> wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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-developers

Re: [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey  wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey :
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey  
>> wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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] CMake 3.6 and OSX

[Gregor Jasny via CMake]

Hello Robert,

On 29/10/2016 22:03, Robert Ramey wrote:
> I've just "upgraded" to version 3.6 of CMake.  I'm using Xcode with the
> clang compiler.  Now when I'm trying to configure a project I'm getting:
> 
> The C compiler identification is unknown
> The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:14 (project):
>   No CMAKE_C_COMPILER could be found.
> CMake Error at CMakeLists.txt:14 (project):
>   No CMAKE_CXX_COMPILER could be found.
> 
> What do I have to do to make this work?

Have a look into /CMakeFiles/CMakeOutput.log and
CMakeError.log. There should be an error visible. Most often someone
forgets to accept the Xcode license. The resulting output leads to CMake
errors.

Thanks,
Gregor
-- 

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 integration in Gradle (Android Studio)

[Cong Monkey]

The latest release of android studio work with CMAKE well.

you can create a new project with c++ support to test CMAKE support!

You can follow https://code.google.com/p/android/issues/detail?id=212007
to get the details.

2016-10-28 5:48 GMT+08:00 Robert Dailey :
> I'm at a bit of a loss on finding more information. Can anyone at
> least confirm that this isn't a reliable place to find the answers I'm
> looking for? Does anyone have real experience with android + gradle +
> cmake integration and can provide some pointers?
>
> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey  
> wrote:
>> I'm not sure if the CMake mailing lists are the right place to ask
>> this question but I thought I'd ask just in case someone has gone down
>> this path or has experience with what Google/Gradle is actually trying
>> to accomplish with what seems to be a hand-built version of CMake with
>> custom patches that are not in upstream repositories.
>>
>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>> Ant. The way I did CMake integration was not really integration at
>> all: I generated Ninja build scripts using CMake and implemented
>> custom targets to run "ant release" after all the C++ projects were
>> built. I made sure that CMake copied relevant *.so files to
>> appropriate directories in the Ant structure so they are packaged with
>> built APKs. That's how I did my Android development.
>>
>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>> is that I can't use CMake 3.7 (or any external installation of CMake)
>> with Android Studio. It requires a version of CMake installed through
>> SDK Manager. This means I can't use the new Android toolchain
>> functionality built into CMake 3.7 (sad face). But this is something I
>> can work around...
>>
>> Next I found out that stuff I'm setting in my CMake scripts, such as
>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>> For whatever reason, Gradle is overriding these from the command line
>> (I'm guessing?). So this requires me to duplicate the toolchain /
>> compiler flag setup I already do in my CMake scripts now in the Gradle
>> build scripts. This seems completely unnecessary and a maintenance
>> burden.
>>
>> What I was expecting Gradle to do was essentially provide me some
>> toolchain file so that CMake can find the compiler and linker to use
>> and then the rest would be determined by CMake itself.
>>
>> Is there a way I can tell Gradle to not take so much control over
>> compiler flags? I want my CMake scripts to do this. I can't imagine
>> they had a good reason to do this. What have others done in this
>> situation with their own Gradle + CMake integration? Looking for
>> advice here, since information is sparse, especially since the Android
>> Studio 2.2 CMake integration is relatively new stuff.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake 3.6 and OSX

[Robert Ramey]

I've just "upgraded" to version 3.6 of CMake.  I'm using Xcode with the 
clang compiler.  Now when I'm trying to configure a project I'm getting:


The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:14 (project):
  No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:14 (project):
  No CMAKE_CXX_COMPILER could be found.

What do I have to do to make this work?

Robert Ramey

--

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 integration in Gradle (Android Studio)

[Robert Dailey]

I'm at a bit of a loss on finding more information. Can anyone at
least confirm that this isn't a reliable place to find the answers I'm
looking for? Does anyone have real experience with android + gradle +
cmake integration and can provide some pointers?

On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey  wrote:
> I'm not sure if the CMake mailing lists are the right place to ask
> this question but I thought I'd ask just in case someone has gone down
> this path or has experience with what Google/Gradle is actually trying
> to accomplish with what seems to be a hand-built version of CMake with
> custom patches that are not in upstream repositories.
>
> Prior to switching to Android Studio / Gradle, I was using Eclipse /
> Ant. The way I did CMake integration was not really integration at
> all: I generated Ninja build scripts using CMake and implemented
> custom targets to run "ant release" after all the C++ projects were
> built. I made sure that CMake copied relevant *.so files to
> appropriate directories in the Ant structure so they are packaged with
> built APKs. That's how I did my Android development.
>
> Now that I'm integrating CMake into Gradle, first annoyance I noticed
> is that I can't use CMake 3.7 (or any external installation of CMake)
> with Android Studio. It requires a version of CMake installed through
> SDK Manager. This means I can't use the new Android toolchain
> functionality built into CMake 3.7 (sad face). But this is something I
> can work around...
>
> Next I found out that stuff I'm setting in my CMake scripts, such as
> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
> For whatever reason, Gradle is overriding these from the command line
> (I'm guessing?). So this requires me to duplicate the toolchain /
> compiler flag setup I already do in my CMake scripts now in the Gradle
> build scripts. This seems completely unnecessary and a maintenance
> burden.
>
> What I was expecting Gradle to do was essentially provide me some
> toolchain file so that CMake can find the compiler and linker to use
> and then the rest would be determined by CMake itself.
>
> Is there a way I can tell Gradle to not take so much control over
> compiler flags? I want my CMake scripts to do this. I can't imagine
> they had a good reason to do this. What have others done in this
> situation with their own Gradle + CMake integration? Looking for
> advice here, since information is sparse, especially since the Android
> Studio 2.2 CMake integration is relatively new stuff.
-- 

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] iwyu and clang-tidy not working under mac os

[Roman Wüger]

Ok, I've got it.
If anyone is interested, here is my configuration:
find_program(iwyu_path NAMES include-what-you-use iwyu PATHS 
${CMAKE_SOURCE_DIR}/tools/include-what-you-use/${iwyu_os}/bin) if(NOT 
iwyu_path) message(STATUS "Program include-what-you-use: Not found") else() 
message(STATUS "Program include-what-you-use: Found") 
set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE ${iwyu_path}) endif() 
find_program(clang_tidy NAMES clang-tidy clang-tidy-3.8) if(NOT clang_tidy) 
message(STATUS "Program clang-tidy: Not found") else() message(STATUS "Program 
clang-tidy: Found") set(CMAKE_CXX_CLANG_TIDY 
"${clang_tidy};-checks=-*,clang-analyzer-*,-clang-analyzer-alpha*,performance-*,cppcoreguidelines-*,cert-*,modernize-*")
 endif() 

Regards
Roman

> Am 26.10.2016 um 11:50 schrieb Daniel Pfeifer :
> 
>> On Wed, Oct 26, 2016 at 11:27 AM, Roman Wüger  wrote:
>> Hello,
>> 
>> I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work as 
>> expected with CMake 3.6.2 under linux. Under Mac OS with the same sources 
>> and the same CMake version doesn't produce any output.
>> 
>> On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with clang-tidy 
>> installed from homebrew.
>> 
>> Any hints?
> 
> When you run "make VERBOSE=1" and look at what is executed, do you see any 
> "cmake --iwyu" invocations?
-- 

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 - ified libjpeg source code

[Boudewijn Rempt]

On Tue, 25 Oct 2016, Aaron Boxer wrote:

> Hello,
> 
> I am looking for a cmake-ified jpeg library to add to another cmake project.
> Any recommendations?

I get mine here:

https://phabricator.kde.org/diffusion/EMERGE/browse/master/portage/win32libs/jpeg/

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
-- 

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 - ified libjpeg source code

[Aaron Boxer]

Hello,

I am looking for a cmake-ified jpeg library to add to another cmake project.
Any recommendations?

Thanks,
Aaron
-- 

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 integration in Gradle (Android Studio)

[Robert Dailey]

I'm not sure if the CMake mailing lists are the right place to ask
this question but I thought I'd ask just in case someone has gone down
this path or has experience with what Google/Gradle is actually trying
to accomplish with what seems to be a hand-built version of CMake with
custom patches that are not in upstream repositories.

Prior to switching to Android Studio / Gradle, I was using Eclipse /
Ant. The way I did CMake integration was not really integration at
all: I generated Ninja build scripts using CMake and implemented
custom targets to run "ant release" after all the C++ projects were
built. I made sure that CMake copied relevant *.so files to
appropriate directories in the Ant structure so they are packaged with
built APKs. That's how I did my Android development.

Now that I'm integrating CMake into Gradle, first annoyance I noticed
is that I can't use CMake 3.7 (or any external installation of CMake)
with Android Studio. It requires a version of CMake installed through
SDK Manager. This means I can't use the new Android toolchain
functionality built into CMake 3.7 (sad face). But this is something I
can work around...

Next I found out that stuff I'm setting in my CMake scripts, such as
CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
For whatever reason, Gradle is overriding these from the command line
(I'm guessing?). So this requires me to duplicate the toolchain /
compiler flag setup I already do in my CMake scripts now in the Gradle
build scripts. This seems completely unnecessary and a maintenance
burden.

What I was expecting Gradle to do was essentially provide me some
toolchain file so that CMake can find the compiler and linker to use
and then the rest would be determined by CMake itself.

Is there a way I can tell Gradle to not take so much control over
compiler flags? I want my CMake scripts to do this. I can't imagine
they had a good reason to do this. What have others done in this
situation with their own Gradle + CMake integration? Looking for
advice here, since information is sparse, especially since the Android
Studio 2.2 CMake integration is relatively new stuff.
-- 

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 not using user configured lib for linking

[Wang Wei]

I am using cmake (3.5.0) to compile a C++ probject on Ubuntu 14.04, which
depends on Nvidia Cudnn. It seems that the cmake does not provide the
correct paths of cudnn to the linker although I have configured the paths.

File FindCUDNN.cmake:

FIND_PATH(CUDNN_INCLUDE_DIR NAME "cudnn.h" PATHS "$ENV{CMAKE_INCLUDE_PATH}")
FIND_LIBRARY(CUDNN_LIBRARIES NAME "libcudnn.so" PATHS
"$ENV{CMAKE_LIBRARY_PATH}")
INCLUDE(FindPackageHandleStandardArgs)
find_package_handle_standard_args(CUDNN DEFAULT_MSG CUDNN_INCLUDE_DIR
CUDNN_LIBRARIES)
MARK_AS_ADVANCED(CUDNN_INCLUDE_DIR CUDNN_LIBRARIES)

CMakeLists.txt:

FIND_PACKAGE(CUDNN REQUIRED)
LIST(APPEND LINKER_LIBS ${CUDNN_LIBRARIES})
...
ADD_LIBRARY(myobjects OBJECT ${mysources})
ADD_LIBRARY(mylib SHARED $ ${cuda_objs})
TARGET_LINK_LIBRARIES(mylib ${LINKER_LIBS})

CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH are exported to the paths of cudnn5
in my home folder. After cmake .., the paths in CmakeCache.txt are set to
cudnn5. However, the linker (and link.txt) uses -lcudnn without paths to
cudnn5. Consequently, it links the cudnn4 in the system folder, i.e.
/usr/local/cuda/lib64.

Note: If there is no cudnn4 in my system folder, everything is fine. The
link.txt file and the output of make VERBOSE=1 use the absolute paths of
cudnn 5 during linking.


Thanks.

Wei.
-- 

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 3.6.2 FindHDF5.cmake trouble finding parallel version

[Christophe Trophime]

Hi, 
I'm experiencing troubles with cmake 3.6.2 and FindHDF5.cmake module in 
Debian/Testing. 
I'm trying to build med-fichier and gmsh for instance. 



The main CMakeList.txt contains: 

find_package(HDF5 COMPONENTS C) 
MESSAGE("HDF5_C_INCLUDE_DIR=${HDF5_C_INCLUDE_DIR}") 
MESSAGE("HDF5_CXX_INCLUDE_DIR=${HDF5_CXX_INCLUDE_DIR}") 
MESSAGE("HDF5_INCLUDE_DIR=${HDF5_INCLUDE_DIR}") 
MESSAGE("HDF5_INCLUDE_DIRS=${HDF5_INCLUDE_DIRS}") 
MESSAGE("HDF5_LIBRARIES=${HDF5_LIBRARIES}") 
MESSAGE("HDF5_C_LIBRARIES=${HDF5_C_LIBRARIES}") 


For those two using something like cmake .. -DHDF5_PREFER_PARALLEL:BOOL=ON to 
force the use of the mpi version 
I end up with error like that: 



-- HDF5: Using hdf5 compiler wrapper to determine C configuration 
-- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS 
HDF5_HL_LIBRARIES) 
HDF5_C_INCLUDE_DIR=HDF5_C_INCLUDE_DIR-NOTFOUND 
HDF5_CXX_INCLUDE_DIR=HDF5_CXX_INCLUDE_DIR-NOTFOUND 
HDF5_INCLUDE_DIR= 
HDF5_INCLUDE_DIRS=HDF5_C_INCLUDE_DIR-NOTFOUND;HDF5_CXX_INCLUDE_DIR-NOTFOUND 
HDF5_LIBRARIES=/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;HDF5_hdf5_LIBRARY-NOTFOUND;HDF5_hdf5_cpp_LIBRARY-NOTFOUND;HDF5_hdf5_LIBRARY-NOTFOUND
 
HDF5_C_LIBRARIES=/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;HDF5_hdf5_LIBRARY-NOTFOUND
 
-- HDF5 not found 




whereas hdf5 is installed!! 


I also tried to see what happens in FindHDF5.cmake by printing some additionnal 
messages: 



-- HDF5: Using hdf5 compiler wrapper to determine C configuration 
HDF5_C_INCLUDE_DIRS = /usr/include/hdf5/openmpi;/usr/include/hdf5/openmpi 
HDF5_C_DEFINITIONS 
=-D_LARGEFILE64_SOURCE;-D_LARGEFILE_SOURCE;-D_FORTIFY_SOURCE=2;-D_LARGEFILE64_SOURCE;-D_LARGEFILE_SOURCE;-D_FORTIFY_SOURCE=2
 
HDF5_C_LIBRARY_DIRS = /usr/lib/x86_64-linux-gnu/hdf5/openmpi 
HDF5_C_LIBRARY_NAMES = hdf5;sz;z;dl;m 
HDF5_C_HL_LIBRARY_NAMES = hdf5_hl 
HDF5_C_HL_LIBRARIES = /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.so 
HDF5_C_IS_PARALLEL=TRUE 
HDF5_IS_PARALLEL=FALSE 
CMake Warning at /usr/share/cmake-3.6/Modules/FindHDF5.cmake:613 (message): 
HDF5 found for language C is parallel but previously found language is not 
parallel. 
Call Stack (most recent call first): 
CMakeLists.txt:853 (find_package) 




It seems to me that HDF5_IS_PARALLEL is never set before... 

Is there a proper new way to find hdf5 with cmake? 
What is the problem with my actual way of doing it? 

Thanks for any help 
Best 

Christophe TROPHIME 
Research Engineer 

CNRS - LNCMI 
25, rue des Martyrs 
BP 166 
38042 GRENOBLE Cedex 9 
FRANCE 

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01 
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr 

-- 

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 doesn't find QtCore

[Hendrik Sattler]

Hi,

what is your compiler?

HS


Am 18. Oktober 2016 02:07:35 MESZ, schrieb Spencer Parkin 
:
>Hi,
>
>I'm trying to install PySide.  With "pip install PySide", I get the
>warning...
>
>CMake Warning at c:/Program Files
>(x86)/Cmake/share/cmake-3.7/Modules/FindQt4.cmake:618 (message):
>C:/Qt/4.8.5/bin/qmake.exe reported QT_INSTALL_LIBS as "C:/Qt/4.8.5/lib"
>but
>QtCore could not be found there.  Qt is NOT installed correctly for the
>target build environment.
>
>...I, however, believe that Qt IS installed correctly.  I find
>QtCore4.lib
>in the said directory.  I tried to decipher the code found in
>FindQt4.cmake, but I don't know the cmake language.  "qmake -query
>QT_INSTALL_LIBS" does indeed report the directory named above, and it's
>full of Qt-licious libraries.
>
>Later on I see...
>
>Qt QTGUI library not found.
>Qt QTXML library not found.
>Qt QTCORE library not found.
>
>...and the ultimate wammy...
>
>CMake Error at ApiExtractor/CmakeLists.txt:82 (qt4_add_resources):
>Unknown
>CMake command "qt4_add_resources".
>
>So "shiboken" fails to configure.  But I'm hoping that the latter
>errors
>are just a symptom of the initial warning above indicating that, oddly,
>cmake can't locate my Qt libraries.
>
>I'm at a complete loss.  I've wasted an entire day here at work on this
>one
>issue.  Any help would be greatly appreciated.
>
>--Sp
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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 doesn't find QtCore

[Spencer Parkin]

Hi,

I'm trying to install PySide.  With "pip install PySide", I get the
warning...

CMake Warning at c:/Program Files
(x86)/Cmake/share/cmake-3.7/Modules/FindQt4.cmake:618 (message):
C:/Qt/4.8.5/bin/qmake.exe reported QT_INSTALL_LIBS as "C:/Qt/4.8.5/lib" but
QtCore could not be found there.  Qt is NOT installed correctly for the
target build environment.

...I, however, believe that Qt IS installed correctly.  I find QtCore4.lib
in the said directory.  I tried to decipher the code found in
FindQt4.cmake, but I don't know the cmake language.  "qmake -query
QT_INSTALL_LIBS" does indeed report the directory named above, and it's
full of Qt-licious libraries.

Later on I see...

Qt QTGUI library not found.
Qt QTXML library not found.
Qt QTCORE library not found.

...and the ultimate wammy...

CMake Error at ApiExtractor/CmakeLists.txt:82 (qt4_add_resources): Unknown
CMake command "qt4_add_resources".

So "shiboken" fails to configure.  But I'm hoping that the latter errors
are just a symptom of the initial warning above indicating that, oddly,
cmake can't locate my Qt libraries.

I'm at a complete loss.  I've wasted an entire day here at work on this one
issue.  Any help would be greatly appreciated.

--Sp
-- 

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 doesn't detect Microsoft Build Tools 2015 on Windows 10

[Gilles Khouzam via CMake]

Please open a bug, I can take a look at it.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Eduard Wirch
Sent: Monday, October 10, 2016 02:41
To: cmake@cmake.org
Subject: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

Hi

I've installed build tools from here: 
http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed 
here as well) instead.

Looking into the source:

const std::string vsregBase =
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
std::vector vsVerions;
vsVerions.push_back("VisualStudio\\");
vsVerions.push_back("VCExpress\\");
vsVerions.push_back("WDExpress\\");
struct VSRegistryEntryName
{
  const char* MSVersion;
  const char* GeneratorName;
};
VSRegistryEntryName version[] = {
  /* clang-format needs this comment to break after the opening brace */
  { "7.1", "Visual Studio 7 .NET 2003" },
  { "8.0", "Visual Studio 8 2005" },
  { "9.0", "Visual Studio 9 2008" },
  { "10.0", "Visual Studio 10 2010" },
  { "11.0", "Visual Studio 11 2012" },
  { "12.0", "Visual Studio 12 2013" },
  { "14.0", "Visual Studio 14 2015" },
  { "15.0", "Visual Studio 15" },
  { 0, 0 }
};
for (int i = 0; version[i].MSVersion != 0; i++) {
  for (size_t b = 0; b < vsVerions.size(); b++) {
std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
reg += ";InstallDir]";
cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
if (!(reg == "/registry")) {
  installedCompiler = version[i].GeneratorName;
  break;
}
  }
}

CMake will look for 
'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is 
not present indeed. When specified explicitly:
cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
"ProductDir"="C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\VC\\"


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
"InstallDir"="C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\"
"VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue 
tracker?

Cheers,
Eduard
-- 

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 doesn't detect Microsoft Build Tools 2015 on Windows 10

[Eduard Wirch]

Hi

I've installed build tools from here: 
http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed 
here as well) instead.

Looking into the source:

const std::string vsregBase =
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
std::vector vsVerions;
vsVerions.push_back("VisualStudio\\");
vsVerions.push_back("VCExpress\\");
vsVerions.push_back("WDExpress\\");
struct VSRegistryEntryName
{
  const char* MSVersion;
  const char* GeneratorName;
};
VSRegistryEntryName version[] = {
  /* clang-format needs this comment to break after the opening brace */
  { "7.1", "Visual Studio 7 .NET 2003" },
  { "8.0", "Visual Studio 8 2005" },
  { "9.0", "Visual Studio 9 2008" },
  { "10.0", "Visual Studio 10 2010" },
  { "11.0", "Visual Studio 11 2012" },
  { "12.0", "Visual Studio 12 2013" },
  { "14.0", "Visual Studio 14 2015" },
  { "15.0", "Visual Studio 15" },
  { 0, 0 }
};
for (int i = 0; version[i].MSVersion != 0; i++) {
  for (size_t b = 0; b < vsVerions.size(); b++) {
std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
reg += ";InstallDir]";
cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
if (!(reg == "/registry")) {
  installedCompiler = version[i].GeneratorName;
  break;
}
  }
}

CMake will look for 
'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is 
not present indeed. When specified explicitly:
cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
"ProductDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\"


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
"InstallDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\"
"VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue 
tracker?

Cheers,
Eduard
-- 

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] Problems with icons for Windows Store 10.0

[Gilles Khouzam via CMake]

Hi Roman,

Glad to hear that it works.

We discussed this when I implemented the feature, the only reason the 
functionality has been implemented is to supplement the intermediate projects 
that CMake produces that cannot easily be adapted for the requirements of a 
Windows Store application.

For a user's project, the AppXManifest is a critical piece that describes the 
application. There are some fields that need to be appropriately set (publisher 
Id, application name and version), even the icons need to be properly specified 
unless you use the exact same name for the files and don't look at having 
different tile sizes.

For prototyping this might seem like an unnecessary step, but once you start 
customizing the parts of the application, it seems counter intuitive to have 
customizations only apply under certain conditions. Perhaps a better solution 
would be to give an error message if any of the defaults are replaced but a 
manifest is not specified.

-Original Message-
From: Roman Wüger [mailto:roman.wue...@gmx.at] 
Sent: Wednesday, October 5, 2016 22:39
To: Gilles Khouzam 
Cc: Brad King ; CMake Developer MailingList 
; CMake MailingList 
Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0

Thanks Gilles,

I added a custom appxmanifest as you mentioned and it works, but it would 
nevertheless very helpful to customize such things via variables and let CMake 
fill out the rest.

Regards
Roman

> Am 05.10.2016 um 21:19 schrieb Gilles Khouzam :
> 
> That's most likely because you're missing an AppxManifest.
> 
> In order to build the CMake detection projects, we inject some necessary 
> files into the project when they aren't specified. This includes the manifest 
> and the icons. Can you add your app manifest to the project (look at 
> Tests\VSWinStorePhone if you want an example) and the icons should not be 
> overridden then.
> 
> Thanks
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Wednesday, October 5, 2016 12:09
> To: Roman Wüger ; Gilles Khouzam 
> 
> Cc: CMake Developer MailingList ; CMake 
> MailingList 
> Subject: Re: [cmake-developers] Problems with icons for Windows Store 
> 10.0
> 
>> On 10/05/2016 02:56 PM, Roman Wüger wrote:
>> I tried the following to copy the required app icons to the required 
>> destination:
>> 
>> configure_file(Logo.png
>> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
> 
> That's a CMake-private directory whose location is an implementation detail.
> Some other interface for configuring this behavior will be needed.
> 
>> The CMake process itself overrides those files at the end with the 
>> files from the CMake's Template directory, which are empty.
> 
> From the current implementation it doesn't look like there is anyway to 
> prevent that.  We'll need to have some configuration of where it gets those 
> files.
> 
>> So, how could I use my icon files and/or what is the preferred way of doing 
>> this?
> 
> Gilles?
> 
> -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

Re: [CMake] [cmake-developers] Problems with icons for Windows Store 10.0

[Roman Wüger]

Thanks Gilles,

I added a custom appxmanifest as you mentioned and it works, but it would 
nevertheless very helpful to customize such things via variables and let CMake 
fill out the rest.

Regards
Roman

> Am 05.10.2016 um 21:19 schrieb Gilles Khouzam :
> 
> That's most likely because you're missing an AppxManifest.
> 
> In order to build the CMake detection projects, we inject some necessary 
> files into the project when they aren't specified. This includes the manifest 
> and the icons. Can you add your app manifest to the project (look at 
> Tests\VSWinStorePhone if you want an example) and the icons should not be 
> overridden then.
> 
> Thanks
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com] 
> Sent: Wednesday, October 5, 2016 12:09
> To: Roman Wüger ; Gilles Khouzam 
> 
> Cc: CMake Developer MailingList ; CMake 
> MailingList 
> Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0
> 
>> On 10/05/2016 02:56 PM, Roman Wüger wrote:
>> I tried the following to copy the required app icons to the required 
>> destination:
>> 
>> configure_file(Logo.png 
>> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
> 
> That's a CMake-private directory whose location is an implementation detail.
> Some other interface for configuring this behavior will be needed.
> 
>> The CMake process itself overrides those files at the end with the 
>> files from the CMake's Template directory, which are empty.
> 
> From the current implementation it doesn't look like there is anyway to 
> prevent that.  We'll need to have some configuration of where it gets those 
> files.
> 
>> So, how could I use my icon files and/or what is the preferred way of doing 
>> this?
> 
> Gilles?
> 
> -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

Re: [CMake] [cmake-developers] Problems with icons for Windows Store 10.0

[Gilles Khouzam via CMake]

That's most likely because you're missing an AppxManifest.

In order to build the CMake detection projects, we inject some necessary files 
into the project when they aren't specified. This includes the manifest and the 
icons. Can you add your app manifest to the project (look at 
Tests\VSWinStorePhone if you want an example) and the icons should not be 
overridden then.

Thanks

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, October 5, 2016 12:09
To: Roman Wüger ; Gilles Khouzam 

Cc: CMake Developer MailingList ; CMake MailingList 

Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0

On 10/05/2016 02:56 PM, Roman Wüger wrote:
> I tried the following to copy the required app icons to the required 
> destination:
> 
> configure_file(Logo.png 
> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

That's a CMake-private directory whose location is an implementation detail.
Some other interface for configuring this behavior will be needed.

> The CMake process itself overrides those files at the end with the 
> files from the CMake's Template directory, which are empty.

>From the current implementation it doesn't look like there is anyway to 
>prevent that.  We'll need to have some configuration of where it gets those 
>files.

> So, how could I use my icon files and/or what is the preferred way of doing 
> this?

Gilles?

-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

Re: [CMake] [cmake-developers] Problems with icons for Windows Store 10.0

[Brad King]

On 10/05/2016 02:56 PM, Roman Wüger wrote:
> I tried the following to copy the required app icons to the required 
> destination:
> 
> configure_file(Logo.png 
> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

That's a CMake-private directory whose location is an implementation detail.
Some other interface for configuring this behavior will be needed.

> The CMake process itself overrides those files at the end with the files from 
> the
> CMake's Template directory, which are empty.

>From the current implementation it doesn't look like there is anyway to prevent
that.  We'll need to have some configuration of where it gets those files.

> So, how could I use my icon files and/or what is the preferred way of doing 
> this?

Gilles?

-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

[CMake] cmake install multiple artifacts

[Tom Gwozdz]

Hello,

I'm using CMake to cross compile some code using Emscripten.  Emscripten
generates html/javascript files from c++ input files.  In my case, my
generated binary output is an html file that loads in a javascript file.
Both files are generated from the final link step.

When I do the following:

install(TARGETS target
EXPORT export
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib
RUNTIME DESTINATION bin
)

The bin directory contains the html file, but not the js file.  Is there
some way of telling CMake that the final link step actually generated
multiple files, and that all of them should be installed to the final bin
directory?

Thanks!
Tom
-- 

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] CPack [WiX] Customizations of individual features/components

[Nils Gladitz]

On 09/30/2016 08:43 AM, Roman Wüger wrote:


Hello,

I want to customize some with CPack  generated *.wxs files.

For example: directories.wxs is generated with only the TARGET_DIR.


TARGETDIR (no underscore) is always the one and only root-directory 
element [1].



How can I add an additional directory in this file and use the newly added 
directory in the components (features.wxs)?

I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it, but 
if so how?


CPACK_WIX_PATCH_FILE can be used to add XML content to (some) existing elements.
It can not be used to reorder or remove existing elements and can not be used 
to modify the attributes of existing elements.


Nils


[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372064(v=vs.85).aspx

--

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] CPack [WiX] Customizations of individual features/components

[Stuermer, Michael SP/HZA-ZSEP]

Hello Roman,

directories are added automatically to the directories.wxs file if you use the 
install() command in cmake and set the DESTINATION to some subfolder:

install(FILES 
DESTINATION "my/sufolder/path")

To add completely new directories I'd suggest to use CPACK_WIX_EXTRA_SOURCES 
and use a  element where you can place your new directories in. 
Untested example how to add a directory (not sure if it works exactly like 
this):


http://schemas.microsoft.com/wix/2006/wi;>
  
   
  
  
  


I'm not sure if patching of  elements is possible/implemented in 
cpack and I believe using the extra sources mechanism is more convenient.

PS: if you want to use the CPACK_WIX_PATCH_FILE nevertheless and you have many 
framents to patch, CPACK_WIX_PATCH_FILE also accepts a list of filenames so you 
can split up your patches in an arbitrary number of files.

best regards,
Michael

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Roman Wüger
> Sent: Friday, September 30, 2016 8:44 AM
> To: CMake Developer MailingList; CMake MailingList
> Subject: [cmake-developers] CPack [WiX] Customizations of individual
> features/components
> 
> Hello,
> 
> I want to customize some with CPack  generated *.wxs files.
> 
> For example: directories.wxs is generated with only the TARGET_DIR.
> 
> How can I add an additional directory in this file and use the newly added
> directory in the components (features.wxs)?
> 
> I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it,
> but if so how?
> 
> Thanks in advance
> 
> Regards
> Roman
> --
> 
> 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] [cmake-developers] CPack [NSIS] Install directory per component

[Roman Wüger]

Hello,I've attached a patch with which it is now possible to set custom install directories per component.

0001-CPack-NSIS-custom-component-install-directory.patch
Description: Binary data
Best RegardsRomanAm 21.09.2016 um 23:04 schrieb Roman Wüger :Hello,Per default the install directory for acomponent is $INSTDIR.Is there a chance to change the install dir per component?ThanksRoman-- Powered by www.kitware.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlFollow 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] cmake source tree pollution ?

[Vania Joloboff]

It seems to be the cause.
Thanks

Vania
On 09/12/2016 09:42 AM, Magnus Therning wrote:

Bruce Stephens  writes:


Looks like https://github.com/redguardtoo/cpputils-cmake might be involved...

If that is the case then this section could be of interest:

https://github.com/redguardtoo/cpputils-cmake#stop-creating-makefiles-for-flymake

/M



--

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 source tree pollution ?

[Magnus Therning]

Bruce Stephens  writes:

> Looks like https://github.com/redguardtoo/cpputils-cmake might be involved...

If that is the case then this section could be of interest:

https://github.com/redguardtoo/cpputils-cmake#stop-creating-makefiles-for-flymake

/M

-- 
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

The man who is denied the opportunity of taking decisions of
importance begins to regard as important the decisions he is allowed
to take.
 — C Northcote Parkinson


signature.asc
Description: PGP signature
-- 

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 source tree pollution ?

[Bruce Stephens]

Looks like https://github.com/redguardtoo/cpputils-cmake might be involved...

On Fri, Sep 9, 2016 at 5:04 PM, Vania Joloboff  wrote:
> On 09/09/2016 05:45 PM, Michael Ellery wrote:
>>
>> This kinda’ sounds like you are doing an in-source build. Are you certain
>> that your currrent/working directory is different from your source tree root
>> when you run cmake? The typical way of doing this is just to make a
>> subdirectory of your source root:
>>
>> mkdir my_build
>> cd my_build
>> cmake ..
>> make
>>
> Yes this is what I do. And indeed there is a  big Makefile with 730 lines
>  created in my build directory, that builds the software.
> The source directories get polluted only with the 5 lines Makefiles attached
> in my previous mail.
> It seems only one thing related to cpp-utils is writing where it should not.
> All binaries are built in my build directory.
>  I do have a full hierarchy of CMakefiles directories that contain what they
> should contain.
> The top level build/CMakefiles directory does contain the CMakeOutput.log
> file
> but I can't make sense of what is wrong at which point.
> It contains also a fille CMakeFiles/TargetDirectories.txt with the right
> directories
> I list below the first 5 lines. They are correct and you can see there is a
> build directory
> The source is in trunk
>
> /home/vjf/workspace/merging/simsoc/trunk/build/libsimsoc/tools/debugger/CMakeFiles/debugger.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/examples/SerialISS/CMakeFiles/build_serial_iss.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/utils/ISC/CMakeFiles/isc.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/examples/TI_AM1707/CMakeFiles/ti-am1707.dir
> /home/vjf/workspace/merging/simsoc/trunk/build/examples/SPEAr/CMakeFiles/spear.dir
>
>
> The source directory (trunk) remains entirely clean,
> except for these strange 5 lines Makefiles.
>
> Vania
>
>
>>> On Sep 9, 2016, at 8:17 AM, Vania Joloboff 
>>> wrote:
>>>
>>> Hi,
>>>
>>> I have started to use CMake for my software.
>>> I build in a separate directory using :
>>> $> cmake -G "Unix Makefiles"  
>>>
>>> Everything is built correctly and the software works fine.
>>> However all of my source code directories get polluted.
>>> Into each source directory, a new Makefile is created.
>>> All of these Makefiles are identical. They are
>>>
>>> -
>>> # Generated by cpputils-cmake.
>>> include /flags.make
>>> .PHONY: check-syntax
>>> check-syntax:
>>> ${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include
>>> -DNDEBUG -S ${CHK_SOURCES}
>>> 
>>>
>>> Any clue ??
>>>
>>> Vania
>>>
>>> --
>>>
>>> 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
-- 

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 source tree pollution ?

[Vania Joloboff]

On 09/09/2016 05:45 PM, Michael Ellery wrote:

This kinda’ sounds like you are doing an in-source build. Are you certain that 
your currrent/working directory is different from your source tree root when 
you run cmake? The typical way of doing this is just to make a subdirectory of 
your source root:

mkdir my_build
cd my_build
cmake ..
make


Yes this is what I do. And indeed there is a  big Makefile with 730 lines
 created in my build directory, that builds the software.
The source directories get polluted only with the 5 lines Makefiles 
attached in my previous mail.

It seems only one thing related to cpp-utils is writing where it should not.
All binaries are built in my build directory.
 I do have a full hierarchy of CMakefiles directories that contain what 
they should contain.
The top level build/CMakefiles directory does contain the 
CMakeOutput.log file

but I can't make sense of what is wrong at which point.
It contains also a fille CMakeFiles/TargetDirectories.txt with the right 
directories
I list below the first 5 lines. They are correct and you can see there 
is a build directory

The source is in trunk

/home/vjf/workspace/merging/simsoc/trunk/build/libsimsoc/tools/debugger/CMakeFiles/debugger.dir
/home/vjf/workspace/merging/simsoc/trunk/build/examples/SerialISS/CMakeFiles/build_serial_iss.dir
/home/vjf/workspace/merging/simsoc/trunk/build/utils/ISC/CMakeFiles/isc.dir
/home/vjf/workspace/merging/simsoc/trunk/build/examples/TI_AM1707/CMakeFiles/ti-am1707.dir
/home/vjf/workspace/merging/simsoc/trunk/build/examples/SPEAr/CMakeFiles/spear.dir


The source directory (trunk) remains entirely clean,
except for these strange 5 lines Makefiles.

Vania


On Sep 9, 2016, at 8:17 AM, Vania Joloboff  wrote:

Hi,

I have started to use CMake for my software.
I build in a separate directory using :
$> cmake -G "Unix Makefiles"  

Everything is built correctly and the software works fine.
However all of my source code directories get polluted.
Into each source directory, a new Makefile is created.
All of these Makefiles are identical. They are

-
# Generated by cpputils-cmake.
include /flags.make
.PHONY: check-syntax
check-syntax:
${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include 
-DNDEBUG -S ${CHK_SOURCES}


Any clue ??

Vania

--

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] cmake source tree pollution ?

[Bruce Stephens]

On Fri, Sep 9, 2016 at 4:45 PM, Michael Ellery  wrote:
> This kinda’ sounds like you are doing an in-source build. Are you certain 
> that your currrent/working directory is different from your source tree root 
> when you run cmake? The typical way of doing this is just to make a 
> subdirectory of your source root:

Not to me. Looks like something (called cpputils, probably) is
deliberately adding
these Makefiles to the source tree. The check-syntax rule is something used by
flymake-mode in Emacs (possibly other things, but that's the one I know of).

[...]

>> On Sep 9, 2016, at 8:17 AM, Vania Joloboff  wrote:
>>
>> Hi,
>>
>> I have started to use CMake for my software.
>> I build in a separate directory using :
>> $> cmake -G "Unix Makefiles"  
>>
>> Everything is built correctly and the software works fine.
>> However all of my source code directories get polluted.
>> Into each source directory, a new Makefile is created.
>> All of these Makefiles are identical. They are
>>
>> -
>> # Generated by cpputils-cmake.
>> include /flags.make
>> .PHONY: check-syntax
>> check-syntax:
>>${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include 
>> -DNDEBUG -S ${CHK_SOURCES}
>> 
>>
>> Any clue ??
>>
>> Vania
>>
>> --
>>
>> 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
-- 

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 source tree pollution ?

[Michael Ellery]

This kinda’ sounds like you are doing an in-source build. Are you certain that 
your currrent/working directory is different from your source tree root when 
you run cmake? The typical way of doing this is just to make a subdirectory of 
your source root:

   mkdir my_build
   cd my_build
   cmake ..
   make


> On Sep 9, 2016, at 8:17 AM, Vania Joloboff  wrote:
> 
> Hi,
> 
> I have started to use CMake for my software.
> I build in a separate directory using :
> $> cmake -G "Unix Makefiles"  
> 
> Everything is built correctly and the software works fine.
> However all of my source code directories get polluted.
> Into each source directory, a new Makefile is created.
> All of these Makefiles are identical. They are
> 
> -
> # Generated by cpputils-cmake.
> include /flags.make
> .PHONY: check-syntax
> check-syntax:
>${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include 
> -DNDEBUG -S ${CHK_SOURCES}
> 
> 
> Any clue ??
> 
> Vania
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] cmake source tree pollution ?

[Vania Joloboff]

Hi,

I have started to use CMake for my software.
I build in a separate directory using :
$> cmake -G "Unix Makefiles"  

Everything is built correctly and the software works fine.
However all of my source code directories get polluted.
Into each source directory, a new Makefile is created.
All of these Makefiles are identical. They are

-
# Generated by cpputils-cmake.
include /flags.make
.PHONY: check-syntax
check-syntax:
${CC} -o /dev/null ${C_FLAGS} ${C_DEFINES} -I/usr/src/linux/include 
-DNDEBUG -S ${CHK_SOURCES}



Any clue ??

Vania

--

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 library installations and pkg-config

[Konstantin Tokarev]

01.09.2016, 08:34, "n...@appletonaudio.com" :
> On 2016-08-31 23:32, Konstantin Tokarev wrote:
>>  31.08.2016, 16:22, "Nick Appleton" :
>>>  Hi,
>>>
>>>  I’ve been recently doing a bit of work for an open source project
>>>  trying to extend it’s support for CMake. I’ve been trying to get CMake
>>>  to be able to replicate most of the functionality which can be
>>>  achieved with the existing autoconf-based infrastructure (and have had
>>>  pretty good success) but am struggling to figure out how to get CMake
>>>  to generate pkg-config files on unix-ey systems. I’ve done quite a lot
>>>  of searching, but have not found anything which provides a good
>>>  solution for our use case.
>>
>>  Do you consider contributing to
>>  https://api.kde.org/ecm/module/ECMGeneratePkgConfigFile.html ?
>
> Hi Konstantin,
>
> Thanks for the reply and pointing me at the ECM repository.
>
> I was hoping that this would be something that CMake would be able to do
> without requiring an external package - particularly since CMake
> provides support for finding packages on the system with pkg-config
> files. I think adding documentation to our project which says "if you
> want to install portaudio into the host system in a way compatible with
> autotools-based projects, you will need to get this other repository"
> seems a little bit much to me.

It's a usual practice to copy ECM modules into your project, they mostly don't 
depend on each other. For example, ECMGeneratePkgConfigFile is completely 
stand-alone.

>
> Cheers,
>
> Nick

-- 
Regards,
Konstantin
-- 

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 library installations and pkg-config

[nick]

On 2016-08-31 23:32, Konstantin Tokarev wrote:

31.08.2016, 16:22, "Nick Appleton" :

Hi,

I’ve been recently doing a bit of work for an open source project 
trying to extend it’s support for CMake. I’ve been trying to get CMake 
to be able to replicate most of the functionality which can be 
achieved with the existing autoconf-based infrastructure (and have had 
pretty good success) but am struggling to figure out how to get CMake 
to generate pkg-config files on unix-ey systems. I’ve done quite a lot 
of searching, but have not found anything which provides a good 
solution for our use case.


Do you consider contributing to
https://api.kde.org/ecm/module/ECMGeneratePkgConfigFile.html ?



Hi Konstantin,

Thanks for the reply and pointing me at the ECM repository.

I was hoping that this would be something that CMake would be able to do 
without requiring an external package - particularly since CMake 
provides support for finding packages on the system with pkg-config 
files. I think adding documentation to our project which says "if you 
want to install portaudio into the host system in a way compatible with 
autotools-based projects, you will need to get this other repository" 
seems a little bit much to me.


Cheers,

Nick
--

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 library installations and pkg-config

[Konstantin Tokarev]

31.08.2016, 16:22, "Nick Appleton" :
> Hi,
>
> I’ve been recently doing a bit of work for an open source project trying to 
> extend it’s support for CMake. I’ve been trying to get CMake to be able to 
> replicate most of the functionality which can be achieved with the existing 
> autoconf-based infrastructure (and have had pretty good success) but am 
> struggling to figure out how to get CMake to generate pkg-config files on 
> unix-ey systems. I’ve done quite a lot of searching, but have not found 
> anything which provides a good solution for our use case.

Do you consider contributing to 
https://api.kde.org/ecm/module/ECMGeneratePkgConfigFile.html ?

>
> The project is called portaudio (a cross-platform, C, real-time audio 
> library) and at present there is one CMakeLists.txt file which does 
> everything (I’ve tried to keep it clean), you can see it here: 
> https://app.assembla.com/spaces/portaudio/git/source/cmake_updates/CMakeLists.txt
>
> It looks for various audio libraries which may be present on the system using 
> find_package() and associates them with the library which it defines using 
> target_link_libraries(). This is all great when my CMake project includes 
> portaudio (via add_subdirectory() and target_link_libraries() with one of the 
> portaudio library targets), but if I want “make install”-like functionality 
> so that others can use a portaudio installation without requiring CMake, I 
> would like to be able to generate a pkg-config file which contains the 
> necessary linker arguments to pass when linking against the library. The 
> generation of the pkg-config file is straight-forward using the 
> configure_file() function, but I am struggling to find a way to: given a 
> CMake target, create a variable containing the set of linker paths and 
> library names to use in the pkg-config file.
>
> Can anyone give me some hints as to whether this is possible?
>
> Cheers,
>
> Nick
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 
Regards,
Konstantin
-- 

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 library installations and pkg-config

[Nick Appleton]

Hi,

I’ve been recently doing a bit of work for an open source project trying to 
extend it’s support for CMake. I’ve been trying to get CMake to be able to 
replicate most of the functionality which can be achieved with the existing 
autoconf-based infrastructure (and have had pretty good success) but am 
struggling to figure out how to get CMake to generate pkg-config files on 
unix-ey systems. I’ve done quite a lot of searching, but have not found 
anything which provides a good solution for our use case.

The project is called portaudio (a cross-platform, C, real-time audio library) 
and at present there is one CMakeLists.txt file which does everything (I’ve 
tried to keep it clean), you can see it here: 
https://app.assembla.com/spaces/portaudio/git/source/cmake_updates/CMakeLists.txt

It looks for various audio libraries which may be present on the system using 
find_package() and associates them with the library which it defines using 
target_link_libraries(). This is all great when my CMake project includes 
portaudio (via add_subdirectory() and target_link_libraries() with one of the 
portaudio library targets), but if I want “make install”-like functionality so 
that others can use a portaudio installation without requiring CMake, I would 
like to be able to generate a pkg-config file which contains the necessary 
linker arguments to pass when linking against the library. The generation of 
the pkg-config file is straight-forward using the configure_file() function, 
but I am struggling to find a way to: given a CMake target, create a variable 
containing the set of linker paths and library names to use in the pkg-config 
file.

Can anyone give me some hints as to whether this is possible?

Cheers,

Nick

-- 

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/CTest no RUN_TESTS target

[tonka tonka]

Hey,

I’ve try to get ctest running with my existing gtest-tests. I have my own
findGTest, but should make no difference.

My Problem is that I can’t see the RUN_TESTS target (I’m using Visual
Studio).

I follow the following tutorialhttps://
cmake.org/Wiki/CMake/Testing_With_CTest

I’m start using enable_testing()

I create my executable in my target-CMakeLists.txt file and add the test to
CTest via add_test(MyTestName ThePathToMyExe)

CMake should now create a RUN_TESTS target for me, but it does not happen.

I’ve I use include(CTest) at the end I get many new targets f.e.
continuous, nightly, etc. but no RUN_TESTS

What I’m doing wrong?

I use CMake 3.4.3

Greetings
Tonka
-- 

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

[Ruslan Baratov via CMake]

On 17-Aug-16 04:29, Florent Castelli wrote:


The Boost source download is cached outside of the build directory 
in a unique folder.

So it’s effectively only done once for all platforms and then reused.
This is true for local machines and for custom build servers like 
your personal Jenkins. For Travis/AppVeyor you have to create root 
folder with 3rd parties from scratch for each build (at least for 
free public accounts).
Yes. If you're using a free shared service, that's not something you 
can count on.
If you host your CI, you can do neat tricks like this, use ccache or 
other similar techs.

What if you don't need "tricks" and make everything plain and simple?







You’ll also have symbols and the sources available for debugging 
properly, and they’re

not always available with a binary distribution.
Just to clarify: with Hunter you're creating binaries from sources, 
so everything you install with `cmake --build _builds --target 
install` (or `./b2 install` for Boost) is available.
So you build each dependency separately, install them, and then use 
them in your top level dependency.

No, in shared root folder.

That works, but you have the extra overhead of the instrumentation for 
the whole build.
Even a no-op build will have to recurse in the build folder for each 
dependency and run again, which is slow.
This is why I prefer Ninja to the Makefile generator: it has a global 
view of everything and you get a quick no-op build.

Not sure I understand that. What is the overhead?








Of course building from source is not an option for such monsters 
like Qt or OpenCV. Ready-to-use binaries is something critical for 
real life applications. There is no way to test everything on 
Travis/AppVeyor without this feature.


Well, you don’t have to use Travis or AppVeyor.
It's the most powerful and easy to setup services I know. If you know 
any better solutions please share.
Well, you don't have a full control on the environment, so I wouldn't 
say it's the most powerful.
Please share your solution. I have worked with Jenkins before and will 
not say that it's something easy customizable. Shareable folder - yes, 
good, but other stuff is a complete pain.
You can setup Travis in a seconds, add AppVeyor and you got Linux, OSX, 
Windows testing. How much time will take to start and tune Jenkins 
master and connect several slaves with different OSes on them?
Then add bunch of projects and tune them, then create dev branches for 
testing and so on.



Convenient for sure. It probably fits smaller structures very well.
Bigger companies have the resources to host their own service most of 
the time and requirements that
force them to do so. Those are probably the ones that will have the 
manpower to handle a super-build type

build system.
Why do not have both? Hunter can share downloads/root/cache on local 
folder for such CIs like Jenkins/custom so you don't need to rebuild 
everything.
At the same time binaries from server can be downloaded for 
"build-from-scratch" environment like Travis.


Anyway what about users? So you think it's okay to spend several hours 
of building from sources to just to run simple example of your product?







Spotify isn’t at the same scale as most
projects hosted there and we have different requirements and resources.
Admittedly, Spotify doesn’t use Qt anymore, so this isn’t a problem 
for us.
It's not about Qt, it's about expandability. Use 20 of smaller 
libraries and you will have quite the same issues.
As I said before, if I have build scripts for 20 small libraries and I 
want to update a build flag affecting the ABI, I don't have to do 
anything but just change the flag once.
In your case, you'll have to tweak the 20 build scripts for each 
library to reflect it.
The dependencies are only intermediate products you use for the final 
one. I don't want to deal with them constantly.
It's not true, I don't need to tweak 20 scripts, I just need to tweak 
one toolchain file.








Note that by integrating everything in the same project, you also 
have proper dependencies
and you will only build what you need. You may save some time by 
doing that.

And caching is important, when done in the right way!
With Hunter you're installing only what you need too, it does respect 
options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only 
binaries for toolchain you're currently working on, etc.


Don't want to make a discussion too broad. You said that it's hard to 
manage binaries for a lot of configuration, I'm saying that it's 
possible and is very handy.
I'm not saying it's impossible. I'm saying the overhead of managing 
binaries is just a burden we shouldn't have to accept in the C/C++ world.
If you can build build everything from source all the time in a 
super-build, why wouldn't you do it?
Because it's not practical. I have such experience with Gentoo, I prefer 
do something useful instead of watching on "emerge world" progress. 
Super-build doesn't scale, what if 

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

[Ruslan Baratov via CMake]

On 17-Aug-16 08:36, Elizabeth A. Fischer wrote:

> > I don't think CMake is the best place to do it,
> Can you provide any details? I personally think that CMake is a
> natural and the only place where it should be done.

The most important reason here is because there are combinatorially
many versions of a package you COULD install, depending on what
versions of its dependencies you link with, and CMake provides nothing
to address that issue.

CMake provides an abstraction. "Slots" that you need to fill:

  if(FOO_WITH_TESTS)
# need to have GTest installed
find_package(GTest)
  endif()
  if(FOO_WITH_OPENSSL)
# need to have OpenSSL installed
find_package(OpenSSL)
  endif()

And it should drive package manager. At least I find that approach 
natural and convenient, see no problems with it.
You can have as much combinations of versions/options/dependencies as 
you need:

* https://docs.hunter.sh/en/latest/overview/customization/hunter-id.html
* https://docs.hunter.sh/en/latest/overview/customization/config-id.html


  See here for an overview of how Spack
addresses the combinatorial versioning issue (which no other
auto-builder does, to the best of my knowledge):

http://hpcugent.github.io/easybuild/files/SC14_BoF_Spack.pdf
That's what I was talking about. I think that there is no need to 
introduce new funky syntax like "spack install mpileaks@1.1.2 %gcc@4.7.3 
+debug".
We already have CMAKE_CXX_COMPILER and 
CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPES. Version can be set by CMake 
options too.

Effectively you can do:

  option(FOO_STABLE_BUILD "Stable build" ON)
  option(FOO_EXPERIMENTAL_BUILD "Experimental build" OFF)

  if(APPLE AND IOS AND FOO_STABLE_BUILD)
hunter_config(BooPackage VERSION "1.0")
  endif()

  if(WIN32 AND FOO_EXPERIMENTAL_BUILD)
hunter_config(BooPackage VERSION "2.0-beta" CMAKE_ARGS 
BOO_NEW_STUFF=YES)

  endif()



Once you've built something, it's nice to be able to re-use it.  If I
have a top-level CMake project that automatically builds three
dependencies, will other projects be able to make use of those
dependencies I've built?

Yes, libraries should be installed to the shared root, not to local folder:
* https://docs.hunter.sh/en/latest/overview/shareable.html


  Or do they become private?
No. Though you can make it private by setting CMake variable. It will 
use separate directory just like virtualenv do.



  If libraries
cannot be shared between applications, you will get a LOT of library
bloat, especially among the low-level libraries that get repeated
numerous times.  Admittedly, this may not be such an issue in some
environments where people are really only focused on building one
thing.

If you make a project, you might see it as a "top-level" project.  But 
someone else might want to build something bigger on top of your 
work.  You can never assume that "this package is top-level and no one 
will ever depend on it."

No issue here, see notes above.



Another obvious problem with using CMake for everything is that not
all packages come with CMake builds; most do not, in fact. Even if we
CAN re-write all the buils into CMake, that is a lot of extra effort.
As Florent has discovered, upstream authors do not always see a CMake
build in a favorable light, and these re-worked builds are not always
as functional as the original.  Moreover... writing a Spack recipe is 
an order of magnitude easier than writing a CMake build.  Usually, 
it's just a matter of calling `configure` or `cmake` with the right 
options.
Again, converting to CMake is a best option, but not the only possible 
one. E.g. OpenSSL, Boost, autotool-based package like X11 can be used as is:
* 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/Boost/hunter.cmake#L21
* 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/OpenSSL/hunter.cmake#L17
* 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/x11/hunter.cmake#L20




Although we can maybe imagine a world in which everyone eventually
abandons Autotools for CMake, it is still not realistic to expect that
Python, Haskell or Java programs will ever come with CMake builds.
This would be OK if each language exited in its own silo. But they
don't.  Python packages (built with setuptools) routinely depend on
C-based packages (built with Autotools or CMake).  By being agnostic
to the build system, auto-builders (like Spack, Macports, HomeBrew,
etc) are able to make packages work together, regardless of the build
system chosen for each one.

That's exactly what Hunter do, but using CMake as a driver.



In the sense that CMake is a Turing-complete language, there's no
fundamental reason you CAN'T write a meta-builder in CMake.  But
gosh... the language sure is arcane (but still better than Autotools
by a long shot).  I like to imagine that if CMake were starting off
today, it would be written in Python.
Language is a 

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

[Elizabeth A. Fischer]

Well, I tried upstreaming the new build scripts to some projects and it
didn’t go well.
Some of the reasons I’ve heard of:

> I installed CMake 2.8.6 five years ago and I don’t want to update yet
> again!  People relying on old versions is quite common and any attempt
> to raise the min version will be frowned upon (see the discussion in
> the LLVM mailing lists for example).

Spack is really good at installing dependencies, and makes this a LOT
easier.  In your Spack recipe, you just tell it which version of CMake
your package needs.  If Spack hasn't already built that
version, it will download and install it for you.  Building packages by
hand, and configuring their dependencies, needs to go the way of stone
spears.

> We prefer to use autotools and don’t want to have to learn CMake.
> That’s fair. But also, no one likes to build an autotools backed
> project for Android or iOS.

I suppose it's fair.  But a Google search of "convert CMake to
Autotools" results in 9:1 stories of people abandoning Autotools for
CMake.  Except for the fact that it works well for users, I can't say
enough evil things about Autotools.

Part of the benefit of Autotools is it "just works" without
requiring the user to install anything.  This benefit is of little
value once you move to an auto-builder like Spack.  The days when
you can get any interesting software to work without installing
a zillion dependencies first are long gone.

> I’ve never heard of Spack before. It looks better than other solutions
> I’ve seen before.

The great and unique thing about Spack is it can install a zillion versions
of each package.  For example... if Package B uses MPI, I can build B-1.7
two (or more) times --- once with OpenMPI and once with MPICH.  And I can
install them side-by-side.  If you change any of the dependencies of a
package, Spack will see that as a new and separate version.  Most
auto-builders let you build one software distro, with only one build of
each package (or sometimes one build per numerical version of the package
or compiler or something).  Spack's versioning is a lot more powerful.

> But you still have to manage all the options from your build script

Not sure what you mean by this.  True, there is some redundancy building
code.  First you put the options and dependencies in a package's CMake
build.  And then you put them into the Spack build again.  Some things
could be simplified if we assumed our CMake-based packages would only ever
be built with Spack.  But we still need to create CMake-based software that
can be installed by hand.  Hence the redundancy between the CMake build
scripts and the Spack package.  In practice, this has not been the
end of the world.

Another nice thing about Spack is there is no difference between your
libraries and Third-party libraries.

> and publish the binaries somewhere.

In its original incarnation, Spack builds from source.  It does not publish
or install from binary distros (because the build you asked for, with all
its dependency variants, is likely not a build that's ever been built
before).  There's currently work on a project to use Spack to produce
binary RPMs, and maybe other forms of binary distribution.

> Then you need to teach your build scripts to get the right version.

Your build scripts know nothing about Spack.  Spack is an auto-builder that
sits ON TOP of your build scripts.

> I won’t trade my builds from source for a set of prebuilt binaries
anytime soon I think :)

Spack builds from source, it is not prebuilt binaries.

> > I don't think CMake is the best place to do it,
> Can you provide any details? I personally think that CMake is a
> natural and the only place where it should be done.

The most important reason here is because there are combinatorially
many versions of a package you COULD install, depending on what
versions of its dependencies you link with, and CMake provides nothing
to address that issue.  See here for an overview of how Spack
addresses the combinatorial versioning issue (which no other
auto-builder does, to the best of my knowledge):

http://hpcugent.github.io/easybuild/files/SC14_BoF_Spack.pdf

Once you've built something, it's nice to be able to re-use it.  If I
have a top-level CMake project that automatically builds three
dependencies, will other projects be able to make use of those
dependencies I've built?  Or do they become private?  If libraries
cannot be shared between applications, you will get a LOT of library
bloat, especially among the low-level libraries that get repeated
numerous times.  Admittedly, this may not be such an issue in some
environments where people are really only focused on building one
thing.

If you make a project, you might see it as a "top-level" project.  But
someone else might want to build something bigger on top of your work.  You
can never assume that "this package is top-level and no one will ever
depend on it."

Another obvious problem with using CMake for everything is that not
all packages 

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

[Ruslan Baratov via CMake]

On 16-Aug-16 16:37, Florent Castelli wrote:
Well, I tried upstreaming the new build scripts to some projects and 
it didn’t go well.

Some of the reasons I’ve heard of:
- Windows developpers don’t use CMake, they have project files on the 
repository.

  The CMake files for Windows will never be updated.
They can coexists, it's easier then maintaining forks. If only C++ code 
changed you got new version "for free".


- I installed CMake 2.8.6 five years ago and I don’t want to update 
yet again!
  People relying on old versions is quite common and any attempt to 
raise the min
  version will be frowned upon (see the discussion in the LLVM mailing 
lists for example).
You can add `if(CMAKE_VERSION VERSION_LESS ...)` condition. It's hard to 
support such hairy configuration but anyway.



- We prefer to use autotools and don’t want to have to learn CMake.
  That’s fair. But also, no one likes to build an autotools backed 
project for Android or iOS.
Just for your info Hunter use build scheme for autotools project: 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/modules/hunter_autotools_project.cmake
It can create universal iOS libraries and works for Android. There are a 
lot of efforts made by Alexandre Pretyman so this can be possible, it 
has some peculiarities. I guess he can clarify anything if you need details.


Ruslo
--

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

[Ruslan Baratov via CMake]

On 16-Aug-16 17:04, Florent Castelli wrote:


On 16 Aug 2016, at 15:29, Ruslan Baratov > wrote:


On 16-Aug-16 13:52, Florent Castelli wrote:
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.

Not a problem for Hunter.

Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, 
LeakSan, ThreadSan, Static Analyzer,  libstdc++, libc++, MinGW, 
Visual Studio 2008-2015:

* https://travis-ci.org/ingenue/hunter/builds/140317830
* https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665

This list is not even full, I guess I can add more toolchains in 
future (GCC variations and C++ standards).


To test all matrix I need to push one commit to pkg.boost branch, to 
upload binaries to server I need to push one commit to upload.boost 
branch (upload ALL toolchains at one shot). To reuse all updates 
users just need to set new URL/SHA1 of HunterGate module: 
https://github.com/ruslo/hunter/releases


Overall, building boost takes 10s on our developers’ machines. The 
sources aren’t changed often,

so the cost is pretty low.
What kind of hardware do they have? And what libraries you mean? It 
takes about 20 seconds on my Linux machine just to unpack 80 MB of 
Boost release archive. It's even worse on Windows, it takes several 
minutes for some strange reason even on SSD + Core i7. Using binaries 
in such cases is a huge time saver because there is no need to 
compile anything and there is no a lot of junk that they put into 
release archive (if you remove docs and tests 80 MB became 15 MB).


I consider the time to download Boost isn’t part of the build.
I'm not counting that. It takes 20 seconds just to unpack archive that 
already downloaded. Anyway I'm just wondering what is possible to do 
with Boost for 10 seconds. Install header-only libraries? Build 1-2 
libraries? All of them? :)


The Boost source download is cached outside of the build directory in 
a unique folder.

So it’s effectively only done once for all platforms and then reused.
This is true for local machines and for custom build servers like your 
personal Jenkins. For Travis/AppVeyor you have to create root folder 
with 3rd parties from scratch for each build (at least for free public 
accounts).




You’ll also have symbols and the sources available for debugging 
properly, and they’re

not always available with a binary distribution.
Just to clarify: with Hunter you're creating binaries from sources, so 
everything you install with `cmake --build _builds --target install` (or 
`./b2 install` for Boost) is available.





Of course building from source is not an option for such monsters 
like Qt or OpenCV. Ready-to-use binaries is something critical for 
real life applications. There is no way to test everything on 
Travis/AppVeyor without this feature.


Well, you don’t have to use Travis or AppVeyor.
It's the most powerful and easy to setup services I know. If you know 
any better solutions please share.



Spotify isn’t at the same scale as most
projects hosted there and we have different requirements and resources.
Admittedly, Spotify doesn’t use Qt anymore, so this isn’t a problem 
for us.
It's not about Qt, it's about expandability. Use 20 of smaller libraries 
and you will have quite the same issues.




Note that by integrating everything in the same project, you also have 
proper dependencies
and you will only build what you need. You may save some time by doing 
that.

And caching is important, when done in the right way!
With Hunter you're installing only what you need too, it does respect 
options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only binaries 
for toolchain you're currently working on, etc.


Don't want to make a discussion too broad. You said that it's hard to 
manage binaries for a lot of configuration, I'm saying that it's 
possible and is very handy.


Ruslo
-- 

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

[Ruslan Baratov via CMake]

On 16-Aug-16 13:52, Florent Castelli wrote:

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.

Not a problem for Hunter.

Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, 
LeakSan, ThreadSan, Static Analyzer,  libstdc++, libc++, MinGW, Visual 
Studio 2008-2015:

* https://travis-ci.org/ingenue/hunter/builds/140317830
* https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665

This list is not even full, I guess I can add more toolchains in future 
(GCC variations and C++ standards).


To test all matrix I need to push one commit to pkg.boost branch, to 
upload binaries to server I need to push one commit to upload.boost 
branch (upload ALL toolchains at one shot). To reuse all updates users 
just need to set new URL/SHA1 of HunterGate module: 
https://github.com/ruslo/hunter/releases



Overall, building boost takes 10s on our developers’ machines. The sources 
aren’t changed often,
so the cost is pretty low.
What kind of hardware do they have? And what libraries you mean? It 
takes about 20 seconds on my Linux machine just to unpack 80 MB of Boost 
release archive. It's even worse on Windows, it takes several minutes 
for some strange reason even on SSD + Core i7. Using binaries in such 
cases is a huge time saver because there is no need to compile anything 
and there is no a lot of junk that they put into release archive (if you 
remove docs and tests 80 MB became 15 MB).


Of course building from source is not an option for such monsters like 
Qt or OpenCV. Ready-to-use binaries is something critical for real life 
applications. There is no way to test everything on Travis/AppVeyor 
without this feature.


Ruslo
--

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

[Elizabeth A. Fischer]

CMake builds for existing libraries are certainly an interesting and useful
thing, and deserve to be posted in a GitHub repo somewhere.  They should
also serve as the basis of a campaign to get the library authors to
incorporate the CMake build directly in their repos.

But any approach that requires every build to be ported to CMake will be
difficult and labor-prone to scale.  Writing a meta-build recipe is usually
much easier.

Spack handles the combinatorial dependencies you mention in a
sophisticated, graceful way that most meta-builders do not.  Its only
problem is it does not (yet) run on Windows.  There's no fundamental reason
why not; we just need someone to get involved and start trying it on
Windows.

-- Elizabeth


On Tue, Aug 16, 2016 at 6:52 AM, Florent Castelli <
florent.caste...@gmail.com> wrote:

> 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 

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 

[CMake] CMake updates timestamp when there are missing files.

[Golebiewski, Jakub]

Hi,

I've noticed a weird (but maybe expected) behavior.

My colleague forgot to edit CMakeLists.txt file for a library from which he 
deleted a .cpp file. As expected cmake failed with an error message during 
build. But next build after that passed without issues. CMake didn't run even 
though the file was still missing. It seems that previous (failed) cmake run 
updated timestamp anyway.

I'm using CMake 3.2.3 with "Visual Studio 2010 Win64" generator.

Is this expected behavior? Can I somehow prevent that?

Regards,
Jakub Golebiewski


**
This e-mail and any attachments thereto may contain confidential information 
and/or information protected by intellectual property rights for the exclusive 
attention of the intended addressees named above. If you have received this 
transmission in error, please immediately notify the sender by return e-mail 
and delete this message and its attachments. Unauthorized use, copying or 
further full or partial distribution of this e-mail or its contents is 
prohibited.
**
-- 

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 3.5 vs 3.6 + qt

[Tom Kulaga]

Thanks

On Thu, 21 Jul 2016, 23:33 Brad King <brad.k...@kitware.com> wrote:

> On 07/18/2016 06:53 PM, Tom Kulaga wrote:
> > I'll try and get together a minimal example to highlight the difference.
>
> This has now been reported with additional information here:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16209
>
> We will have to revert the offending changes until another
> solution is found.
>
> -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