date:20151221

[CMake] still having rpath problems on osx

2015-12-21 Thread Boudewijn Rempt


I'm still having rpath problems when creating libraries on OSX... And I'm not 
sure what's going on here. Here's the output for a single library:

otool -L ../i/lib/libkritaimage.dylib 
../i/lib/libkritaimage.dylib:

/Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libImath.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
@rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version 
22.0.0)
@rpath/libIex.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
@rpath/libHalf.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
@rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
/Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, 
current version 8.4.0)
@rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
/Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
@rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility 
version 5.6.0, current version 5.6.0)
/Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
/Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
/Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
@rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility 
version 5.6.0, current version 5.6.0)
@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 
5.6.0, current version 5.6.0)
/Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, 
current version 5.6.0)
@rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, 
current version 5.6.0)
/Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, 
current version 5.6.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1225.1.1)

All libraries I link to are built. Some come with a cmake build system, some 
with an automake build system, boost with something else altogether... But I 
wouldn't have expected the way a library is built to make a difference for the 
link lines in the library that links to the other library.

Obviously,
 libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
is wrong -- it's got neither an @rpath, nor a full path.

I'm not sure even why some libraries are linked to with @rpath and others with a 
full path after running a make install, but I cannot figure out why libboost_system

doesn't have anything.

libkritaimage is build with these settings:

* CMake is version 3.4.0

* Policy CMP0042 is set to NEW

* in the toplevel cmakelists.txt, there's

if (APPLE)
set(CMAKE_MACOSX_RPATH ON)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
endif ()

I'm feeling dense, but I just cannot make out the documentation for these 
variables...

Re: [CMake] Tests with assert and Release build type

2015-12-21 Thread Ruslan Baratov via CMake


On 20-Dec-15 01:31, Magnus Therning wrote:

Ruslan Baratov writes:


How about using RelWithDebInfo? See:
http://stackoverflow.com/a/28124715/2288008

Hmm, I'm probably missing something but how does that solve the issue
with some targets requiring NDEBUG to be *undefined* and other targets
requiring NDEBUG to be defined?
I don't think that building targets with different NDEBUG values is a 
good idea. More correct approach will be to introduce custom macro to 
allow checks (i.e. FOO_NDEBUG/FOO_DEBUG).




/M


On 18-Dec-15 20:55, Magnus Therning wrote:

I'm sure I'm not the first one to run into the conflict between a desire
to test the code shipped to customers and the desire to at the same time
define NDEBUG to make sure tests don't have their `assert` turned into
NOOPs.

Is there some nice way of handling this?

I can always remove -DNDEBUG from the CFLAGS for tests (possibly by
defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another
option is to `#undef NDEBUG` in the source of tests.

If there's some more or less standard way to address this I'd like to
use that.

/M

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

There's a big difference between making something easy to use and
making it productive.
   -- Adam Bosworth




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

C++ is history repeated as tragedy. Java is history repeated as farce.
  -- Scott McKay


--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015891]: CMake extracts non-standard filenames incorrectly from tarballs

2015-12-21 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15891 
== 
Reported By:Ben Boeckel
Assigned To:
== 
Project:CMake
Issue ID:   15891
Category:   CMake
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-21 15:21 EST
Last Modified:  2015-12-21 15:21 EST
== 
Summary:CMake extracts non-standard filenames incorrectly
from tarballs
Description: 
Attached is a tarball which contains a file "Appendix A \xc2\xa0 An Introduction
to Preprocessor Metaprogramming.html" (the hex is a UTF-8 non-breaking-space).
"cmake -E tar xzf" will extract the file improperly, mangling it. CMake can then
not delete the mangled file.

Using msys2's (from git-bash) to extract the tarball works as expected (the
filename looks fine and cmake can delete it).
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-21 15:21 Ben BoeckelNew Issue
2015-12-21 15:21 Ben BoeckelFile Added: bad-filename.tar.gz 
  
==

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://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] Tests with assert and Release build type

2015-12-21 Thread Magnus Therning


Ruslan Baratov writes:

> On 20-Dec-15 01:31, Magnus Therning wrote:
>> Ruslan Baratov writes:
>>
>>> How about using RelWithDebInfo? See:
>>> http://stackoverflow.com/a/28124715/2288008
>> Hmm, I'm probably missing something but how does that solve the issue
>> with some targets requiring NDEBUG to be *undefined* and other targets
>> requiring NDEBUG to be defined?
> I don't think that building targets with different NDEBUG values is a
> good idea. More correct approach will be to introduce custom macro to
> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG).

Why not?

/M

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

We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
enthusiastic about.
 -- Albert Einstein


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-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-21 Thread Ruslan Baratov via cmake-developers


On 21-Dec-15 17:19, Bartosz Kosiorek wrote:


Thanks Ruslan for explanation.


Currently we already building fat library for arm (armv7;armv7s;arm64) 
and x86 (i386;x86_64).



That's why my original assumption was that it could be easily enabled 
for Simulator/device (armv7;armv7s;arm64;i386;x86_64).


I could start working on that but if it will be too hacky, then I will 
leave that idea.




BTW I made some benchmarks of Xcode vs Make comparison for our 
internal subproject (with "time" command). Here are results:



Xcode generation:

   real6m31.733s

   user4m51.862s

   sys0m20.268s


Make generation:

   real4m45.089s

   user2m56.117s

   sys0m17.481s


Ninja generation:

  real2m48.585s

  user2m30.712s

  sys0m6.313s



Xcode generation + build time:

   real64m3.238s

   user353m36.825s

   sys46m52.415s


Make generation + build time:

   real61m2.583s

   user358m7.464s

   sys47m21.512s


So it seems in our case, for Generation performance step, we should 
use Ninja.


Ok, thanks for sharing it. This proves what I was thinking - there is no 
difference in build time, but generate time is better for Makefile. 
Probably you can profile CMake and find some bottlenecks.




Best Regards

Bartosz



*From:* Ruslan Baratov 
*Sent:* Saturday, December 19, 2015 6:27 PM
*To:* Bartosz Kosiorek
*Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.

On 18-Dec-15 22:46, Bartosz Kosiorek wrote:


Thank you all for your tips/advice.


From our experience IDE generators (eg. Visual Studio, Xcode) is 
much slower than Make or Ninja. I will attach benchmarks later.



Unfortunately I'm unable to build Universal libraries for x86 and arm 
architectures by using Makefile.


This feature will work only for Xcode. For Makefile generator 
variable/property IOS_INSTALL_COMBINED is ignored. Xcode and Makefile 
differs in internals. Xcode can hold in build directory all variants 
of library like Release/Debug + Simulator/Device:


Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug
Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator 
-config Debug

Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release
Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator 
-config Release


Makefile holds only one variant so building both Simulator/Device in 
one project is tricky. You can build/install several libraries by 
Makefile and combine them with lipo using some external script.



See attached logs.


It seems that two different SDK's (iPhoneOS and 
iPhoneSimulator) needs to be used in that case.


Do you know how it could be fixed?

Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other 
generators?


What do you think about that idea?


Thanks in advance

Bartosz


PS

I'm attaching the script which I'm using for testing purposes.

To reproduce it just run command (from command line):

   cd builddir && cmake .. && cmake --build .




*From:*Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
*Sent:* Saturday, December 12, 2015 6:49 AM
*To:* Bartosz Kosiorek
*Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.


On 12-Dec-15 10:08, Bartosz Kosiorek wrote:

Thanks Ruslan.

I would like to create instruction which is universal for all
generators.

I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only 
for Xcode.



Currently we would like to support both Make/Ninja and Xcode generators,

...


because Make is much faster than Xcode generator, and we are using it 
in our CI system.


Do you mean generate step or build? I've used to compile quite big 
projects like OpenCV with Xcode and according to the `top` it uses 
all my cores with clang++ at 100% CPU time.
Can you show any benchmarks? Also note that Xcode can add some 
additional stuff, like dSYM: 
https://github.com/headupinclouds/gatherer/pull/69



