Re: [CMake] GCC: -std=g++14 vs -std=c++14

[Patrick Boettcher]

On Mon, 13 Jun 2016 20:05:23 +0200
Patrick Boettcher  wrote:
> > You also need to correctly set the CXX_EXTENSIONS properties to get
> > a standard standard.  
> 
> Yep, 
> 
>   set(CXX_EXTENSIONS OFF)
> 
> seems to do the trick - thanks.

Well, it is 
  
  set(CMAKE_CXX_EXTENSIONS OFF)

actually. Before the target-definition (add_library or add_executable).


--
Patrick.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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.6.0-rc2-128-g909d51b

[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  909d51bece7d343f32a8f59351aad5c396101a2c (commit)
  from  33f74dc5247328cc5b3d6239c65e869bcc35cd80 (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=909d51bece7d343f32a8f59351aad5c396101a2c
commit 909d51bece7d343f32a8f59351aad5c396101a2c
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Jun 15 00:01:06 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Jun 15 00:01:06 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index fe41ca6..da12fe0 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 6)
-set(CMake_VERSION_PATCH 20160614)
+set(CMake_VERSION_PATCH 20160615)
 #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

[CMake] Finding libxml2 when building llvm/clang

[Edward Diener]

Building llvm/clang from source involves using CMake. I am building 
llvm/clang from source on Windows using CMake 3.5.2. I am not a clang 
developer, just a clang user. Similarly I just use CMake rather than 
understand or write CMakeLists.txt files.


I reported a problem to clang where building a 32-bit version of clang 
succeeds but building a 64-bit version of clang fails with xml link 
errors. I have A 32-bit libxml2 binary in my path from gnuwin32, but not 
a 64-bit binary of libxml2 in my path.


I was told by clang developers that one of the tools which clang builds 
uses xml and libxml2 if it is available, otherwise uses some other 
technology for the tool. The suggestion was that the problem I am 
encountering is that of CMake; that CMake does not recognize that the 
libxml2 which I have is the 32-bit version and instead thinks that it is 
the 64-bit version and therefore attempts erroneously to use it in the 
64-bit build of clang.


Does anybody know what might be happening here ? I do not create the 
CMakeLists.txt files used by llvm/clang so I do not know how the use of 
libxml2 can be optionally specified in them.


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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.6.0-rc2-312-gff2a74b

[Daniel Pfeifer]

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  ff2a74b6fa5c9d13647e61cee90d0699661416c4 (commit)
   via  ed5fa48d50ea0605b47598ff5b1d765548e8d638 (commit)
   via  24ab29b882548d9eceeb20d3ecbc5b9cc918bb7c (commit)
   via  ab8b77dd33e9a13551af402b2cf7ee3aaa5486b8 (commit)
   via  eb79fa726090410dbfceb64e29604320cc65d92f (commit)
   via  33f74dc5247328cc5b3d6239c65e869bcc35cd80 (commit)
  from  6efb9214e46763a2a731938e3948fc8751f51167 (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=ff2a74b6fa5c9d13647e61cee90d0699661416c4
commit ff2a74b6fa5c9d13647e61cee90d0699661416c4
Merge: 6efb921 ed5fa48
Author: Daniel Pfeifer 
AuthorDate: Tue Jun 14 17:32:06 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 14 17:32:06 2016 -0400

Merge topic 'cleanup-streams' into next

ed5fa48d cmXMLWriter: use ifstream from KWSys
24ab29b8 Prefer istringstream and ostringstream over stringstream.
ab8b77dd Remove redundant arguments from fstream constructors
eb79fa72 Access std::ios_base with std::ios
33f74dc5 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed5fa48d50ea0605b47598ff5b1d765548e8d638
commit ed5fa48d50ea0605b47598ff5b1d765548e8d638
Author: Daniel Pfeifer 
AuthorDate: Tue Jun 14 23:26:16 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Tue Jun 14 23:26:16 2016 +0200

cmXMLWriter: use ifstream from KWSys

diff --git a/Source/cmXMLWriter.cxx b/Source/cmXMLWriter.cxx
index 98c2680..e2dce93d 100644
--- a/Source/cmXMLWriter.cxx
+++ b/Source/cmXMLWriter.cxx
@@ -14,7 +14,7 @@
 #include "cmXMLSafe.h"
 
 #include 
-#include 
+#include 
 
 cmXMLWriter::cmXMLWriter(std::ostream& output, std::size_t level)
   : Output(output)
@@ -107,7 +107,7 @@ void cmXMLWriter::ProcessingInstruction(const char* target, 
const char* data)
 void cmXMLWriter::FragmentFile(const char* fname)
 {
   this->CloseStartElement();
-  std::ifstream fin(fname, std::ios::in | std::ios::binary);
+  cmsys::ifstream fin(fname, std::ios::in | std::ios::binary);
   this->Output << fin.rdbuf();
 }
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24ab29b882548d9eceeb20d3ecbc5b9cc918bb7c
commit 24ab29b882548d9eceeb20d3ecbc5b9cc918bb7c
Author: Daniel Pfeifer 
AuthorDate: Tue Jun 14 22:37:36 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Tue Jun 14 22:37:36 2016 +0200

Prefer istringstream and ostringstream over stringstream.

Use istringsream for parsing, ostringstream for generation.

diff --git a/Source/CPack/IFW/cmCPackIFWGenerator.cxx 
b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
index b47d46e..accba08 100644
--- a/Source/CPack/IFW/cmCPackIFWGenerator.cxx
+++ b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
@@ -567,7 +567,7 @@ cmCPackIFWRepository* cmCPackIFWGenerator::GetRepository(
 
 void cmCPackIFWGenerator::WriteGeneratedByToStrim(cmXMLWriter& xout)
 {
-  std::stringstream comment;
+  std::ostringstream comment;
   comment << "Generated by CPack " << CMake_VERSION << " IFW generator "
   << "for QtIFW ";
   if (IsVersionLess("2.0")) {
diff --git a/Source/CPack/IFW/cmCPackIFWPackage.cxx 
b/Source/CPack/IFW/cmCPackIFWPackage.cxx
index c44e389..405d668 100644
--- a/Source/CPack/IFW/cmCPackIFWPackage.cxx
+++ b/Source/CPack/IFW/cmCPackIFWPackage.cxx
@@ -422,7 +422,7 @@ void cmCPackIFWPackage::GeneratePackageFile()
   }
   // Write dependencies
   if (!compDepSet.empty()) {
-std::stringstream dependencies;
+std::ostringstream dependencies;
 std::set::iterator it = compDepSet.begin();
 dependencies << it->NameWithCompare();
 ++it;
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 8777296..b5b364d 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -90,7 +90,7 @@ bool cmCPackWIXGenerator::RunCandleCommand(std::string const& 
sourceFile,
 return false;
   }
 
-  std::stringstream command;
+  std::ostringstream command;
   command << QuotePath(executable);
   command << " -nologo";
   command << " -arch " << GetArchitecture();
@@ -115,7 +115,7 @@ bool cmCPackWIXGenerator::RunLightCommand(std::string 
const& objectFiles)
 return false;
   }
 
-  std::stringstream command;
+  std::ostringstream command;
   command << QuotePath(executable);
   command << " -nologo";
   command << " -out " << QuotePath(packageFileNames.at(0));
@@ -254,7 +254,7 @@ bool 

Re: [CMake] CMAKE - troubles finding executables/paths - Windows 7 / MinGW

[Martin Weber]

Yes, I know this [1] thread is old, but it hurts me, too.

This is what I found:
The mingw32 installer (mingw32-get, IIRC) no longer places a key in the 
windows registry.

So if anyone installed mingw32 in a directory other than c:/MinGW/,
cmake will not find it.
After adding the bin directory of the mingw install location to %PATH%, cmake 
will detect mingw32-make, but it will complain saying 'the compiler is not 
able to build a single program'. 
This happens because cc1.exe (which is *not* in the bin directory) cannot find 
the DLLs located in the bin directory. You have to manually copy the DLLs to 
the directory containing cc1.exe.

Maybe someone finds this useful.

Martin

[1] https://cmake.org/pipermail/cmake/2011-May/044637.html

-- 
Cd wrttn wtht vwls s mch trsr.


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] codeblocks generator: Fix include directories being in unexpected order

[Tobias Hunger]

On Di, 2016-06-14 at 15:21 +, Tobias Hunger wrote:
> Hello,
> 
> https://github.com/hunger/CMake/commit/a87e306fd03e7fae7409b16e4e586083822c6fe
> 8

https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc28661e3

Is the same thing updated based on suggestions from Stephen.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] Questions about coding conventions

[clinton]

- On Jun 14, 2016, at 8:09 AM, Daniel Pfeifer dan...@pfeifer-mail.de wrote:

> On Tue, Jun 14, 2016 at 3:14 PM, Brad King  wrote:
>> On 06/13/2016 10:16 AM, Brad King wrote:
 Can't `std::ifstream` and `std::ofstream` be used directly? It seams
 that kwsys does some workarounds
>>>
>>> Yes, std::{o,f}stream can be used directly.
>>
>> On second thought, std::{i,o}fstream should not be used to open files.
>> The cmsys::{i,o}fstream interfaces are not about compatibility, they
>> are about opening files on Windows using the wide character APIs by
>> converting from UTF-8 to UCS-2.
> 
> I see.
> 
> There are a few uses of std::{i,o}fstream. I guess we should migrate
> them all to kwsys.

Yes.  Thanks.
cmsys::{i,o}fstream is to support additional filenames on Windows by not using 
obsolete ANSI apis.

Clint
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] codeblocks generator: Fix include directories being in unexpected order

[Tobias Hunger]

Hello,

https://github.com/hunger/CMake/commit/a87e306fd03e7fae7409b16e4e586083822c6fe8

has a fix to not put include directories into random order while trying to make
them unique.

Would that be applicable for the next release?

All Tests pass, with or without the patch.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] Toward a more deterministic ninja generator