Make is also common for other architectures (Linux, QNX, Android etc.)

Unfortunately

   set(CMAKE_OSX_SYSROOT "iphoneos")

is not working for me.

It displays error:

  /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
/Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .


  -- Configuring done

  -- Generating done

  -- Build files have been written to: 
/Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir


  [ 14%] Building C object 
shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o


  clang: warning: no such sysroot directory: 'iphoneos'

...

Do you have some tip for that?

Yes, this hint was for Xcode generator.


After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works 
perfectly. Thanks


Unfortunately

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

2015-12-21 Thread DJ


Thanks for the feedback everyone.

I think I may be stuck having to learn cmake because several software 
libraries that I am starting to use build with cmake.


Based on the feedback, for no I'll pass on the book and see what I can 
do by reading online.


One of the things that seems to me to be missing is some kind of quick 
description of the overall "theory of cmake". I am a top-down kind of 
person, so I really dislike being left with nothing but "here, type this 
in" which is what a lot of the web stuff seems to be. A sketch of how it 
works conceptually would help me. (Of course, I need examples too.)


Just sayin'.

Best,

- Jake -

On 15-12-18 04:02 PM, DJ wrote:
I have only very recently encountered the need to use cmake. It seems 
this need came all at once out of the blue.


It appears to me that there is a general perception that good tutorial 
material is in short supply. I have followed various tutorials that 
are available online and find them less than stellar. I am mostly 
familiar with gnu toolchain stuff. I admit that I am biased here 
because my own work presents zero requirement for cross-platform 
builds. So far I find cmake documentation to be considerably inferior 
to gnu documentation, but that's just me.


This all led me to consider purchasing the book Mastering CMake. 
However, reviews on Amazon are generally very critical of the book. It 
is indeed expensive. Should I bother to shell out for it, or do others 
here share this negative evaluation of it? I don't want to waste my 
money.


Best,

- Jake -




--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://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] Are the poor reviews of Mastering CMake Justified?

2015-12-21 Thread Pau Garcia i Quiles

On Mon, Dec 21, 2015 at 11:11 PM, DJ  wrote:


>
> One of the things that seems to me to be missing is some kind of quick
> description of the overall "theory of cmake". I am a top-down kind of
> person, so I really dislike being left with nothing but "here, type this
> in" which is what a lot of the web stuff seems to be. A sketch of how it
> works conceptually would help me. (Of course, I need examples too.)
>
>
It's old but it still gets a few hundreds downloads a month:

http://www.elpauer.org/stuff/learning_cmake.pdf


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://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] Are the poor reviews of Mastering CMake Justified?

2015-12-21 Thread Bruce Stephens

On Mon, Dec 21, 2015 at 10:11 PM, DJ  wrote:

> One of the things that seems to me to be missing is some kind of quick
> description of the overall "theory of cmake". I am a top-down kind of
> person, so I really dislike being left with nothing but "here, type this
> in" which is what a lot of the web stuff seems to be. A sketch of how it
> works conceptually would help me. (Of course, I need examples too.)
>


There's the manages. Specifically cmake-buildsystem(7) and
cmake-language(7) (and the others, though those are more reference lists of
details).
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1800-gddbacc2

2015-12-21 Thread Brad King

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

The branch, next has been updated
   via  ddbacc21f0b21abed14bf1ba34437cf03b299f73 (commit)
   via  d9bf5206d007507fff3e1a89b8f49d7960a209c8 (commit)
  from  b6883ac381657dd855dfe9a8cda76b040a225dcf (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ddbacc21f0b21abed14bf1ba34437cf03b299f73
commit ddbacc21f0b21abed14bf1ba34437cf03b299f73
Merge: b6883ac d9bf520
Author: Brad King 
AuthorDate: Mon Dec 21 09:34:42 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 21 09:34:42 2015 -0500

Merge topic 'vs-compiler-id-itanium' into next

d9bf5206 CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9bf5206d007507fff3e1a89b8f49d7960a209c8
commit d9bf5206d007507fff3e1a89b8f49d7960a209c8
Author: Brad King 
AuthorDate: Mon Dec 21 09:30:26 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 21 09:34:16 2015 -0500

CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889)

VS expects the platform to be just `Itanium`, so drop the incorrect
special case mapping it to `ia64`.  This platform name has been wrong
since the logic was added by commit v2.8.10~148^2~8 (VS: Detect the
compiler id and tool location, 2012-08-16).

diff --git a/Modules/CMakeDetermineCompilerId.cmake 
b/Modules/CMakeDetermineCompilerId.cmake
index 81c2509..5b3c7f2 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -182,9 +182,6 @@ Id flags: ${testflags}
   set(v 6)
   set(ext dsp)
 endif()
-if("${id_platform}" STREQUAL "Itanium")
-  set(id_platform ia64)
-endif()
 if(CMAKE_VS_PLATFORM_TOOLSET)
   if(CMAKE_VS_PLATFORM_NAME STREQUAL "Tegra-Android")
 set(id_toolset 
"${CMAKE_VS_PLATFORM_TOOLSET}")

---

Summary of changes:
 Modules/CMakeDetermineCompilerId.cmake |3 ---
 1 file changed, 3 deletions(-)


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-746-ga53e016

2015-12-21 Thread Brad King

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

The branch, master has been updated
   via  a53e0168c344111de301ad67498ad89862b58cdf (commit)
   via  a5dd0c9d427d66f7e361b0aa714a0a41b65ae4f0 (commit)
   via  036b6ef7c47ccb19f291d2f36df37aaf885b4ba8 (commit)
   via  12293371ee0f3b930afee8d328415968eb8201e6 (commit)
   via  3fdbb0a806f67f10ea8428e03a4523d08d2b083c (commit)
   via  55b21d072e2df9a35a354fd33e8cf2d0c3bd22be (commit)
   via  c7d9a249118a7b01ed8fa9cc8c61833e39d251d2 (commit)
  from  3768a79c232dc2456b9e9b70da6582b0eb1e78f1 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a53e0168c344111de301ad67498ad89862b58cdf
commit a53e0168c344111de301ad67498ad89862b58cdf
Merge: 3768a79 a5dd0c9
Author: Brad King 
AuthorDate: Mon Dec 21 09:41:09 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 21 09:41:09 2015 -0500

Merge topic 'import-kwiml'

a5dd0c9d Add option to use a system-installed KWIML
036b6ef7 Port CMake from cmIML to KWIML
12293371 Merge branch 'upstream-KWIML' into import-kwiml
3fdbb0a8 KWIML 2015-12-09 (43f9f8d0)
55b21d07 Add script to update KWIML from upstream
c7d9a249 Utilities/KWIML: Drop sources to make room for fresh import


---

Summary of changes:
 CMakeLists.txt |   29 +-
 CTestCustom.cmake.in   |2 +-
 Source/CMakeLists.txt  |1 +
 Source/cmAlgorithms.h  |4 +-
 Source/cmELF.cxx   |   11 +-
 Source/cmFileCommand.cxx   |4 +-
 Source/cmFindPackageCommand.h  |2 +-
 Source/cmLocalGenerator.cxx|4 +-
 Source/cmLocalGenerator.h  |4 +-
 Source/cmStandardIncludes.h|2 +-
 Source/cmVersion.h |2 +-
 Source/cm_sha2.c   |   13 +-
 Source/cm_sha2.h   |   10 +-
 Utilities/KWIML/.gitattributes |1 +
 Utilities/KWIML/ABI.h.in   |  506 -
 Utilities/KWIML/CMakeLists.txt |  145 +--
 Utilities/KWIML/Copyright.txt  |2 +-
 Utilities/KWIML/INT.h.in   |  861 
 Utilities/KWIML/README.md  |   36 +
 Utilities/KWIML/README.txt |   29 -
 Utilities/KWIML/include/kwiml/abi.h|  562 ++
 Utilities/KWIML/include/kwiml/int.h| 1069 
 Utilities/KWIML/src/kwiml-config.cmake.in  |1 +
 Utilities/KWIML/src/version.h.in   |   59 ++
 Utilities/KWIML/test/CMakeLists.txt|   48 +-
 Utilities/KWIML/test/test.c|   32 +-
 Utilities/KWIML/test/test.cxx  |   16 +-
 Utilities/KWIML/test/test.h|   31 +-
 Utilities/KWIML/test/test_ABI_C.c  |   22 -
 Utilities/KWIML/test/test_ABI_CXX.cxx  |   22 -
 Utilities/KWIML/test/test_ABI_endian.h.in  |   47 -
 Utilities/KWIML/test/test_INT_C.c  |   22 -
 Utilities/KWIML/test/test_INT_CXX.cxx  |   22 -
 Utilities/KWIML/test/test_abi_C.c  |   19 +
 Utilities/KWIML/test/test_abi_CXX.cxx  |   19 +
 Utilities/KWIML/test/test_abi_endian.h |   41 +
 Utilities/KWIML/test/test_include_C.c  |   20 +-
 Utilities/KWIML/test/test_include_CXX.cxx  |   20 +-
 Utilities/KWIML/test/test_int_C.c  |   19 +
 Utilities/KWIML/test/test_int_CXX.cxx  |   19 +
 .../{test_INT_format.h.in => test_int_format.h}|   83 +-
 .../{update-kwsys.bash => update-kwiml.bash}   |   10 +-
 Utilities/cmThirdParty.h.in|1 +
 Utilities/{cm_jsoncpp_writer.h => cm_kwiml.h}  |   14 +-
 Utilities/cmjsoncpp/CMakeLists.txt |1 +
 bootstrap  |   31 +-
 46 files changed, 2108 insertions(+), 1810 deletions(-)
 create mode 100644 Utilities/KWIML/.gitattributes
 delete mode 100644 Utilities/KWIML/ABI.h.in
 delete mode 100644 Utilities/KWIML/INT.h.in
 create mode 100644 Utilities/KWIML/README.md
 delete mode 100644 Utilities/KWIML/README.txt
 create mode 100644 Utilities/KWIML/include/kwiml/abi.h
 create mode 100644

Re: [cmake-developers] Can't find correct openssl on Windows

2015-12-21 Thread Brad King

On 12/18/2015 07:49 PM, Patrick Spendrin wrote:
> I attached a patch both here and at the bug report which fixes this
> behaviour for the cost of having an additional and ugly option for the
> FindOpenSSL.cmake file.
> I don't see a different solution, as the no-MD/MT version of the
> library is the backup solution (although the one I would prefer in
> this case).

The OPENSSL_MSVC_NO_RT_MODE patch can be a fallback solution, but we
may be able to avoid it.  Take a look at the NAMES_PER_DIR option of
the find_library command.  Using that it should be possible to find
the library of any name that appears first among the searched locations.

FYI, one may avoid using OpenSSL altogether on Windows by using Schannel
instead:

 https://msdn.microsoft.com/en-us/library/windows/desktop/aa380123.aspx
 https://msdn.microsoft.com/en-us/library/windows/desktop/aa374782.aspx

This is the approach CMake itself currently uses, in particular because
it has the advantage of using the OS-maintained list of root CAs.

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] QtDialog: Allow to set CMAKE_SHARE_DIR

2015-12-21 Thread Brad King

On 12/20/2015 05:07 PM, Niels Ole Salscheider wrote:
> This is needed for multiarch layouts where the prefix is /usr/${host} but
> where arch-independet files are installed to /usr/share.

Thanks.  Some of the current install dir options default to `share/...` as
seen in `Source/CMakeInstallDestinations.cmake`.  Many of the corresponding
installed files are also architecture-independent.  The name `CMAKE_SHARE_DIR`
sounds like it intends to replace all uses of `share/` and architecture-
independent files when in fact it is only for gui system integration files.
Can you propose a more-specific name and description for the option?

Also, the `cmake_install_dest_default` function in the bootstrap script depends
on the source code layout in `Source/CMakeInstallDestinations.cmake` and a
"# OTHER" comment.  Please revise and test that the bootstrap script extracts
the matching default.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake with VS 2015 using Android?

2015-12-21 Thread Robert Dailey

Is it possible for CMake 3.4 to generate VS2015 projects targeting
their new Android functionality? Is this just a matter of configuring
the toolset (-T)? Or is there more to it?
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-739-g3768a79

2015-12-21 Thread Brad King

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

The branch, master has been updated
   via  3768a79c232dc2456b9e9b70da6582b0eb1e78f1 (commit)
   via  928d2085d8ebeadc498e9e9f884b8adabf3346c3 (commit)
  from  ba88bfcf212bc8e93eb065e6d4bafbbf34394e68 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3768a79c232dc2456b9e9b70da6582b0eb1e78f1
commit 3768a79c232dc2456b9e9b70da6582b0eb1e78f1
Merge: ba88bfc 928d208
Author: Brad King 
AuthorDate: Mon Dec 21 09:41:02 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 21 09:41:02 2015 -0500

Merge topic 'fix-absolute-libs-for-cray-wrappers'

928d2085 CrayPrgEnv: Don't use absolute paths for imlicit libraries


---

Summary of changes:
 Modules/Compiler/CrayPrgEnv.cmake |   17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1808-ga314171

2015-12-21 Thread Brad King

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

The branch, next has been updated
   via  a314171669df6f6b8584eec9554b68b542841ba2 (commit)
   via  8b627550ef91e12a0952e8ed271a4f90a8da1aaa (commit)
  from  4631633ebf7cf92bc1ed03c24d51d74e00519fcb (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a314171669df6f6b8584eec9554b68b542841ba2
commit a314171669df6f6b8584eec9554b68b542841ba2
Merge: 4631633 8b62755
Author: Brad King 
AuthorDate: Mon Dec 21 09:51:46 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 21 09:51:46 2015 -0500

Merge topic 'suppress-Wshadow-single' into next

8b627550 CTestCustom: Suppress -Wshadow warning about Solaris 'single' 
typedef


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8b627550ef91e12a0952e8ed271a4f90a8da1aaa
commit 8b627550ef91e12a0952e8ed271a4f90a8da1aaa
Author: Brad King 
AuthorDate: Mon Dec 21 09:48:35 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 21 09:49:00 2015 -0500

CTestCustom: Suppress -Wshadow warning about Solaris 'single' typedef

On Solaris the system `/usr/include/floatingpoint.h` header contains

 typedef float single;

so the GNU compiler warns that uses of the name `single` shadow it.
Just suppress the warning because our uses of this name would become
less readable with a different name.

diff --git a/CTestCustom.cmake.in b/CTestCustom.cmake.in
index db64559..634d22a 100644
--- a/CTestCustom.cmake.in
+++ b/CTestCustom.cmake.in
@@ -21,6 +21,7 @@ list(APPEND CTEST_CUSTOM_WARNING_EXCEPTION
   "Utilities.cmcurl"
   "Utilities.cmexpat."
   "Utilities.cmlibarchive"
+  "warning: declaration of .single. shadows a global declaration"
   "/usr/include.*warning.*shadowed declaration is here"
   "/usr/bin/ld.*warning.*-..*directory.name.*bin.*does not exist"
   "Redeclaration of .send. with a different storage class specifier"

---

Summary of changes:
 CTestCustom.cmake.in |1 +
 1 file changed, 1 insertion(+)


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-747-g8a45573

2015-12-21 Thread Kitware Robot

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

The branch, master has been updated
   via  8a45573e99165e926482b07da5ceb3dd86307ea5 (commit)
  from  a53e0168c344111de301ad67498ad89862b58cdf (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a45573e99165e926482b07da5ceb3dd86307ea5
commit 8a45573e99165e926482b07da5ceb3dd86307ea5
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Dec 22 00:01:07 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Dec 22 00:01:07 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 15feed4..636083d 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20151221)
+set(CMake_VERSION_PATCH 20151222)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [CMake] CPack and PackageMaker

2015-12-21 Thread Roman Wüger

Is there anything I can do to support?

Best regards 

> Am 11.12.2015 um 20:17 schrieb robert.bielik :
> 
> Dear Clint,
>  
> Thank you! Will certainly start with that as a base :)
>  
> Regards 
> /R
>  
> -- Ursprungligt meddelande--
> Från:
> Datum: fre, 11 dec 2015 20:12
> Till: Robert Bielik;
> Kopia: Attila Krasznahorkay;cmake;
> Ämne:Re: [CMake] CPack and PackageMaker
>  
> If you are interested, attached is some code I started a couple years ago but 
> never finished, nor did I do much testing.
> Perhaps that'll help, or maybe you'll find a better way.
> 
> Clint
> 
> - On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bie...@dirac.se wrote:
> 
> > Dear Attila,
> > 
> > Ok, been struggling getting an installation package to work with the
> > pkgbuild/productbild tools, so I think I got the gist of what needs to
> > be done, at least to get something going :)
> > 
> > Regards
> > /R
> > 
> > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay:
> >> Hi Robert,
> >>
> >> I'm afraid that the sad situation is that nobody has done this yet, or is
> >> working on it at the moment.
> >>
> >> I'm absolutely sure that if you can help with this by any amount, that 
> >> will be
> >> most welcome by the CMake developers. It will certainly be most welcome by 
> >> me,
> >> as I've been disappointed by the lack of this support as well. (But
> >> unfortunately can't spare the time to help out in writing this CPack
> >> generator.)
> >>
> >> Cheers,
> >>   Attila
> >>
> >>> On 11 Dec 2015, at 17:44, Robert Bielik  wrote:
> >>>
> >>> Really ? No one ? :)
> >>>
> >>> So it's ok to go ahead and start create a new one ? ;)
> >>>
> >>> Rgds,
> >>> /R
> >>>
> >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik:
>  Mac OSX:
> 
>  Since PackageMaker has been deprecated by Apple, the new tools to use are
>  pkgbuild [1] and productbuild [2].
> 
>  Simple question: Is there any work being done by the CMake community on 
>  a new OS
>  X CPack backend to support the above tools ?
> 
>  Regards
>  /Robert
>  [1]
>  https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
>  [2]
>  https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.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
> > 
> > --
> > 
> > Powered by www.kitware.com
> > 
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> > 
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> > 
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://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