[Nicolas Desprès]

Hi,

While working on something else I wrote this patch:
https://github.com/nicolasdespres/CMake/commit/59e4e62ba014c6fcd4519b57b621d9434f99ff19

It makes the ninja generator more deterministic by sorting the build edge's
inputs/outputs. It does not introduce any regression on my macbookpro.

This could help to fix issue #15968.

Regards,

-- 
Nicolas Desprès
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] Provide configuration settings for users

[Elizabeth A. Fischer]

Cedric,

I would highly recommend an auto-builder such as Spack as a good way to
have a system that automatically downloads and installs dependencies for
your software.  My software requires about 50 dependencies (once recursive
dependencies are counted), and I've successfully used Spack to have others
install it.  See instructions for installing my software stack using Spack
at:

   https://github.com/citibeth/icebin

(Most of these instructions are for bootstrapping Spack on old machines,
and not directly for my particular software).

This approach is a lot easier for you and your users, and more flexible to
boot:

 1. You don't have to deal with advanced/esoteric features like
ExternalProject, CMakeList templates, etc.

 2. It doesn't matter what build system your dependencies were written
with.  (I've heard of people writing CMake builds for all their
dependencies.  As much as I like CMake, that seems like a painful way to
proceed).

 3. Consider what would happen if every project used ExternalProject for