smime.p7s
Description: S/MIME cryptographic 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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-21 Thread Bartosz Kosiorek

Thanks Ruslan for explanation.


Currently we already building fat library for arm (armv7;armv7s;arm64) and x86 
(i386;x86_64).


That's why my original assumption was that it could be easily enabled for 
Simulator/device (armv7;armv7s;arm64;i386;x86_64).

I could start working on that but if it will be too hacky, then I will leave 
that idea.



BTW I made some benchmarks of Xcode vs Make comparison for our internal 
subproject (with "time" command). Here are results:


Xcode generation:

   real 6m31.733s

   user 4m51.862s

   sys 0m20.268s


Make generation:

   real 4m45.089s

   user 2m56.117s

   sys 0m17.481s


Ninja generation:

  real 2m48.585s

  user 2m30.712s

  sys 0m6.313s



Xcode generation + build time:

   real 64m3.238s

   user 353m36.825s

   sys 46m52.415s


Make generation + build time:

   real 61m2.583s

   user 358m7.464s

   sys 47m21.512s


So it seems in our case, for Generation performance step, we should use Ninja.


Best Regards

Bartosz



From: Ruslan Baratov 
Sent: Saturday, December 19, 2015 6:27 PM
To: Bartosz Kosiorek
Cc: Clinton Stimpson; Gregor Jasny; CMake Developers
Subject: Re: [cmake-developers] Create subdirectories in Resource directory for 
Frameworks and Application bundle.

On 18-Dec-15 22:46, Bartosz Kosiorek wrote:
Thank you all for your tips/advice.

From our experience IDE generators (eg. Visual Studio, Xcode) is much slower 
than Make or Ninja. I will attach benchmarks later.

Unfortunately I'm unable to build Universal libraries for x86 and arm 
architectures by using Makefile.
This feature will work only for Xcode. For Makefile generator variable/property 
IOS_INSTALL_COMBINED is ignored. Xcode and Makefile differs in internals. Xcode 
can hold in build directory all variants of library like Release/Debug + 
Simulator/Device:

Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug
Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config Debug
Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release
Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config 
Release

Makefile holds only one variant so building both Simulator/Device in one 
project is tricky. You can build/install several libraries by Makefile and 
combine them with lipo using some external script.

See attached logs.

It seems that two different SDK's (iPhoneOS and iPhoneSimulator) needs to be 
used in that case.
Do you know how it could be fixed?
Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other generators?
What do you think about that idea?

Thanks in advance
Bartosz

PS
I'm attaching the script which I'm using for testing purposes.
To reproduce it just run command (from command line):
   cd builddir && cmake .. && cmake --build .




From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Saturday, December 12, 2015 6:49 AM
To: Bartosz Kosiorek
Cc: Clinton Stimpson; Gregor Jasny; CMake Developers
Subject: Re: [cmake-developers] Create subdirectories in Resource directory for 
Frameworks and Application bundle.

On 12-Dec-15 10:08, Bartosz Kosiorek wrote:

Thanks Ruslan.



I would like to create instruction which is universal for all generators.
I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only for Xcode.



Currently we would like to support both Make/Ninja and Xcode generators,
...



because Make is much faster than Xcode generator, and we are using it in our CI 
system.
Do you mean generate step or build? I've used to compile quite big projects 
like OpenCV with Xcode and according to the `top` it uses all my cores with 
clang++ at 100% CPU time.
Can you show any benchmarks? Also note that Xcode can add some additional 
stuff, like dSYM: https://github.com/headupinclouds/gatherer/pull/69



Make is also common for other architectures (Linux, QNX, Android etc.)



Unfortunately

   set(CMAKE_OSX_SYSROOT "iphoneos")

is not working for me.

It displays error:


  /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
/Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .
  -- Configuring done
  -- Generating done
  -- Build files have been written to: 
/Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir
  [ 14%] Building C object shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o
  clang: warning: no such sysroot directory: 'iphoneos'
...
Do you have some tip for that?
Yes, this hint was for Xcode generator.




After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works perfectly. 
Thanks

Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not working 
with Make.
Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already have 
CMAKE_OSX_DEPLOYMENT_TARGET?
Since OSX_ARCHITECTURES controls iOS architectures too I think request should 
sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS platform".



I have attached my example script which I'm using.
Could

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

2015-12-21 Thread Raymond Wan

Hi Jake,

On Sat, Dec 19, 2015 at 5:02 AM, DJ  wrote:
> This all led me to consider purchasing the book Mastering CMake. However,
> reviews on Amazon are generally very critical of the book. It is indeed
> expensive. Should I bother to shell out for it, or do others here share this
> negative evaluation of it? I don't want to waste my money.

I've purchased the book (the older edition) and it is fine.  I mean,
I'm a bit old-school and do prefer a printed book.  Online docs seem
more of an excuse to easily swap between reading and a distraction
(i.e. Facebook) -- but that's just me.

Indeed, it is similar to the online manuals.  And those will get
updated with each subsequent version; a book will not (e-book or on
paper).

I had a hard time getting into CMake and the book isn't written like a
tutorial.  I mean, it explains the first few steps and then jumps to a
reference book (I don't have it with me, but this is from memory).  I
guess there is value in having a CMake book that is entirely a
tutorial or even one of "recipes" -- Mastering CMake (as far as I can
remember) isn't that.

For that, you'd probably have to use the Web...

Ray

PS:  I don't regret buying the book.  At the time, I was really stuck
and overwhelmed by the online documentation.  Having it printed made
it a bit easier for me.  Each person learns differently, but skimming
over the Amazon comments, they seem accurate.  Of course, buy the
latest edition if you end up buying.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://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] How to pass a configuration file to CMake?

2015-12-21 Thread Petr Kmoch

Hi Cedric.

I have never used it myself, but I believe you're looking for CMake's
command-line option '-C ':
https://cmake.org/cmake/help/latest/manual/cmake.1.html

Petr

On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet 
wrote:

>
> Hello,
>
> I would like to know if it's possible to pass a configuration file to
> CMake.
> I have to pass a lot of information to CMake and the resulting command
> line is very long to type.
> Would it be possible to create a file containing all needed definitions
> and pass it to CMake?
>
> For exemple, instead of typing
>
> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D
> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>
> would it be possible to create a file containing
>
> CMAKE_BUILD_TYPE=Debug
> CMAKE_INSTALL_PREFIX=/home/me/there
> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>
> and pass it to CMake?
>
> Cédric
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://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] How to pass a configuration file to CMake?

2015-12-21 Thread Cedric Doucet


Hello, 

I would like to know if it's possible to pass a configuration file to CMake. 
I have to pass a lot of information to CMake and the resulting command line is 
very long to type. 
Would it be possible to create a file containing all needed definitions and 
pass it to CMake? 

For exemple, instead of typing 

cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D 
CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ 

would it be possible to create a file containing 

CMAKE_BUILD_TYPE=Debug 
CMAKE_INSTALL_PREFIX=/home/me/there 
CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ 

and pass it to CMake? 

Cédric 
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://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] How to pass a configuration file to CMake?

2015-12-21 Thread Cedric Doucet

Hi Peter! 

Thank you very much! 
It seems to be exactly what I want. :) 
I will try to use it. 

Cédric 

- Mail original -

> De: "Petr Kmoch" 
> À: "Cedric Doucet" 
> Cc: cmake@cmake.org
> Envoyé: Lundi 21 Décembre 2015 13:25:53
> Objet: Re: [CMake] How to pass a configuration file to CMake?

> Hi Cedric.

> I have never used it myself, but I believe you're looking for CMake's
> command-line option '-C ':
> https://cmake.org/cmake/help/latest/manual/cmake.1.html

> Petr

> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet < cedric.dou...@inria.fr >
> wrote:

> > Hello,
> 

> > I would like to know if it's possible to pass a configuration file to
> > CMake.
> 
> > I have to pass a lot of information to CMake and the resulting command line
> > is very long to type.
> 
> > Would it be possible to create a file containing all needed definitions and
> > pass it to CMake?
> 

> > For exemple, instead of typing
> 

> > cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D
> > CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
> 

> > would it be possible to create a file containing
> 

> > CMAKE_BUILD_TYPE=Debug
> 
> > CMAKE_INSTALL_PREFIX=/home/me/there
> 
> > CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
> 

> > and pass it to CMake?
> 

> > Cédric
> 

> > --
> 

> > Powered by www.kitware.com
> 

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1815-g2aa0380

2015-12-21 Thread Brad King

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

The branch, next has been updated
   via  2aa03802ead74a2adbcb2687b6a17e783add47db (commit)
   via  fae4779864d1e5a93369b1ac7de9ee7428a28043 (commit)
   via  083312a8fd39f6ff7a9abc79184e31eb233e8933 (commit)
   via  240b065faa9bc3b1a8dcf073a94028cd473a8c62 (commit)
   via  a95b47154ef0508cb30c82b79dab75526743498a (commit)
  from  f80b5b22722ae4e20eec33705a56c3734df2dd05 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2aa03802ead74a2adbcb2687b6a17e783add47db
commit 2aa03802ead74a2adbcb2687b6a17e783add47db
Merge: f80b5b2 fae4779
Author: Brad King 
AuthorDate: Mon Dec 21 11:30:18 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 21 11:30:18 2015 -0500

Merge topic 'release-windows' into next

fae47798 Utilities/Release: Configure Windows binary to support Windows XP
083312a8 Utilities/Release: Switch to .msi builder for Windows binary
240b065f Utilities/Release: Optionally load environment on remote build 
server
a95b4715 Utilities/Release: Add optional remote launcher to ssh calls


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fae4779864d1e5a93369b1ac7de9ee7428a28043
commit fae4779864d1e5a93369b1ac7de9ee7428a28043
Author: Brad King 
AuthorDate: Fri Dec 18 14:35:34 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 21 10:05:03 2015 -0500

Utilities/Release: Configure Windows binary to support Windows XP

Compile with `-D_WIN32_WINNT=0x501` to use a WinXP-compatible API.
Compile with `-D_USING_V110_SDK71_` to tell the VS standard library
headers that we are building with a WinXP-compatible Windows SDK.  Link
executables with `-subsystem:console,5.01` to make them runnable on
Windows XP.  Ideally `cmake-gui` should instead be linked with
`-subsystem:windows,5.01` but with the Ninja and Makefile generators
CMake adds `-subsystem:windows` after our `-subsystem:console,5.01` flag
and the linker seems to interpret this combination as we need.

diff --git a/Utilities/Release/dash3win7_release.cmake 
b/Utilities/Release/dash3win7_release.cmake
index 290b473..f25d638 100644
--- a/Utilities/Release/dash3win7_release.cmake
+++ b/Utilities/Release/dash3win7_release.cmake
@@ -17,7 +17,11 @@ CMAKE_GENERATOR:INTERNAL=Ninja
 BUILD_QtDialog:BOOL:=TRUE
 CMake_GUI_DISTRIBUTE_WITH_Qt_LGPL:BOOL=TRUE
 CMake_INSTALL_DEPENDENCIES:BOOL=ON
+CMAKE_EXE_LINKER_FLAGS:STRING=-machine:x86 -subsystem:console,5.01
 ")
+set(ppflags "-D_WIN32_WINNT=0x501 -D_USING_V110_SDK71_")
+set(CFLAGS "${ppflags}")
+set(CXXFLAGS "${ppflags}")
 set(ENV ". ~/rel/env")
 get_filename_component(path "${CMAKE_CURRENT_LIST_FILE}" PATH)
 set(GIT_EXTRA "git config core.autocrlf true")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=083312a8fd39f6ff7a9abc79184e31eb233e8933
commit 083312a8fd39f6ff7a9abc79184e31eb233e8933
Author: Brad King 
AuthorDate: Thu Dec 10 14:59:09 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 21 09:52:28 2015 -0500

Utilities/Release: Switch to .msi builder for Windows binary

Use a new build machine to produce the Windows binary using the CPack
WiX generator to produce a `.msi` installer.