its dependencies: we'd be unable to link projects together as soon as they
share a sub-dependency, since every project would be building its own.  You
really want to build a coherent software DAG (Directed Acyclic Graph) at a
level ABOVE the single-project level, in order to avoid duplicate /
conflicting packages in your build.  For that reason, the project-building
level (CMake) is fundamentally the wrong place to do this.  It should be
done by auto-builders on top of the project level (Spack, EasyBuild,
MacPorts, Gentoo Portage, etc).

-- Elizabeth



On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet 
wrote:

>
> Hello,
>
> is there a native way to provide configuration settings for the users of a
> software?
>
> For example, I develop a software which depends on several 3rd party
> libraries which are automatically downloaded and installed with the
> ExternalProject module.
> My CMake configuration scripts are written so as to handle these 3rd party
> libraries.
> During installation of the software, header files and libraries are copied
> to the destination directory but (of course) without their 3rd party
> dependencies.
>
> Therefore, if a user wants to use my software, he has to handle these 3rd
> party libraries during compilation and linking steps.
> Depending on the skills of the user, it may be difficult to achieve it.
>
> I would like to know if there exists a native way of providing sufficient
> configuration information so that users do not have to handle these
> libraries.
> For the moment, I provide a CMakeLists template but I wonder if it's the
> best possible solution.
>
> Best regards,
>
> Cédric Doucet
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/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] Questions about coding conventions