diff --git a/Help/release/dev/release-windows.rst 
b/Help/release/dev/release-windows.rst
new file mode 100644
index 000..cc9f2d5
--- /dev/null
+++ b/Help/release/dev/release-windows.rst
@@ -0,0 +1,7 @@
+release-windows
+---
+
+* The precompiled Windows binary provided on ``cmake.org`` is now a
+  ``.msi`` package instead of an installer executable.  One may need
+  to manually uninstall CMake versions lower than 3.5 before installing
+  the new package.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 65bfb77..043b757 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -685,7 +685,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   endmacro()
   if(CMAKE_BUILD_NIGHTLY_RELEASES)
 ADD_NIGHTLY_BUILD_TEST(CMakeNightlyWindows
-  dash2win64_release.cmake)
+  dash3win7_release.cmake)
 ADD_NIGHTLY_BUILD_TEST(CMakeNightlyOSX
   dashmacmini5_release.cmake)
 ADD_NIGHTLY_BUILD_TEST(CMakeNightlyLinux32
diff --git a/Utilities/Release/create-cmake-release.cmake 
b/Utilities/Release/create-cmake-release.cmake
index 76057d1..d41c4ec 100644
--- a/Utilities/Release/create-cmake-release.cmake
+++ b/Utilities/Release/create-cmake-release.cmake
@@ -6,7 +6,7 @@ endif()
 file(MAKE_DIRECTORY

Re: [CMake] CMake with VS 2015 using Android?

2015-12-21 Thread Greg Marr

Is it possible for CMake 3.4 to generate VS2015 projects targeting 
their new Android functionality? Is this just a matter of configuring the 
toolset (-T)? Or is there more to it?

No, but Microsoft has added this functionality to their own fork, and is 
working to contribute it back to CMake.

http://blogs.msdn.com/b/vcblog/archive/2015/12/15/support-for-android-cmake-projects-in-visual-studio.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-developers] CMakeFindDependencyMacro limitations

2015-12-21 Thread Stephen Kelly

Roger Leigh wrote:

> I've run into a few limitations in find_dependency.  I'm not sure if
> these are by design or could be fixed, so this is really a request for
> further explanation or design rationale.
> 
> The first issue is this:
> 
>if (NOT ${dep}_FOUND)
> 
> This seems to be making the assumption that the found variable matches
> the dependency name, but the case used varies between modules and the
> name is case sensitive, from my reading of cmake-language.  Is this
> correct?

It is intentional, yes. See

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

The config-packages generated by cmake are canonical, so modules should set 
the ExactCase_FOUND to be a 'correct module'.

> Even if so, should this optimisation be put here rather than
> in find_package itself? 

I don't know the answer to this.

> If case sensitivity/naming is an issue, could
> the _FOUND variable be passed in as an argument, leaving the existing
> behaviour as the default if unspecified?

I don't think that's a good idea.

> The reason for stripping EXACT isn't clear.  If my package has a strict
> requirement on another package, whether the caller has an exact
> requirement for the version of my package has no bearing on the
> requirements I have for my dependencies as far as I understand.  What's
> the reason for the existing behaviour?

I don't know what you are referring to with 'stripping EXACT'. Perhaps you 
are looking at CMake < 3.0. See commit v3.0.0-rc2~10^2 (find_dependency: 
Don't propagate EXACT argument., 2014-03-06).

> Support for find_package arguments is limited to the dependency name and
> optionally the version.  

... and optionally EXACT.

> I can understand why REQUIRED and related
> arguments are omitted--that is why find_dependency exists--but I'd quite
> like to be able to specify COMPONENTS where needed e.g. with FindBoost,
> and this is not currently possible.

I don't remember whether this was discussed when designing find_dependency. 
Perhaps COMPONENTS could be added to the macro now.

> I was wondering if we could perhaps make find_dependency handle and pass
> through /all/ find_package arguments, minus REQUIRED/QUIET, so that
> find_dependency can expose the additional functionality offered by
> find_package.  Some may not be useful, in which case they could be
> omitted, but some like COMPONENTS may be required for the find_package
> call to be useful.

It might be possible, but might not be a good idea. What else do you want to 
pass in?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015890]: file(STRINGS ..) doesn't work on single character files.

2015-12-21 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15890 
== 
Reported By:Fredrik Björkenfors
Assigned To:
== 
Project:CMake
Issue ID:   15890
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-21 10:43 EST
Last Modified:  2015-12-21 10:43 EST
== 
Summary:file(STRINGS ..) doesn't work on single character
files.
Description: 
If the file passed to file(STRINGS  VAR) contains a single character file
VAR will be empty.

Steps to Reproduce: 
Run CMake on the attached project.

Workaround: Adding any character to the input file, including an EOL character.

Additional Information: 
If the file has less than 2 characters ReadBOM(std::istream& in) will set the
failbit and the attempt to rewind the file will fail. 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-21 10:43 Fredrik BjörkenforsNew Issue  
 
2015-12-21 10:43 Fredrik BjörkenforsFile Added: CMake_bug.zip  
 
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR

2015-12-21 Thread Niels Ole Salscheider

This is needed for multiarch layouts where the prefix is /usr/${host} but
where arch-independet files (like the XDG specific ones) are installed to
/usr/share.
---
 Source/CMakeInstallDestinations.cmake | 5 +
 Source/QtDialog/CMakeLists.txt| 6 +++---
 bootstrap | 7 +++
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Source/CMakeInstallDestinations.cmake 
b/Source/CMakeInstallDestinations.cmake
index 99c86ca..2f9d95a 100644
--- a/Source/CMakeInstallDestinations.cmake
+++ b/Source/CMakeInstallDestinations.cmake
@@ -3,24 +3,29 @@ if(BEOS)
   set(CMAKE_DATA_DIR_DEFAULT 
"share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # HAIKU
   set(CMAKE_MAN_DIR_DEFAULT "documentation/man") # HAIKU
   set(CMAKE_DOC_DIR_DEFAULT 
"documentation/doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # HAIKU
+  set(CMAKE_XDGDATA_DIR_DEFAULT "share") # HAIKU
 elseif(CYGWIN)
   set(CMAKE_DATA_DIR_DEFAULT "share/cmake-${CMake_VERSION}") # CYGWIN
   set(CMAKE_DOC_DIR_DEFAULT "share/doc/cmake-${CMake_VERSION}") # CYGWIN
   set(CMAKE_MAN_DIR_DEFAULT "share/man") # CYGWIN
+  set(CMAKE_XDGDATA_DIR_DEFAULT "share") # CYGWIN
 else()
   set(CMAKE_DATA_DIR_DEFAULT 
"share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # OTHER
   set(CMAKE_DOC_DIR_DEFAULT 
"doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # OTHER
   set(CMAKE_MAN_DIR_DEFAULT "man") # OTHER
+  set(CMAKE_XDGDATA_DIR_DEFAULT "share") # OTHER
 endif()
 
 set(CMAKE_DATA_DIR_DESC "data")
 set(CMAKE_DOC_DIR_DESC "docs")
 set(CMAKE_MAN_DIR_DESC "man pages")
+set(CMAKE_XDGDATA_DIR_DESC "XDG specific files")
 
 foreach(v
 CMAKE_DATA_DIR
 CMAKE_DOC_DIR
 CMAKE_MAN_DIR
+CMAKE_XDGDATA_DIR
 )
   # Populate the cache with empty values so we know when the user sets them.
   set(${v} "" CACHE STRING "")
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 9161ad3..f17de5d 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -193,7 +193,7 @@ if(UNIX AND NOT APPLE)
   foreach (size IN ITEMS 32 128)
 install(
   FILES   "${CMAKE_CURRENT_SOURCE_DIR}/CMakeSetup${size}.png"
-  DESTINATION "share/icons/hicolor/${size}x${size}/apps"
+  DESTINATION "${CMAKE_XDGDATA_DIR}/icons/hicolor/${size}x${size}/apps"
   ${COMPONENT}
   RENAME  "CMakeSetup.png")
   endforeach ()
@@ -201,10 +201,10 @@ if(UNIX AND NOT APPLE)
   # install a desktop file so CMake appears in the application start menu
   # with an icon
   install(FILES CMake.desktop
-DESTINATION share/applications
+DESTINATION "${CMAKE_XDGDATA_DIR}/applications"
 ${COMPONENT})
   install(FILES cmakecache.xml
-DESTINATION share/mime/packages
+DESTINATION "${CMAKE_XDGDATA_DIR}/mime/packages"
 ${COMPONENT})
 endif()
 
diff --git a/bootstrap b/bootstrap
index b2421a1..97e85bf 100755
--- a/bootstrap
+++ b/bootstrap
@@ -63,9 +63,11 @@ cmake_copyright="`grep '^Copyright .* Kitware' 
"${cmake_source_dir}/Copyright.tx
 cmake_data_dir_keyword="OTHER"
 cmake_doc_dir_keyword="OTHER"
 cmake_man_dir_keyword="OTHER"
+cmake_xdgdata_dir_keyword="OTHER"
 cmake_data_dir=""
 cmake_doc_dir=""
 cmake_man_dir=""
+cmake_xdgdata_dir=""
 cmake_init_file=""
 cmake_bootstrap_system_libs=""
 cmake_bootstrap_qt_gui=""
@@ -214,6 +216,7 @@ fi
 cmake_data_dir_default="`cmake_install_dest_default DATA 
${cmake_data_dir_keyword}`"
 cmake_doc_dir_default="`cmake_install_dest_default DOC 
${cmake_doc_dir_keyword}`"
 cmake_man_dir_default="`cmake_install_dest_default MAN 
${cmake_man_dir_keyword}`"
+cmake_xdgdata_dir_default="`cmake_install_dest_default XDGDATA 
${cmake_xdgdata_dir_keyword}`"
 
 CMAKE_KNOWN_C_COMPILERS="cc gcc xlc icc tcc"
 CMAKE_KNOWN_CXX_COMPILERS="aCC xlC CC g++ c++ icc como "
@@ -428,6 +431,8 @@ Directory and file names:
   ['"${cmake_doc_dir_default}"']
   --mandir=DIRinstall man pages files in PREFIX/DIR/manN
   ['"${cmake_man_dir_default}"']
+  --xdgdatadir=DIRinstall XDG specific files in PREFIX/DIR
+  ['"${cmake_xdgdata_dir_default}"']
 '
   exit 10
 }
@@ -616,6 +621,7 @@ while test $# != 0; do
   --datadir=*) cmake_data_dir=`cmake_arg "$1"` ;;
   --docdir=*) cmake_doc_dir=`cmake_arg "$1"` ;;
   --mandir=*) cmake_man_dir=`cmake_arg "$1"` ;;
+  --xdgdatadir=*) cmake_xdgdata_dir=`cmake_arg "$1"` ;;
   --init=*) cmake_init_file=`cmake_arg "$1"` ;;
   --system-libs) cmake_bootstrap_system_libs="${cmake_bootstrap_system_libs} 
-DCMAKE_USE_SYSTEM_LIBRARIES=1" ;;
   --no-system-libs) 
cmake_bootstrap_system_libs="${cmake_bootstrap_system_libs} 
-DCMAKE_USE_SYSTEM_LIBRARIES=0" ;;
@@ -1368,6 +1374,7 @@ set (CMAKE_INSTALL_PREFIX "'"${cmake_prefix_dir}"'" CACHE 
PATH "Install path pre
 set (CMAKE_DOC_DIR "'"${cmake_doc_dir}"'" CACHE PATH "Install location for 
documentation (relative to prefix)." FORCE)
 set (CMAKE_MAN_DIR "'"${cmake_man_dir}"'" CACHE PATH

Re: [cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR

2015-12-21 Thread Brad King

On 12/21/2015 10:02 AM, Niels Ole Salscheider wrote:
> This is needed for multiarch layouts where the prefix is /usr/${host} but
> where arch-independet files (like the XDG specific ones) are installed to
> /usr/share.

Great, thanks.  Applied:

 QtDialog: Add option to control XDG file install destination
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76566621

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Generate sources (smartly :-))

2015-12-21 Thread Guillaume Maudoux (Layus)

Hi,

I am generating files with some executable called "generator" built with
cmake.

Apparently I am unable to avoid the generator being built even when the
generated files are up to date.
IIRC, EXCLUDE_FROM_ALL should do just that: avoid a target being build
if not strictly needed.

I have reproduced the issue in a small project :

$ tree
.
├── build/...
├── CMakeLists.txt
├── generator
│   ├── CMakeLists.txt
│   └── generator.cc
└── step1
└── CMakeLists.txt

$ tail -n +0 **/*
==> CMakeLists.txt <==
cmake_minimum_required(VERSION 3.4)

add_subdirectory(generator EXCLUDE_FROM_ALL)
add_subdirectory(step1)

==> generator/CMakeLists.txt <==
add_executable(generator EXCLUDE_FROM_ALL generator.cc)

==> generator/generator.cc <==
#include 
#include 
using namespace std;

int main(int argc, char** argv) {
ofstream myfile;
myfile.open (argv[1]);
myfile << "Writing this to a file." << endl;
myfile << argv[2] << endl;
myfile.close();
return 0;
}

==> step1/CMakeLists.txt <==
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/task1.txt
COMMAND ${CMAKE_CURRENT_BINARY_DIR}/../generator/generator
${CMAKE_CURRENT_BINARY_DIR}/task1.txt none
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS generator
VERBATIM)

add_custom_target(task1 ALL
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/task1.txt
VERBATIM)

$ cd build
$ cmake ..
$ touch step1/task1.txt # Simulate import of generated files.
$ make
[ !!! still builds generator, but it is not needed as task1.txt is up to
date ]

I am really annoyed by this issue, as it defeats the advantage of
caching generated files.

Is there something I am missing in my usage of EXCLUDE_FROM_ALL ?

Thx,

Guillaume.


Le 18/12/15 20:53, Layus a écrit :
> On 16/12/15 17:53, Mark Stijnman wrote:
>> On Wed, Dec 16, 2015 at 2:29 PM, Layus > > wrote:
>>
>> Hi,
>>
>> I am looking for a way to share an archive of a partially
>> compiled project to speedup compilation time and configuration
>> hassle for the users.
>>
>> I have a project that works in two steps.
>> First a source generator is built (based on clang) and generates
>> some extra source files based on the existing source files.
>> Then the normal compilation process takes places, building the
>> application from both original and generated sources.
>>
>> 
>>  
>>
>> Now, is it possible to distribute a source archive with the
>> generated sources, in such a way that any user unpacking the
>> archive and running cmake would not have to generate the extra
>> sources ?
>>
>> This would be useful because
>> i) the project is tricky to configure and
>> ii) the generated sources are not dependent on the user config,
>> so building the generator is just useless computation time on the
>> user.
>>
>> The ideal scheme would be something like
>>
>> [developper]
>> $ cmake -DCLANG=config
>> $ make generate
>> $ make package_source
>>
>> [user]
>> $ unpack
>> $ cmake -DUSER=config
>> $ make # builds only the application, reusing the shipped
>> generated sources.
>> $ make install
>>
>> ... but when the user runs cmake, he overwrites the generated
>> Makefiles and the extra sources are generated again.
>>
>> Any idea ?
>>
>> layus.
>>
>> -- 
>>
>>
>> I'd probably just make it such that the CMake script automatically
>> detects the presence of the generated files, and if they don't exist,
>> generate them. For example: 
>> 1. Set a variable GENERATED_FOLDER to
>> ${CMAKE_CURRENT_SOURCE_DIR}/generated
>> 2. If ${GENERATED_FOLDER} doesn't exist, set it to
>> ${CMAKE_CURRENT_BINARY_DIR}/generated instead, and set up the targets
>> that will generate the files in that folder. 
>> 3. Simply use the ${GENERATED_FOLDER} variable to add the generated
>> files to your application. 
>> 4. Set up the package_source target so that it packages the files
>> from ${GENERATED_FOLDER} to a folder called "generated" (such that if
>> a user unpacks from there, they will end up in
>> ${CMAKE_CURRENT_SOURCE_DIR}/generated), and you're done. 
>> 5. Recommended: add a check for the existence of target "generate",
>> and if so, set it as a dependency for your application and
>> package_source.
>>
>> This way, you don't need to remember what switches to use, or when to
>> use "make generate". If you need to make it possible for a user to
>> force generation, you can alter step 2 to also run when a command
>> line option is supplied.
>>
>> Hope that helps,
>>
>> Best regards Mark
>
> Works like a charm.
>
> (See https://github.com/layus/mozart2/tree/cache_generated_code)
>
> Thanks !
>

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each

[Cmake-commits] CMake branch, next, updated. v3.4.1-1810-gf80b5b2

2015-12-21 Thread Brad King

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

The branch, next has been updated
   via  f80b5b22722ae4e20eec33705a56c3734df2dd05 (commit)
   via  7656662148782b7751c62efd256e644c7295c883 (commit)
  from  a314171669df6f6b8584eec9554b68b542841ba2 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f80b5b22722ae4e20eec33705a56c3734df2dd05
commit f80b5b22722ae4e20eec33705a56c3734df2dd05
Merge: a314171 7656662
Author: Brad King 
AuthorDate: Mon Dec 21 10:27:18 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 21 10:27:18 2015 -0500

Merge topic 'install-xdgdata-dir' into next

76566621 QtDialog: Add option to control XDG file install destination


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7656662148782b7751c62efd256e644c7295c883
commit 7656662148782b7751c62efd256e644c7295c883
Author: Niels Ole Salscheider 
AuthorDate: Mon Dec 21 16:02:11 2015 +0100
Commit: Brad King 
CommitDate: Mon Dec 21 10:23:48 2015 -0500

QtDialog: Add option to control XDG file install destination

Create a `CMAKE_XDGDATA_DIR` option and add a corresponding flag to the
`bootstrap` script.  This is needed for multiarch layouts where the
prefix is `/usr/${host}` but where architecture-independent files (like
the XDG-specific ones) are installed to `/usr/share`.

diff --git a/Source/CMakeInstallDestinations.cmake 
b/Source/CMakeInstallDestinations.cmake
index 99c86ca..2f9d95a 100644
--- a/Source/CMakeInstallDestinations.cmake
+++ b/Source/CMakeInstallDestinations.cmake
@@ -3,24 +3,29 @@ if(BEOS)
   set(CMAKE_DATA_DIR_DEFAULT 
"share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # HAIKU
   set(CMAKE_MAN_DIR_DEFAULT "documentation/man") # HAIKU
   set(CMAKE_DOC_DIR_DEFAULT 
"documentation/doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # HAIKU
+  set(CMAKE_XDGDATA_DIR_DEFAULT "share") # HAIKU
 elseif(CYGWIN)
   set(CMAKE_DATA_DIR_DEFAULT "share/cmake-${CMake_VERSION}") # CYGWIN
   set(CMAKE_DOC_DIR_DEFAULT "share/doc/cmake-${CMake_VERSION}") # CYGWIN
   set(CMAKE_MAN_DIR_DEFAULT "share/man") # CYGWIN
+  set(CMAKE_XDGDATA_DIR_DEFAULT "share") # CYGWIN
 else()
   set(CMAKE_DATA_DIR_DEFAULT 
"share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # OTHER
   set(CMAKE_DOC_DIR_DEFAULT 
"doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # OTHER
   set(CMAKE_MAN_DIR_DEFAULT "man") # OTHER
+  set(CMAKE_XDGDATA_DIR_DEFAULT "share") # OTHER
 endif()
 
 set(CMAKE_DATA_DIR_DESC "data")
 set(CMAKE_DOC_DIR_DESC "docs")
 set(CMAKE_MAN_DIR_DESC "man pages")
+set(CMAKE_XDGDATA_DIR_DESC "XDG specific files")
 
 foreach(v
 CMAKE_DATA_DIR
 CMAKE_DOC_DIR
 CMAKE_MAN_DIR
+CMAKE_XDGDATA_DIR
 )
   # Populate the cache with empty values so we know when the user sets them.
   set(${v} "" CACHE STRING "")
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 9161ad3..f17de5d 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -193,7 +193,7 @@ if(UNIX AND NOT APPLE)
   foreach (size IN ITEMS 32 128)
 install(
   FILES   "${CMAKE_CURRENT_SOURCE_DIR}/CMakeSetup${size}.png"
-  DESTINATION "share/icons/hicolor/${size}x${size}/apps"
+  DESTINATION "${CMAKE_XDGDATA_DIR}/icons/hicolor/${size}x${size}/apps"
   ${COMPONENT}
   RENAME  "CMakeSetup.png")
   endforeach ()
@@ -201,10 +201,10 @@ if(UNIX AND NOT APPLE)
   # install a desktop file so CMake appears in the application start menu
   # with an icon
   install(FILES CMake.desktop
-DESTINATION share/applications
+DESTINATION "${CMAKE_XDGDATA_DIR}/applications"
 ${COMPONENT})
   install(FILES cmakecache.xml
-DESTINATION share/mime/packages
+DESTINATION "${CMAKE_XDGDATA_DIR}/mime/packages"
 ${COMPONENT})
 endif()
 
diff --git a/bootstrap b/bootstrap
index b2421a1..97e85bf 100755
--- a/bootstrap
+++ b/bootstrap
@@ -63,9 +63,11 @@ cmake_copyright="`grep '^Copyright .* Kitware' 
"${cmake_source_dir}/Copyright.tx
 cmake_data_dir_keyword="OTHER"
 cmake_doc_dir_keyword="OTHER"
 cmake_man_dir_keyword="OTHER"
+cmake_xdgdata_dir_keyword="OTHER"
 cmake_data_dir=""
 cmake_doc_dir=""
 cmake_man_dir=""
+cmake_xdgdata_dir=""
 cmake_init_file=""
 cmake_bootstrap_system_libs=""
 cmake_bootstrap_qt_gui=""
@@ -214,6 +216,7 @@ fi
 cmake_data_dir_default="`cmake_install_dest_default DATA 
${cmake_data_dir_keyword}`"
 cmake_doc_dir_default="`cmake_install_dest_default DOC 
${cmake_doc_dir_keyword}`"
 cmake_man_dir_default="`cmake_install_dest_default

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

2015-12-21 Thread Tamás Kenéz

Jake,
I've read the older edition. Yes, I also think it could be written better
and most of the information is available online. Still, it provided me with
authorative information, concentrated into a single book, (as opposed to be
scattered over the internet). It really helped me to lay down the
foundations of my CMake knowledge.
Tamas

On Friday, December 18, 2015, DJ  wrote:

> I have only very recently encountered the need to use cmake. It seems this
> need came all at once out of the blue.
>
> It appears to me that there is a general perception that good tutorial
> material is in short supply. I have followed various tutorials that are
> available online and find them less than stellar. I am mostly familiar with
> gnu toolchain stuff. I admit that I am biased here because my own work
> presents zero requirement for cross-platform builds. So far I find cmake
> documentation to be considerably inferior to gnu documentation, but that's
> just me.
>
> This all led me to consider purchasing the book Mastering CMake. However,
> reviews on Amazon are generally very critical of the book. It is indeed
> expensive. Should I bother to shell out for it, or do others here share
> this negative evaluation of it? I don't want to waste my money.
>
> Best,
>
> - Jake -
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://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] still having rpath problems on osx

Re: [CMake] Tests with assert and Release build type

[cmake-developers] [CMake 0015891]: CMake extracts non-standard filenames incorrectly from tarballs

Re: [CMake] Tests with assert and Release build type

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

[Cmake-commits] CMake branch, next, updated. v3.4.1-1800-gddbacc2

[Cmake-commits] CMake branch, master, updated. v3.4.1-746-ga53e016

Re: [cmake-developers] Can't find correct openssl on Windows

Re: [cmake-developers] [PATCH] QtDialog: Allow to set CMAKE_SHARE_DIR

[CMake] CMake with VS 2015 using Android?

[Cmake-commits] CMake branch, master, updated. v3.4.1-739-g3768a79

[Cmake-commits] CMake branch, next, updated. v3.4.1-1808-ga314171

[Cmake-commits] CMake branch, master, updated. v3.4.1-747-g8a45573

Re: [CMake] CPack and PackageMaker

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

Re: [CMake] How to pass a configuration file to CMake?

[CMake] How to pass a configuration file to CMake?

Re: [CMake] How to pass a configuration file to CMake?

[Cmake-commits] CMake branch, next, updated. v3.4.1-1815-g2aa0380

Re: [CMake] CMake with VS 2015 using Android?

Re: [cmake-developers] CMakeFindDependencyMacro limitations

[cmake-developers] [CMake 0015890]: file(STRINGS ..) doesn't work on single character files.

[cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR

Re: [cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR

Re: [CMake] Generate sources (smartly :-))

[Cmake-commits] CMake branch, next, updated. v3.4.1-1810-gf80b5b2

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

31 matches

Site Navigation

Mail list logo

Footer information