[Daniel Pfeifer]

On Tue, Jun 14, 2016 at 3:14 PM, Brad King  wrote:
> On 06/13/2016 10:16 AM, Brad King wrote:
>>> Can't `std::ifstream` and `std::ofstream` be used directly? It seams
>>> that kwsys does some workarounds
>>
>> Yes, std::{o,f}stream can be used directly.
>
> On second thought, std::{i,o}fstream should not be used to open files.
> The cmsys::{i,o}fstream interfaces are not about compatibility, they
> are about opening files on Windows using the wide character APIs by
> converting from UTF-8 to UCS-2.

I see.

There are a few uses of std::{i,o}fstream. I guess we should migrate
them all to kwsys.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] Installation of imported targets

[Brad King]

On 06/13/2016 06:12 PM, Elie Roudninski wrote:
> Everything works fine except when you need to install the imported target.
> You can't use the regular:
> install(TARGETS myimportedlib LIBRARY DESTINATION lib)
> It is not permitted for imported targets. At the moment, i usually use: 
> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/path/to/myimportedlib.so 
> DESTINATION lib)
> to install it.

The main problem is that as the importer of the target we don't necessarily
have enough information to properly install it.  Shared libraries and 
executables
often need RPATH updates or other (platform-specific) modifications during
installation.  Multiple files need to be installed to bring along import 
libraries
or soname symlinks.  Only the original build system that produces a file knows
how it should be properly installed.  Therefore installing imported targets is
not a well-defined concept.

> The problem now, is when you need to export the library ... At the moment,
> you just can't do it properly.

This is because imported targets are not meant to be exported.  You got them
from some other project, so your clients can get them directly from that other
project too.  Your package configuration file is responsible for providing the
imported targets on which your exported targets depend so that a client sees
all of them after using find_package(YourProject).  It finds the dependency
and loads its imported targets, and then loads your imported targets.  There
is no need for "re-export" of imported targets.

All this was designed with the idea that external dependencies are installed
separately.  Using ExternalProject to extend your build system and then import
a target is more of a trick than a first-class feature of CMake.  Instead we
typically have a "superbuild" project that has nothing but ExternalProject_Add
calls to build all the source trees in order and share a common installation
prefix.  Then deployment is a matter of packaging what is left behind in
that prefix after all the builds are done.

-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-commits] CMake branch, next, updated. v3.6.0-rc2-306-g6efb921

[Chuck Atkins]

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  6efb9214e46763a2a731938e3948fc8751f51167 (commit)
   via  90d114ed8c724ca49fa02444dd59d06fd9806f3b (commit)
  from  68b0ed4e365c77d1eb2109b17fa11d358f1a575b (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=6efb9214e46763a2a731938e3948fc8751f51167
commit 6efb9214e46763a2a731938e3948fc8751f51167
Merge: 68b0ed4 90d114e
Author: Chuck Atkins 
AuthorDate: Tue Jun 14 09:56:45 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 14 09:56:45 2016 -0400

Merge topic 'findcuda-use-correct-runtime-for-required' into next

90d114ed FindCUDA: Use the correct runtime in REQUIRED_VARS check


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90d114ed8c724ca49fa02444dd59d06fd9806f3b
commit 90d114ed8c724ca49fa02444dd59d06fd9806f3b
Author: Chuck Atkins 
AuthorDate: Mon Jun 13 09:39:15 2016 -0400
Commit: Chuck Atkins 
CommitDate: Tue Jun 14 09:55:35 2016 -0400

FindCUDA: Use the correct runtime in REQUIRED_VARS check

When enabling the CUDA static runtime, the current module always uses
the shared runtime in the REQUIRED_VARS check.  This change should
select the correct runtime to be checked for as required based on the
CUDA_USE_STATIC_CUDA_RUNTIME option.

Fixes #16096

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 86f89d8..81fc7a8 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -787,8 +787,10 @@ endif()
 if(CUDA_cudart_static_LIBRARY)
   # Set whether to use the static cuda runtime.
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" ON)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_cudart_static_LIBRARY)
 else()
   option(CUDA_USE_STATIC_CUDA_RUNTIME "Use the static version of the CUDA 
runtime library if available" OFF)
+  set(CUDA_CUDART_LIBRARY_VAR CUDA_CUDART_LIBRARY)
 endif()
 
 if(CUDA_USE_STATIC_CUDA_RUNTIME)
@@ -1003,7 +1005,7 @@ find_package_handle_standard_args(CUDA
 CUDA_TOOLKIT_ROOT_DIR
 CUDA_NVCC_EXECUTABLE
 CUDA_INCLUDE_DIRS
-CUDA_CUDART_LIBRARY
+${CUDA_CUDART_LIBRARY_VAR}
   VERSION_VAR
 CUDA_VERSION
   )

---

Summary of changes:


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

Re: [CMake] Provide configuration settings for users

[Chuck Atkins]

Hi Cedric,

It sounds like creating a package config file is exactly what you need.
When installed, a user will be able to consume your project with
"find_package(Foo)".  That will locate and read the package config file
which will create an imported target Foo::Foo.  This imported target will
cary with it all of the necessary link dependency information.

See https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html for more
details.

- Chuck

On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet 
wrote:

>
> Hello,
>
> is there a native way to provide configuration settings for the users of a
> software?
>
> For example, I develop a software which depends on several 3rd party
> libraries which are automatically downloaded and installed with the
> ExternalProject module.
> My CMake configuration scripts are written so as to handle these 3rd party
> libraries.
> During installation of the software, header files and libraries are copied
> to the destination directory but (of course) without their 3rd party
> dependencies.
>
> Therefore, if a user wants to use my software, he has to handle these 3rd
> party libraries during compilation and linking steps.
> Depending on the skills of the user, it may be difficult to achieve it.
>
> I would like to know if there exists a native way of providing sufficient
> configuration information so that users do not have to handle these
> libraries.
> For the moment, I provide a CMakeLists template but I wonder if it's the
> best possible solution.
>
> Best regards,
>
> Cédric Doucet
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/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] Questions about coding conventions

[Brad King]

On 06/13/2016 10:16 AM, Brad King wrote:
>> Can't `std::ifstream` and `std::ofstream` be used directly? It seams
>> that kwsys does some workarounds
> 
> Yes, std::{o,f}stream can be used directly.

On second thought, std::{i,o}fstream should not be used to open files.
The cmsys::{i,o}fstream interfaces are not about compatibility, they
are about opening files on Windows using the wide character APIs by
converting from UTF-8 to UCS-2.  Sorry for the confusion.

I've reverted the std-fstream topic for now.

-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-commits] CMake branch, next, updated. v3.6.0-rc2-304-g68b0ed4

[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  68b0ed4e365c77d1eb2109b17fa11d358f1a575b (commit)
   via  853f85da0ad03271cd0a3a1bdbfc0aa7d2910b3f (commit)
  from  41ecb26fc477d763a455738f0ab0485770149d7c (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=68b0ed4e365c77d1eb2109b17fa11d358f1a575b
commit 68b0ed4e365c77d1eb2109b17fa11d358f1a575b
Merge: 41ecb26 853f85d
Author: Brad King 
AuthorDate: Tue Jun 14 09:13:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 14 09:13:59 2016 -0400

Merge topic 'std-fstream' into next

853f85da Revert topic 'std-fstream'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853f85da0ad03271cd0a3a1bdbfc0aa7d2910b3f
commit 853f85da0ad03271cd0a3a1bdbfc0aa7d2910b3f
Author: Brad King 
AuthorDate: Tue Jun 14 09:13:15 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 14 09:13:40 2016 -0400

Revert topic 'std-fstream'

diff --git a/Source/CPack/OSXScriptLauncher.cxx 
b/Source/CPack/OSXScriptLauncher.cxx
index 1b1457c..a233e76 100644
--- a/Source/CPack/OSXScriptLauncher.cxx
+++ b/Source/CPack/OSXScriptLauncher.cxx
@@ -28,7 +28,7 @@ int main(int argc, char* argv[])
 {
   // if ( cmsys::SystemTools::FileExists(
   std::string cwd = cmsys::SystemTools::GetCurrentWorkingDirectory();
-  std::ofstream ofs("/tmp/output.txt");
+  cmsys::ofstream ofs("/tmp/output.txt");
 
   CFStringRef fileName;
   CFBundleRef appBundle;
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 9b240d8..8777296 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -66,7 +66,7 @@ bool cmCPackWIXGenerator::RunWiXCommand(std::string const& 
command)
 , , 0,
 cmSystemTools::OUTPUT_NONE);
 
-  std::ofstream logFile(logFileName.c_str(), std::ios::app);
+  cmsys::ofstream logFile(logFileName.c_str(), std::ios::app);
   logFile << command << std::endl;
   logFile << output;
   logFile.close();
@@ -796,7 +796,7 @@ bool cmCPackWIXGenerator::CreateLicenseFile()
   } else if (extension == ".txt") {
 cmWIXRichTextFormatWriter rtfWriter(licenseDestinationFilename);
 
-std::ifstream licenseSource(licenseSourceFilename.c_str());
+cmsys::ifstream licenseSource(licenseSourceFilename.c_str());
 
 std::string line;
 while (std::getline(licenseSource, line)) {
diff --git a/Source/CPack/WiX/cmWIXRichTextFormatWriter.h 
b/Source/CPack/WiX/cmWIXRichTextFormatWriter.h
index 096f6ce..acf1fa6 100644
--- a/Source/CPack/WiX/cmWIXRichTextFormatWriter.h
+++ b/Source/CPack/WiX/cmWIXRichTextFormatWriter.h
@@ -48,7 +48,7 @@ private:
 
   void EmitInvalidCodepoint(int c);
 
-  std::ofstream File;
+  cmsys::ofstream File;
 };
 
 #endif
diff --git a/Source/CPack/WiX/cmWIXSourceWriter.h 
b/Source/CPack/WiX/cmWIXSourceWriter.h
index 781d813..4efc026 100644
--- a/Source/CPack/WiX/cmWIXSourceWriter.h
+++ b/Source/CPack/WiX/cmWIXSourceWriter.h
@@ -63,7 +63,7 @@ private:
 
   static std::string EscapeAttributeValue(std::string const& value);
 
-  std::ofstream File;
+  cmsys::ofstream File;
 
   State State;
 
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index b358778..f4379c1 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -230,12 +230,12 @@ bool 
cmCPackDragNDropGenerator::CopyFile(std::ostringstream& source,
 bool cmCPackDragNDropGenerator::CreateEmptyFile(std::ostringstream& target,
 size_t size)
 {
-  std::ofstream fout(target.str().c_str(), std::ios::out | std::ios::binary);
+  cmsys::ofstream fout(target.str().c_str(), std::ios::out | std::ios::binary);
   if (!fout) {
 return false;
   } else {
 // Seek to desired size - 1 byte
-fout.seekp(size - 1, std::ios::beg);
+fout.seekp(size - 1, std::ios_base::beg);
 char byte = 0;
 // Write one byte to ensure file grows
 fout.write(, 1);
@@ -784,7 +784,7 @@ bool cmCPackDragNDropGenerator::WriteLicense(
   std::string actual_license = !licenseFile.empty()
 ? licenseFile
 : (slaDirectory + "/" + licenseLanguage + ".license.txt");
-  std::ifstream license_ifs;
+  cmsys::ifstream license_ifs;
   license_ifs.open(actual_license.c_str());
   if (license_ifs.is_open()) {
 while (license_ifs.good()) {
@@ -816,7 +816,7 @@ bool 

[CMake] Provide configuration settings for users

[Cedric Doucet]

Hello, 

is there a native way to provide configuration settings for the users of a 
software? 

For example, I develop a software which depends on several 3rd party libraries 
which are automatically downloaded and installed with the ExternalProject 
module. 
My CMake configuration scripts are written so as to handle these 3rd party 
libraries. 
During installation of the software, header files and libraries are copied to 
the destination directory but (of course) without their 3rd party dependencies. 
Therefore, if a user wants to use my software, he has to handle these 3rd party 
libraries during compilation and linking steps. 
Depending on the skills of the user, it may be difficult to achieve it. 

I would like to know if there exists a native way of providing sufficient 
configuration information so that users do not have to handle these libraries. 
For the moment, I provide a CMakeLists template but I wonder if it's the best 
possible solution. 

Best regards, 

Cédric Doucet 
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] daemon-mode: Infrastructure

[Tobias Hunger]

PS: I think it would make perfect sense to ship the first cmake version with
included daemon-mode with a big, fat warning that the interfaces are not
finalized yet and will change in incompatible ways during the first release
cycle (or maybe two:-).

In my experience you only get the full feedback once the first release is out
and users can test it without building the code themselves. So this would
provide an opportunity to battle-harden all the daemon-mode APIs without
commiting us too early.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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] fixup! Remove redundant arguments from fstream constructors

[Daniel Pfeifer]

This is a fixup for the std-fstream topic.
From 1d52cfe88e98738a1f1172cd1723a07ac579d2eb Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Tue, 14 Jun 2016 09:47:46 +0200
Subject: [PATCH] fixup! Remove redundant arguments from fstream constructors

---
 Tests/AliasTarget/commandgenerator.cpp | 3 +--
 Tests/AliasTarget/targetgenerator.cpp  | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Tests/AliasTarget/commandgenerator.cpp b/Tests/AliasTarget/commandgenerator.cpp
index 57a9887..c4d80a1 100644
--- a/Tests/AliasTarget/commandgenerator.cpp
+++ b/Tests/AliasTarget/commandgenerator.cpp
@@ -5,8 +5,7 @@
 
 int main(int argc, char** argv)
 {
-  std::fstream fout;
-  fout.open("commandoutput.h");
+  std::ofstream fout("commandoutput.h");
   if (!fout)
 return 1;
   fout << "#define COMMANDOUTPUT_DEFINE\n";
diff --git a/Tests/AliasTarget/targetgenerator.cpp b/Tests/AliasTarget/targetgenerator.cpp
index 15cfc89..4de4792 100644
--- a/Tests/AliasTarget/targetgenerator.cpp
+++ b/Tests/AliasTarget/targetgenerator.cpp
@@ -3,8 +3,7 @@
 
 int main(int argc, char** argv)
 {
-  std::fstream fout;
-  fout.open("targetoutput.h");
+  std::ofstream fout("targetoutput.h");
   if (!fout)
 return 1;
   fout << "#define TARGETOUTPUT_DEFINE\n";
-- 
2.8.3

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/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