[Cmake-commits] CMake branch, master, updated. v3.5.2-813-g34d07d7

[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  34d07d7146b167e45f8d158204de049150d9 (commit)
  from  d6754d37d593a0189809dcf98bc4fdf3a609f0a3 (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=34d07d7146b167e45f8d158204de049150d9
commit 34d07d7146b167e45f8d158204de049150d9
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Jun 2 00:01:10 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Jun 2 00:01:10 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index d8920e6..390e408 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 20160601)
+set(CMake_VERSION_PATCH 20160602)
 #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-developers] [CMake 0016134]: CMake crashes at generation stage

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16134 
== 
Reported By:Daniel Levin
Assigned To:
== 
Project:CMake
Issue ID:   16134
Category:   CMake
Reproducibility:always
Severity:   crash
Priority:   high
Status: new
== 
Date Submitted: 2016-06-01 23:58 EDT
Last Modified:  2016-06-01 23:58 EDT
== 
Summary:CMake crashes at generation stage
Description: 
Reproducibility 100% on my personal project using either Makefile or Ninja
generator. Affected all CMake version after 3.4, earlier versions might contains
this issue as well, did not check. Provided fixup patch is for CMake 3.4.0.
Versions 3.5+ have different implementation of the same code, but bug is still
there. Please see attached Git bundle with branch 'bug' inside that contains the
fix.

Copy of the patch message:

cmGeneratorTarget: Fix tracing dependencies in local generator

When looping over the generator targets they might become indirectly
invalidated and recreated from cmGlobalGenerator::CreateGenerationObjects().
Thus targets container cmGeneratorTarget pointers will be deleted,
dereferencing them leads to crashes at generation stage.

To avoid this loop should iterate over cmTarget keys and look for
cmGeneratorTarget pointers directly from Makefile instance each time.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-06-01 23:58 Daniel Levin   New Issue
2016-06-01 23:58 Daniel Levin   File Added: crash.bundle 
==

-- 

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.5.2-819-gddd74ff

[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  ddd74ff94ba85c04382f33e01915350d65464682 (commit)
   via  9c77135bd53cfe4cd60df3ce6a2761ca77521c4e (commit)
  from  9f6fe2f9ba059566b665466fdcb2b0caf6d8e4fc (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=ddd74ff94ba85c04382f33e01915350d65464682
commit ddd74ff94ba85c04382f33e01915350d65464682
Merge: 9f6fe2f 9c77135
Author: Daniel Pfeifer 
AuthorDate: Wed Jun 1 17:39:57 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 17:39:57 2016 -0400

Merge topic 'simplify-boolean-expressions' into next

9c77135b Simplify boolean expressions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c77135bd53cfe4cd60df3ce6a2761ca77521c4e
commit 9c77135bd53cfe4cd60df3ce6a2761ca77521c4e
Author: Daniel Pfeifer 
AuthorDate: Wed Jun 1 23:29:53 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Wed Jun 1 23:29:53 2016 +0200

Simplify boolean expressions

Use clang-tidy's readability-simplify-boolean-expr checker.
After applying the fix-its, revise all changes *very* carefully.
Be aware of false positives and invalid changes.

diff --git a/Source/CPack/IFW/cmCPackIFWRepository.cxx 
b/Source/CPack/IFW/cmCPackIFWRepository.cxx
index b149f81..1838005 100644
--- a/Source/CPack/IFW/cmCPackIFWRepository.cxx
+++ b/Source/CPack/IFW/cmCPackIFWRepository.cxx
@@ -45,16 +45,16 @@ bool cmCPackIFWRepository::IsValid() const
 
   switch (Update) {
 case None:
-  valid = Url.empty() ? false : true;
+  valid = !Url.empty();
   break;
 case Add:
-  valid = Url.empty() ? false : true;
+  valid = !Url.empty();
   break;
 case Remove:
-  valid = Url.empty() ? false : true;
+  valid = !Url.empty();
   break;
 case Replace:
-  valid = (OldUrl.empty() || NewUrl.empty()) ? false : true;
+  valid = !OldUrl.empty() && !NewUrl.empty();
   break;
   }
 
@@ -244,11 +244,7 @@ bool cmCPackIFWRepository::PatchUpdatesXml()
 
   fout.Close();
 
-  if (!cmSystemTools::RenameFile(updatesPatchXml.data(), updatesXml.data())) {
-return false;
-  }
-
-  return true;
+  return cmSystemTools::RenameFile(updatesPatchXml.data(), updatesXml.data());
 }
 
 void cmCPackIFWRepository::WriteRepositoryConfig(cmXMLWriter& xout)
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx 
b/Source/CPack/cmCPackArchiveGenerator.cxx
index 7db20a4..baf6719 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -269,9 +269,5 @@ bool 
cmCPackArchiveGenerator::SupportsComponentInstallation() const
   // The Component installation support should only
   // be activated if explicitly requested by the user
   // (for backward compatibility reason)
-  if (IsOn("CPACK_ARCHIVE_COMPONENT_INSTALL")) {
-return true;
-  } else {
-return false;
-  }
+  return IsOn("CPACK_ARCHIVE_COMPONENT_INSTALL");
 }
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 1ad4152..ddaa483 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -675,11 +675,7 @@ int cmCPackDebGenerator::createDeb()
 
 bool cmCPackDebGenerator::SupportsComponentInstallation() const
 {
-  if (IsOn("CPACK_DEB_COMPONENT_INSTALL")) {
-return true;
-  } else {
-return false;
-  }
+  return IsOn("CPACK_DEB_COMPONENT_INSTALL");
 }
 
 std::string cmCPackDebGenerator::GetComponentInstallDirNameSuffix(
diff --git a/Source/CPack/cmCPackRPMGenerator.cxx 
b/Source/CPack/cmCPackRPMGenerator.cxx
index 9827b70..bc10111 100644
--- a/Source/CPack/cmCPackRPMGenerator.cxx
+++ b/Source/CPack/cmCPackRPMGenerator.cxx
@@ -228,11 +228,7 @@ int cmCPackRPMGenerator::PackageFiles()
 
 bool cmCPackRPMGenerator::SupportsComponentInstallation() const
 {
-  if (IsOn("CPACK_RPM_COMPONENT_INSTALL")) {
-return true;
-  } else {
-return false;
-  }
+  return IsOn("CPACK_RPM_COMPONENT_INSTALL");
 }
 
 std::string cmCPackRPMGenerator::GetComponentInstallDirNameSuffix(
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index 94e1615..425afd9 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -209,11 +209,7 @@ int main(int argc, char const* const* argv)
* should launch cpack using "cpackConfigFile" if it exists
* in the current directory.
*/
-  if ((doc.CheckOptions(argc, argv, "-G")) && !(argc == 1)) {
-help = true;
-  } else {
-help = false;
-  }
+  help = doc.CheckOptions(argc, argv, "-G") && argc != 1;
 
   // 

[CMake] CMake searching for shared libraries in invalid paths

[Mark Thomas via CMake]

Hi cmake users,     Reposting question from stackoverflow 
(http://stackoverflow.com/questions/37449511/cmake-searching-for-shared-libraries-in-invalid-paths)
 since I didn't get a good answer there:
I noticed that the cmake generation step in my project was taking a long time 
and so I ran cmake through strace to figure out the root cause. I found that 
cmake was trying to find internal shared libraries in the wrong locations 
repeatedly, which was causing a lot of unnecessary file system lookups. Here is 
a simple project that illustrates the problem:
    $ ll -R                                                                     
                                                                                
                                                                                
                    .:    total 20K    drwxr-xr-x 2 mark mark 4.0K May 25 16:22 
alpha    drwxr-xr-x 2 mark mark 4.0K May 25 16:22 beta    drwxr-xr-x 2 mark 
mark 4.0K May 25 16:42 build    -rw-r--r-- 1 mark mark  185 May 25 16:20 
CMakeLists.txt    -rw-r--r-- 1 mark mark    0 May 25 16:16 dummy.cc    
drwxr-xr-x 2 mark mark 4.0K May 25 16:22 gamma        ./alpha:    total 4.0K    
-rw-r--r-- 1 mark mark  0 May 25 16:16 alpha.cc    -rw-r--r-- 1 mark mark 69 
May 25 16:20 CMakeLists.txt        ./beta:    total 4.0K    -rw-r--r-- 1 mark 
mark  0 May 25 16:16 beta.cc    -rw-r--r-- 1 mark mark 67 May 25 16:18 
CMakeLists.txt        ./build:    total 0        ./gamma:    total 4.0K    
-rw-r--r-- 1 mark mark 35 May 25 16:19 CMakeLists.txt    -rw-r--r-- 1 mark mark 
 0 May 25 16:16 gamma.cc 
alpha.cc, beta.cc, gamma.cc and dummy.cc are all empty cc files. Here are the 
contents of all the CMakLists.txt files:
Top level CMakeLists.txt
    $ cat CMakeLists.txt     cmake_minimum_required(VERSION 2.8)
    add_subdirectory(alpha)    add_subdirectory(beta)    add_subdirectory(gamma)
    add_executable(dummy_exec dummy.cc)    target_link_libraries(dummy_exec 
alpha)
alpha/CMakeLists.txt 
    $ cat alpha/CMakeLists.txt     add_library(alpha SHARED alpha.cc)    
target_link_libraries(alpha beta)
beta/CMakeLists.txt
    $ cat beta/CMakeLists.txt     add_library(beta SHARED beta.cc)    
target_link_libraries(beta gamma)
gamma/CMakeLists.txt 
    $ cat gamma/CMakeLists.txt     add_library(gamma SHARED gamma.cc)

I invoke cmake (through strace) as follows:
    $ cd build/    $ strace -f -o /tmp/s.out  cmake  ..                         
                                                                                
                                                                                
                     -- The C compiler identification is GNU 4.8.4    -- The 
CXX compiler identification is GNU 4.8.4    -- Check for working C compiler: 
/usr/bin/cc    -- Check for working C compiler: /usr/bin/cc -- works    -- 
Detecting C compiler ABI info    -- Detecting C compiler ABI info - done    -- 
Check for working CXX compiler: /usr/bin/c++    -- Check for working CXX 
compiler: /usr/bin/c++ -- works    -- Detecting CXX compiler ABI info    -- 
Detecting CXX compiler ABI info - done    -- Configuring done    -- Generating 
done    -- Build files have been written to: /home/mark/Downloads/cmake/build

When I inspect the strace output, I see it trying to access libalpha in invalid 
locations (such as under the beta/ and gamma/ sub directories):
    31430 access("/home/mark/Downloads/cmake/build/beta/libalpha.so", R_OK) = 
-1 ENOENT (No such file or directory)    31430 
access("/home/mark/Downloads/cmake/build/gamma/libalpha.so", R_OK) = -1 ENOENT 
(No such file or directory)
Similarly, it is trying to access libbeta and libgamma in invalid locations:
    31430 access("/home/mark/Downloads/cmake/build/alpha/libbeta.so", R_OK) = 
-1 ENOENT (No such file or directory)    31430 
access("/home/mark/Downloads/cmake/build/gamma/libbeta.so", R_OK) = -1 ENOENT 
(No such file or directory)
    31430 access("/home/mark/Downloads/cmake/build/alpha/libgamma.so", R_OK) = 
-1 ENOENT (No such file or directory)    31430 
access("/home/mark/Downloads/cmake/build/beta/libgamma.so", R_OK) = -1 ENOENT 
(No such file or directory)
For a large project with many shared libraries and many dependencies, these 
invalid lookups add up and seem to be causing big delays at the makefile 
generation step. Any idea on why this is happening and how I could prevent 
cmake from searching in these invalid paths ? 
thanksmark
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to 

Re: [CMake] add_custom_command, POST_BUILD

[Magnus Therning]

Vladimir Chebotarev  writes:

> Hi there.
>
> At the moment one can add a command executing after a build of a target
> using:
> add_custom_command(... POST_BUILD...)
>
> However if the command have a dependencies which build after the target,
> there is practically no way to specify it.
>
> Simple case: we have a library and tests for it. E.g. I want them to run in
> POST_BUILD of a library. But, tests already depends on the library so I
> can't make them built before it.
>
> There are few possible solutions to that:
> 1) add possibility to set dependencies for add_custom_command in POST_BUILD
> mode;
> 2) add possibility to populate list of targets if we have specified ones in
> list.
>
> Or maybe correct me if I miss something.

Have you not simply missed add_test()? ;)

What's the reason for wanting the tests to run post-build, rather than
on `make test`?

/M

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

A system is composed of components: a component is something you
understand.
 — Professor Howard Aiken


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] Topic "add-opencl-imported-target" good to merge?

[Matthäus G . Chajdas]

Hi Brad,

done - I had to squash and force push once more, because I used the
wrong author in the first commit.

Everything is now in one commit here:
https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4

Thanks for the timely feedback!

Cheers,
  Matthäus

Am 01.06.2016 um 20:22 schrieb Brad King:
> On 06/01/2016 02:15 PM, Matthäus G. Chajdas wrote:
>> Hopefully done
> 
> The revised history looks good.  The change itself looks good.
> 
> Please also add a `Help/release/dev/FindOpenCL-imported-target.rst`
> file with a release note for the feature.  Look at other files
> in that directory for a sample.  See Help/release/*.rst for other
> examples.
> 
> As part of the modernization of find modules we're also trying
> to add better testing for them.  Please see Tests/FindPNG and the
> CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct
> a similar test for the FindOpenCL module.
> 
> 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

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Brad King]

On 06/01/2016 02:15 PM, Matthäus G. Chajdas wrote:
> Hopefully done

The revised history looks good.  The change itself looks good.

Please also add a `Help/release/dev/FindOpenCL-imported-target.rst`
file with a release note for the feature.  Look at other files
in that directory for a sample.  See Help/release/*.rst for other
examples.

As part of the modernization of find modules we're also trying
to add better testing for them.  Please see Tests/FindPNG and the
CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct
a similar test for the FindOpenCL module.

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

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Matthäus G . Chajdas]

Hopefully done - I'm not the biggest git expert but the history looks
like I'd expect it to look like :)

Cheers,
  Matthäus

Am 01.06.2016 um 19:57 schrieb Brad King:
> On 06/01/2016 01:53 PM, Matthäus G. Chajdas wrote:
>> updated to latest master and pushed again (I merged latest master into
>> this - is that fine or does it have to be a rebase? In that case I'll redo.)
> 
> Please rebase and force push.
> 
> 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

Re: [cmake-developers] [PATCH] fix issue #0016076 Add a --bindir option to bootstrap and use it to install cmake in custom directory

[Brad King]

On 05/30/2016 10:50 AM, BUNEL Nicolas wrote:
> Here, the new patch

Thanks.

I've applied the patches, squashed, and made some minor tweaks.
It has been merged to 'next' for testing:

 Add option to control 'bin' directory of CMake's own installation (#16076)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18bfbc97

Please try out that version.

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

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Esch Nigma]

I tried it out just now.

I pulled and installed a couple 5.x packages  from the Arch archive:
https://archive.archlinux.org/packages/l/

The packages:
gcc-libs-multilib-5.3.0-4-x86_64.pkg.tar.xz
gcc-multilib-5.3.0-4-x86_64.pkg.tar.xz
lib32-gcc-libs-5.3.0-4-x86_64.p

The downgrade didn't change anything for my Hello World program.

For the project I'm actively working on, it broke everything, since C++11 is no 
longer 
recognized.


On my system I had to pull the 'multilib' versions, as this is what my system 
seems to be 
using. If requested, I can try to switch to normal gcc to test that out.


Interesting.  It seems CMake is having trouble identifying GCC in 6.1.1.  Do 
you have a 5.x 
compiler available?  If so does it work with that?  That would help narrow it 
down to a gcc6 
issue vs something about how Manjaro packages compilers.




- Chuck




On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma  
wrote:


The standard choice is c++
 
[eschnigma@manjaro ~]$ c++ --version c++ (GCC) 6.1.1 20160501 Copyright (C) 
2016 Free 
Software Foundation, Inc. This is free software; see the source for copying 
conditions.  
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


But I've tried enforcing g++ as such:
 
-DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:STRING=/usr/
bin/g++
 
And that has the same results.
 
Version:
 
[eschnigma@manjaro ~]$ g++ --version g++ (GCC) 6.1.1 20160501 Copyright (C) 
2016 Free 
Software Foundation, Inc. This is free software; see the source for copying 
conditions.  
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.



On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote:


   [eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" 



This is definitely the reason for no debug symbols.  If the compiler is unknown 
then 
CMake won't know the right flags to pass to generate debug info.  The more 
important 
question though is why the compiler can't be identified.  What compiler is 
being used?  
Can check with /usr/bin/c++ --version ?










[1] mailto:eschni...@openmailbox.org
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Brad King]

On 06/01/2016 01:53 PM, Matthäus G. Chajdas wrote:
> updated to latest master and pushed again (I merged latest master into
> this - is that fine or does it have to be a rebase? In that case I'll redo.)

Please rebase and force push.

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

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Matthäus G . Chajdas]

Hi Brad,

updated to latest master and pushed again (I merged latest master into
this - is that fine or does it have to be a rebase? In that case I'll redo.)

Cheers,
  Matthäus

Am 01.06.2016 um 17:18 schrieb Brad King:
> On 05/31/2016 03:17 PM, Matthäus G. Chajdas wrote:
>> I've just pushed "add-opencl-imported-target" which adds an imported
>> target to FindOpenCL. The whole change is rather small:
>>
>> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71
>>
>> Good to merge this to next for testing?
> 
> Please rebase on 'master' now that post-3.6 development is open.
> 
> 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-commits] CMake branch, next, updated. v3.5.2-817-g9f6fe2f

[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  9f6fe2f9ba059566b665466fdcb2b0caf6d8e4fc (commit)
   via  18bfbc972fd3daf3e973f80072c4de09ec7e852b (commit)
  from  36ec325b71c4dcc5c65ae3c44c43b75efdf1500c (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=9f6fe2f9ba059566b665466fdcb2b0caf6d8e4fc
commit 9f6fe2f9ba059566b665466fdcb2b0caf6d8e4fc
Merge: 36ec325 18bfbc9
Author: Brad King 
AuthorDate: Wed Jun 1 13:51:57 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 13:51:57 2016 -0400

Merge topic 'bin-dir-option' into next

18bfbc97 Add option to control 'bin' directory of CMake's own installation 
(#16076)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18bfbc972fd3daf3e973f80072c4de09ec7e852b
commit 18bfbc972fd3daf3e973f80072c4de09ec7e852b
Author: Nicolas BUNEL 
AuthorDate: Fri May 27 16:03:43 2016 +0200
Commit: Brad King 
CommitDate: Wed Jun 1 11:12:36 2016 -0400

Add option to control 'bin' directory of CMake's own installation (#16076)

Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
Add a `--bindir` option to the `bootstrap` script to set it.

diff --git a/CMakeCPack.cmake b/CMakeCPack.cmake
index 3203279..72fc97c 100644
--- a/CMakeCPack.cmake
+++ b/CMakeCPack.cmake
@@ -166,7 +166,7 @@ if(EXISTS "${CMAKE_ROOT}/Modules/CPack.cmake")
   set(CPACK_PACKAGE_CONTACT "cm...@cmake.org")
 
   if(UNIX)
-set(CPACK_STRIP_FILES "bin/ccmake;bin/cmake;bin/cpack;bin/ctest")
+set(CPACK_STRIP_FILES 
"${CMAKE_BIN_DIR}/ccmake;${CMAKE_BIN_DIR}/cmake;${CMAKE_BIN_DIR}/cpack;${CMAKE_BIN_DIR}/ctest")
 set(CPACK_SOURCE_STRIP_FILES "")
 set(CPACK_PACKAGE_EXECUTABLES "ccmake" "CMake")
   endif()
diff --git a/Source/CMakeInstallDestinations.cmake 
b/Source/CMakeInstallDestinations.cmake
index 2f9d95a..023f6c0 100644
--- a/Source/CMakeInstallDestinations.cmake
+++ b/Source/CMakeInstallDestinations.cmake
@@ -1,27 +1,32 @@
 # Keep formatting here consistent with bootstrap script expectations.
 if(BEOS)
+  set(CMAKE_BIN_DIR_DEFAULT "bin") # HAIKU
   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_BIN_DIR_DEFAULT "bin") # 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_BIN_DIR_DEFAULT "bin") # OTHER
   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_BIN_DIR_DESC "bin")
 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_BIN_DIR
 CMAKE_DATA_DIR
 CMAKE_DOC_DIR
 CMAKE_MAN_DIR
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 3223831..3f00c8e 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -786,7 +786,7 @@ endif()
 
 foreach(_tool ${_tools})
   CMake_OPTIONAL_COMPONENT(${_tool})
-  install(TARGETS ${_tool} DESTINATION bin ${COMPONENT})
+  install(TARGETS ${_tool} DESTINATION ${CMAKE_BIN_DIR} ${COMPONENT})
 endforeach()
 
 install(FILES cmCPluginAPI.h DESTINATION ${CMAKE_DATA_DIR}/include)
diff --git a/Source/CursesDialog/CMakeLists.txt 
b/Source/CursesDialog/CMakeLists.txt
index 93ff425..55599b6 100644
--- a/Source/CursesDialog/CMakeLists.txt
+++ b/Source/CursesDialog/CMakeLists.txt
@@ -48,4 +48,4 @@ else()
 endif()
 
 CMake_OPTIONAL_COMPONENT(ccmake)
-install(TARGETS ccmake DESTINATION bin ${COMPONENT})
+install(TARGETS ccmake DESTINATION ${CMAKE_BIN_DIR} ${COMPONENT})
diff --git a/Source/cmConfigure.cmake.h.in b/Source/cmConfigure.cmake.h.in
index 62128a7..11ff00b 100644
--- a/Source/cmConfigure.cmake.h.in
+++ b/Source/cmConfigure.cmake.h.in
@@ -15,4 +15,5 @@
 #cmakedefine CMAKE_USE_MACH_PARSER
 #cmakedefine CMAKE_ENCODING_UTF8
 #cmakedefine CMake_HAVE_CXX11_UNORDERED_MAP
+#define CMAKE_BIN_DIR 

Re: [CMake] How to use CMAKE_MFC_FLAG for only one on executables?

[David Cole via CMake]

Or just isolate it into its own CMakeLists.txt file in a sub-directory?

On Wed, Jun 1, 2016 at 8:34 AM, Nicholas Braden
 wrote:
> Have you tried unsetting it after adding the executable in question?
> If that doesn't work, is it possible to make the MFX executable be the
> very last executable added in your project?
>
> On Wed, Jun 1, 2016 at 4:50 AM, Zhang Peixuan  
> wrote:
>> Hello All,
>>
>> I want to use CMake to manage my MFC projects, and I added the following
>> code:
>>
>> set( CMAKE_MFC_FLAG 2)
>> add_executable(MFCDemo WIN32
>> ${MFC_RESOURCE_FILES}
>> ${MFC_HEADER_FILES}
>> ${MFC_SOURCE_FILES}
>> )
>> target_compile_definitions(MFCDemo
>> PUBLIC -D_AFXDLL=1
>> PUBLIC -D_UNICODE
>> PUBLIC -DUNICODE
>> )
>>
>> It works.
>> However, my question is that: In addition to the MFC executable, I still
>> have some non-MFC executables,
>> and once CMAKE_MFC_FLAG is set, all the add_executables' property should be
>> "Use MFC in a Shared DLL".
>> In fact, I want only one MFC executable, and make sure all other executables
>> are "Use Standard Windows Library".
>> Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work with
>> set_target_property or other commands.
>>
>> Thanks,
>> Peixuan Zhang
>>
>> --
>>
>> 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

[CMake] RPATH of imported targets

[Philip Pfaffe]

Hi Folks,

I'm linking a target against libraries from an imported package. The
resulting linker invocation then will link against the libs using the full
path, but it will not set the RPATH accordingly. How to I enable RPATH?

I suspect the reason is, that, in the package's Exports.cmake, it sets the
IMPORTED_LOCATION property. My cmake version is 3.2.2.

- Philip
-- 

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] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Chuck Atkins]

Interesting.  It seems CMake is having trouble identifying GCC in 6.1.1.
Do you have a 5.x compiler available?  If so does it work with that?  That
would help narrow it down to a gcc6 issue vs something about how Manjaro
packages compilers.

- Chuck

On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma 
wrote:

> The standard choice is c++
>
>
>
> [eschnigma@manjaro ~]$ c++ --version
> c++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> But I've tried enforcing g++ as such:
>
>
>
> -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
> -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++
>
>
>
> And that has the same results.
>
>
>
> Version:
>
>
>
> [eschnigma@manjaro ~]$ g++ --version
> g++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote:
>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>
>
> This is definitely the reason for no debug symbols.  If the compiler is
> unknown then CMake won't know the right flags to pass to generate debug
> info.  The more important question though is why the compiler can't be
> identified.  What compiler is being used?  Can check with /usr/bin/c++
> --version ?
>
>
>
-- 

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] add_custom_command, POST_BUILD

[Vladimir Chebotarev]

Hi there.

At the moment one can add a command executing after a build of a target
using:
add_custom_command(... POST_BUILD...)

However if the command have a dependencies which build after the target,
there is practically no way to specify it.

Simple case: we have a library and tests for it. E.g. I want them to run in
POST_BUILD of a library. But, tests already depends on the library so I
can't make them built before it.

There are few possible solutions to that:
1) add possibility to set dependencies for add_custom_command in POST_BUILD
mode;
2) add possibility to populate list of targets if we have specified ones in
list.

Or maybe correct me if I miss something.

Kind regards, Vladimir.
-- 

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] Running OSX Bundle via open after creation with CMake/CPack

[Juan Carlos Prieto]

Dear all,

I have generated a bundle for MacOS as follows:

if(APPLE)
set(OS_BUNDLE MACOSX_BUNDLE)
  elseif(WIN32)
set(OS_BUNDLE WIN32)
  endif()

  include_directories(${CMAKE_CURRENT_BINARY_DIR})
  add_executable(FADTTSter ${OS_BUNDLE}
${FADTTS_src}
  )
  target_link_libraries(FADTTSter ${QT_LIBRARIES} ${VTK_LIBRARIES})

#
  # Install the QtTest application, on Apple, the bundle is at the root of
the
  # install tree, and on other platforms it'll go into the bin directory.
  INSTALL(TARGETS FADTTSter
DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
  )

  macro(install_qt5_plugin _qt_plugin_name _qt_plugins_var)
get_target_property(_qt_plugin_path "${_qt_plugin_name}" LOCATION)
if(EXISTS "${_qt_plugin_path}")
  get_filename_component(_qt_plugin_file "${_qt_plugin_path}" NAME)
  get_filename_component(_qt_plugin_type "${_qt_plugin_path}" PATH)
  get_filename_component(_qt_plugin_type "${_qt_plugin_type}" NAME)
  set(_qt_plugin_dest
"${CMAKE_INSTALL_PREFIX}/FADTTSter.app/Contents/PlugIns/${_qt_plugin_type}")
  install(FILES "${_qt_plugin_path}"
DESTINATION "${_qt_plugin_dest}"
COMPONENT Runtime)
  set(${_qt_plugins_var}
"${${_qt_plugins_var}};${_qt_plugin_dest}/${_qt_plugin_file}")
else()
  message(FATAL_ERROR "QT plugin ${_qt_plugin_name} not found")
endif()
  endmacro()
  install_qt5_plugin("Qt5::QCocoaIntegrationPlugin" QT_PLUGINS)


#
  # install a qt.conf file
  # this inserts some cmake code into the install script to write the file
  INSTALL(CODE "
  file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qtconf_dest_dir}/qt.conf\"
\"[Paths]\nPlugins = PlugIns\n\")
  " COMPONENT Runtime)


  install(CODE "
include(BundleUtilities)
fixup_bundle(\"${APPS}\" \"${QT_PLUGINS};\"
\"${QT_LIBRARY_DIR};${QT_BINARY_DIR};\")
   "
COMPONENT Runtime)

The bundle will not run if executed through finder or in command line as
$ open FADTTSter.app.

LSOpenURLsWithRole() failed with error -10810 for the file
/path/to/FADTTSter.app


However, if the executable inside FADTTSter.app/Contents/MacOS/FADTTSter is
executed, the application works fine.

Does any body knows how to solve this issue?

Any help will be greatly appreciated.

Best regards,
-- 

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] Some trivial patches

[Brad King]

On 06/01/2016 05:04 AM, Tobias Hunger wrote:
> Attached you will find a couple of really small changes that add const to a
> method and fix a couple of typos in comments. Trivial stuff.

Thanks.  I've applied the changes:

 cmSearchPath: Fix typo in comment
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e

 cmSourceFileLocation: Fix typo in comment
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64

 cmGlobalGenerator: Make IsMultiConfig() const
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf

> This is mostly to figure out how to contribute code:-)

Good job.  For large changes (e.g. cmake-daemon work) feel free
to publish your branch somewhere and post a link here.  For most
changes please post here.

> Is this the preferred way you want your patches?
> Or do I need to inline them somehow?

Either attachments or inline is fine.

> How can I create an account in the bug tracker?

Unfortunately we had to turn off self-registration due to recent
spam attacks (by human registrants).  While we explore alternatives
it is a manual process. I'll contact you privately.

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

Re: [cmake-developers] CMake execute_process/signal_handler on Unix

[Brad King]

On 06/01/2016 09:04 AM, Yordanov, Dimitar wrote:
> I'm looking into an issue with a CMake build on Linux hanging in a
> select syscall, when using EXECUTE_PROCESS without any additional
> arguments. The subprocess executed is "chmod". The child finishes and
> is marked as a zombie, but CMake did not realize that. The only
> descriptors left open are the one of the signaling pipe.

The code in question uses a well-known idiom to make SIGCHLD
select()able.  It has worked well for years on many platforms.
Are you running inside some kind of virtualization or emulation
environment?

> is the use of a shared variable "kwsysProcesses" in the signal
> handler. I think the usage of non volatile shared objects should be
> avoided in signal handlers and we should just do as less as we
> can in there.

IIRC we suppress signals while updating the shared variables.
CMake also doesn't use threads.

> Why do we need the "(void)pipeStatus;" lines. For debugging?

Some compilers complain we don't use the return value of write().
Therefore we must assign it to a variable.  Then compilers
complain that the variable is assigned a value that is never
used.  The cast suppresses this.

> Why do we need to read from the pipe in the signal handler?

If many signals are received in succession before the select()
wakes up and reads from the pipe then it could fill the pipe
and block in the handler.  We do a non-blocking read to make
sure the pipe never has more than one byte in it.  All we care
about is waking up any blocking select().

BTW, in the long run I'd like to drop this code completely and
move to libuv.  Meanwhile I'd rather not spend too much time
updating the existing implementation.

-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] Topic "add-opencl-imported-target" good to merge?

[Brad King]

On 05/31/2016 03:17 PM, Matthäus G. Chajdas wrote:
> I've just pushed "add-opencl-imported-target" which adds an imported
> target to FindOpenCL. The whole change is rather small:
> 
> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71
> 
> Good to merge this to next for testing?

Please rebase on 'master' now that post-3.6 development is open.

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

Re: [cmake-developers] CMake 3.6 feature freeze on 2016-06-01

[Brad King]

On 05/27/2016 09:02 AM, Brad King wrote:
> I'll announce when post-3.6 development in 'next' is open.

I've branched 'release' for 3.6.  The repository is now open for
post-3.6 development.  Please rebase any open topics on 'master'
before merging to 'next'.

> * Documentation updates
> * Regression fixes
> * Fixes for bugs in features new to 3.6

These types of changes may still be accepted to 'release' during
the 3.6 release candidate cycle.  The 3.6 release is now closed
to new features and general bug fixes.

-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.5.2-815-g36ec325

[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  36ec325b71c4dcc5c65ae3c44c43b75efdf1500c (commit)
   via  2175e5bfa5a2f9f08d6f4f4db652b8f5fae08d79 (commit)
  from  e3d868ac2ff6360e72f95cc9b75ea31f8c75098c (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=36ec325b71c4dcc5c65ae3c44c43b75efdf1500c
commit 36ec325b71c4dcc5c65ae3c44c43b75efdf1500c
Merge: e3d868a 2175e5b
Author: Brad King 
AuthorDate: Wed Jun 1 11:13:20 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 11:13:20 2016 -0400

Merge topic 'minor-cleanups' into next

2175e5bf cmGlobalGenerator: Make IsMultiConfig() const


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bfa5a2f9f08d6f4f4db652b8f5fae08d79
commit 2175e5bfa5a2f9f08d6f4f4db652b8f5fae08d79
Author: Tobias Hunger 
AuthorDate: Tue May 31 13:53:19 2016 +0200
Commit: Brad King 
CommitDate: Wed Jun 1 11:12:58 2016 -0400

cmGlobalGenerator: Make IsMultiConfig() const

diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 2575911..68ff042 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -319,7 +319,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return false; }
+  virtual bool IsMultiConfig() const { return false; }
 
   std::string GetSharedLibFlagsForLanguage(std::string const& lang) const;
 
diff --git a/Source/cmGlobalVisualStudioGenerator.h 
b/Source/cmGlobalVisualStudioGenerator.h
index fb2cdbd..1d456ff 100644
--- a/Source/cmGlobalVisualStudioGenerator.h
+++ b/Source/cmGlobalVisualStudioGenerator.h
@@ -85,7 +85,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return true; }
+  virtual bool IsMultiConfig() const { return true; }
 
   /** Return true if building for Windows CE */
   virtual bool TargetsWindowsCE() const { return false; }
diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 6628cfc..b666594 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3437,7 +3437,7 @@ std::string 
cmGlobalXCodeGenerator::ComputeInfoPListLocation(
 
 // Return true if the generated build tree may contain multiple builds.
 // i.e. "Can I build Debug and Release in the same tree?"
-bool cmGlobalXCodeGenerator::IsMultiConfig()
+bool cmGlobalXCodeGenerator::IsMultiConfig() const
 {
   // Old Xcode 1.5 is single config:
   if (this->XcodeVersion == 15) {
diff --git a/Source/cmGlobalXCodeGenerator.h b/Source/cmGlobalXCodeGenerator.h
index 2ca4c19..0485d4f 100644
--- a/Source/cmGlobalXCodeGenerator.h
+++ b/Source/cmGlobalXCodeGenerator.h
@@ -79,7 +79,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig();
+  virtual bool IsMultiConfig() const;
 
   virtual bool SetGeneratorToolset(std::string const& ts, cmMakefile* mf);
   void AppendFlag(std::string& flags, std::string const& flag);

---

Summary of changes:
 Source/cmGlobalGenerator.h |2 +-
 Source/cmGlobalVisualStudioGenerator.h |2 +-
 Source/cmGlobalXCodeGenerator.cxx  |2 +-
 Source/cmGlobalXCodeGenerator.h|2 +-
 4 files changed, 4 insertions(+), 4 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.5.2-813-ge3d868a

[cmake-commits]

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
  discards  afce47035ef92e0b9b97f6bd2ac3ac395669201c (commit)
  discards  f258626f963518d54ae326471e9560e490f67de7 (commit)
  discards  5e4ac458141630cd1e2dc2cd68becd8ae18f58f5 (commit)
  discards  067dd85ac5d2316209d5349c634a1e8966f3b386 (commit)
  discards  a4e984d5fdb0190c09e04b4138467150fb5ab3d8 (commit)
  discards  b8560be7b0697c90cce259998b5c64bdff039ccd (commit)
  discards  2fdaa209e13e01fff7186d55c1f11901262534b4 (commit)
  discards  285d4d0a88b83e8ea46d315ed6d60c954e26e661 (commit)
  discards  e4bfebdd3f8433b47c265020ab042ebe639765fd (commit)
  discards  7f7326ebd77d9471d0f4c496f7214c118bc8260d (commit)
  discards  d85aa5879305fb82da613028dbda41ac66f08c93 (commit)
  discards  6d7243240c0a1ad807207c6bfd3d6392a658f7ef (commit)
  discards  d975bf0ecbf8e10f745585f82397f07aa161fdf9 (commit)
  discards  e9985b3c34609f1385123768f9bb44ce314d51b8 (commit)
  discards  b13304569f05d26976ab92a973e000a3eda1a3f5 (commit)
  discards  35998cba3771984b9923cb20a71a1abc1928bbcf (commit)
  discards  db87c9ddc46e8da39e282d5f1670584368aafb7e (commit)
  discards  875eb5dddbaf8b18a69dd5edc1f790fec39afee8 (commit)
  discards  6b5bdb6b271a91ac6de709c683c43ecffdb8925c (commit)
  discards  467f8ba80a3038c3b485dd6cc236ef90e5caf6fd (commit)
  discards  10c39437bb51bae38c8c6b72b205fed81dfea561 (commit)
  discards  c731294ce32e05fb4af93e18e4d7ed85bd105041 (commit)
  discards  df332cc0b25d60420b865f6753b39dec94c81b85 (commit)
  discards  55b647a38dad9aa0d955fb438dd88cf7a4f3678a (commit)
  discards  d5f21f98666311bf7b1d71446ef1aa947d773fb0 (commit)
  discards  7af18cb57b3d8d3366c694d57fa7f6888f45e9dc (commit)
  discards  dc857f961d48c6a03eb2b0cafc38b8e69629075b (commit)
  discards  cb027b4aa9ffdcdd1fb148bb0157e54acd00dbbe (commit)
  discards  1d515e50baa2f096f85d3ba97a67592fcfd149f9 (commit)
  discards  dbb18b7656652b8da15d34eb1c1516dcb80bfd17 (commit)
  discards  19ccdd04e8128ff05f9c0beb062aa20b5d2b1742 (commit)
  discards  fe005958b0079c029360b40364c11a96720714fb (commit)
  discards  c7d14b1d26c8456c6135bf5f6b664446c27ef498 (commit)
  discards  cec4fc067dccac3e84f1b82bf0f462520d0df742 (commit)
  discards  19d8ac43004cef7a63c65660b8f5f7d583dee762 (commit)
  discards  3f65c7d72b09cb6bfa4265a568bb9f2469773bd4 (commit)
  discards  03655800e9142fd2e0b8a1db025fb5751a9009b3 (commit)
  discards  e35490d722241d1646b25642b80187b4d658fea9 (commit)
  discards  eda0e5f604dbaeacfe069c043ea9625581411214 (commit)
  discards  4abb02ace6738cfe46ab4696701232fa99b67297 (commit)
  discards  95d23d0699bf39764f6e3f07bc29b7a84a91367a (commit)
  discards  489d882aa966193309a87b92294d206fbeb0b952 (commit)
  discards  47f1e3ecc7ea6802f6894712758292fe354cdbd6 (commit)
  discards  eec9b0f91dac9ac4dc938c624b44ac55b69b3c1c (commit)
  discards  b63eb05e2a0d750c08e78e915993da53e165a350 (commit)
  discards  43d02bf54b86076ffa4ad0bb30b087a51c0b860e (commit)
  discards  b3f40570a5530c01a5d517a779027ae27d1bbf69 (commit)
  discards  201e5242dfc8e3dd1af8bb5ffca76a61226c9195 (commit)
  discards  b5b362e0efe5b5ccb610aa65d5d5c8392d125bb7 (commit)
  discards  75f46e9143a5022405dffb5c1abd10355b4fee09 (commit)
  discards  3565b58ea8f6f54c9c8d3f6187361def72944672 (commit)
  discards  cd153d4e1865c3e1d5ac30277d6a0c15447a7bf8 (commit)
  discards  05d0c64015540df0512f2c5afcc27eb8af590748 (commit)
  discards  093627b6d828009e26d2108f69faf56670340930 (commit)
  discards  2033a966ff73e6e7a6d0a4d52555d565e6a1b88f (commit)
  discards  a639d9b9828a57142d53847fc033fcca59ee4fab (commit)
  discards  c1f682fc1e292bfd6040d19002bd93675d282fa9 (commit)
  discards  873854200c33faffd87406143f60664fea9de6a4 (commit)
  discards  89e30ba9b52013cf8cb923942e205be4a4354784 (commit)
  discards  0a67a1180fc50eade5a753c8c2ec994865084eb7 (commit)
  discards  2f506a44da9ed33a5c87f89b2d48ae389ef85a2e (commit)
  discards  7b6f89791a8ba71d242669ed2496264cbbf2776a (commit)
  discards  0ff7efacd558718f84eac5759560f9e0075fe473 (commit)
  discards  a01cbf97476c413247a826e7f5ff906561822811 (commit)
  discards  1e1ee6b739bde71fccb87f267fb21d74e65fa226 (commit)
  discards  792442356bfad2d6d4a626c8c6e77016ca169cd7 (commit)
  discards  d907aa09c2c5169c456fb07bf0a21c1bba8339b4 (commit)
  discards  d07ce8d49ab9401a0d26452746677cfb94c9c5e9 (commit)
  discards  1186c697351081db7f7e886d00bd94b8311d362b (commit)
  discards  ea38bd083ec543dc0015592f250db27642139f0e (commit)
  discards  b5c7fe7f58cb622f177ca7d09a1ada6a7f35d2db (commit)
  discards  8a17b4a96e19c6ab56266f61913da61e795fb938 (commit)
  discards  af3d76b3eb2981178260916d919b0b07ee8e4d55 (commit)
  discards  674c838e2c93ae2b97ca1ca8defbb1697911d0f3 (commit)
  discards  42f2a139b38ab735a6bb20a3c330e308dd53d8fa (commit)
  discards  5a82892855a34228ebc2315f55400fb8539a440b (commit)
  discards  48d6c426e5a5634f9897ef6ecc6d8e9918fdd405 (commit)
  discards  

Re: [CMake] C header file cross dependency

[Wagner Martin]

> 
> Could you provide a working, stripped down example to show the problem
> provided via github (in an example repo).
> 

I've added a simple test project to 

https://github.com/martinwag/test_cmake/tree/master

Note that this example does not need cross gcc for ARM. It doesn't implement 
any useful functionality!

Regards,
Martin
-- 

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.5.2-1643-gafce470

[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  afce47035ef92e0b9b97f6bd2ac3ac395669201c (commit)
   via  9d81f1b3aaa82d12a3a87067572b3ff5e2b9c4d2 (commit)
  from  f258626f963518d54ae326471e9560e490f67de7 (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=afce47035ef92e0b9b97f6bd2ac3ac395669201c
commit afce47035ef92e0b9b97f6bd2ac3ac395669201c
Merge: f258626 9d81f1b
Author: Brad King 
AuthorDate: Wed Jun 1 10:54:01 2016 -0400
Commit: Brad King 
CommitDate: Wed Jun 1 10:54:01 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


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.5.2-808-g9d81f1b

[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  9d81f1b3aaa82d12a3a87067572b3ff5e2b9c4d2 (commit)
   via  98eafa9b5f346f3695befcc0b52f5206904c8309 (commit)
   via  c5df7483f50876de5f5e50280ff6557e4ba39d15 (commit)
  from  62adedbf5e4fd54fc017cf78a8127875260f84a4 (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=9d81f1b3aaa82d12a3a87067572b3ff5e2b9c4d2
commit 9d81f1b3aaa82d12a3a87067572b3ff5e2b9c4d2
Merge: 62adedb 98eafa9
Author: Brad King 
AuthorDate: Wed Jun 1 10:53:53 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 10:53:53 2016 -0400

Merge topic 'doc-3.6-relnotes'

98eafa9b Help: Organize and revise 3.6 release notes
c5df7483 Help: Consolidate 3.6 release notes


---

Summary of changes:
 Help/release/3.6.rst   |  315 
 ...akePushCheckState-CMAKE_EXTRA_INCLUDE_FILES.rst |5 -
 .../dev/ExternalProject-git-clone-shallow.rst  |5 -
 .../dev/ExternalProject-git-recursive-init.rst |7 -
 Help/release/dev/FindCUDA-cublas_device.rst|4 -
 Help/release/dev/FindGTest-depends.rst |6 -
 Help/release/dev/FindPkgConfig-targets.rst |5 -
 Help/release/dev/FindProtobuf-variable-case.rst|7 -
 Help/release/dev/FindProtobuf-version.rst  |6 -
 ...InstallRequiredSystemLibraries-Windows-UCRT.rst |6 -
 Help/release/dev/add-FindLTTngUST.rst  |5 -
 Help/release/dev/add-bruce-c.rst   |4 -
 Help/release/dev/automoc-diagnostics.rst   |6 -
 Help/release/dev/clang-tidy.rst|7 -
 Help/release/dev/cmake-depend-in-project-only.rst  |6 -
 Help/release/dev/cmake-host-solaris.rst|5 -
 .../release/dev/cpack-deb-autodep-ORIGIN-RPATH.rst |6 -
 Help/release/dev/cpack-deb-imporvements.rst|   32 --
 Help/release/dev/cpack-dmg-no-app-link.rst |6 -
 Help/release/dev/cpack-ifw-updates.rst |6 -
 .../dev/cpack-rpm-adding-dist-to-release-tag.rst   |7 -
 .../dev/cpack-rpm-default-user-and-group.rst   |9 -
 .../dev/cpack-rpm-different-package-names.rst  |9 -
 .../dev/cpack-rpm-external-symlink-handling.rst|5 -
 .../dev/cpack-rpm-upper-cased-components.rst   |   15 -
 Help/release/dev/ctest-run-submodule-sync.rst  |9 -
 .../dev/custom-command-CROSSCOMPILING_EMULATOR.rst |6 -
 Help/release/dev/cygwin-clang.rst  |4 -
 Help/release/dev/deprecate-CMakeForceCompiler.rst  |5 -
 Help/release/dev/doc-standard-libs.rst |6 -
 Help/release/dev/enable-ssl-automatically.rst  |8 -
 Help/release/dev/ep-tls-verify-git.rst |5 -
 Help/release/dev/error-multiple-targets.rst|6 -
 Help/release/dev/external-project-no-extract.rst   |6 -
 Help/release/dev/find-blas-lapack-OpenBLAS.rst |5 -
 .../find-command-prefix-from-PATH-windows-only.rst |   12 -
 .../dev/fix-bison-flex-command-escaping.rst|   12 -
 Help/release/dev/install-EXCLUDE_FROM_ALL.rst  |5 -
 Help/release/dev/intel-compiler-features.rst   |6 -
 Help/release/dev/list-FILTER-command.rst   |5 -
 Help/release/dev/ninja-depfile-system-headers.rst  |5 -
 Help/release/dev/ninja-directory-targets.rst   |7 -
 Help/release/dev/ninja-output-path-prefix.rst  |6 -
 Help/release/dev/remove-vs6-generator.rst  |4 -
 Help/release/dev/remove-vs7.0-generator.rst|5 -
 Help/release/dev/standard-include-directories.rst  |6 -
 Help/release/dev/timeout_after_match.rst   |6 -
 Help/release/dev/try_compile-config-flags.rst  |7 -
 Help/release/dev/try_compile-custom-variables.rst  |7 -
 Help/release/dev/try_compile-target-type.rst   |8 -
 Help/release/dev/unix-timestamps.rst   |6 -
 Help/release/dev/update-osx-release.rst|5 -
 Help/release/dev/vs-clang-cl.rst   |5 -
 Help/release/dev/vs-remote-directory.rst   |7 -
 Help/release/dev/vs-startup-project.rst|6 -
 Help/release/dev/vs-vcxproj-ConfigurationType.rst  |6 -
 Help/release/dev/vs71-deprecate.rst|5 -
 Help/release/index.rst |1 +
 58 files changed, 316 insertions(+), 380 deletions(-)
 create mode 100644 Help/release/3.6.rst
 delete mode 100644 

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Esch Nigma]

The standard choice is c++

[eschnigma@manjaro ~]$ c++ --version c++ (GCC) 6.1.1 20160501 Copyright (C) 
2016 
Free Software Foundation, Inc. This is free software; see the source for 
copying conditions.  
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


But I've tried enforcing g++ as such:

-DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:STRING=/usr/
bin/g++

And that has the same results.

Version:

[eschnigma@manjaro ~]$ g++ --version g++ (GCC) 6.1.1 20160501 Copyright (C) 
2016 
Free Software Foundation, Inc. This is free software; see the source for 
copying conditions.  
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.



On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote:


   [eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" 



This is definitely the reason for no debug symbols.  If the compiler is unknown 
then 
CMake won't know the right flags to pass to generate debug info.  The more 
important 
question though is why the compiler can't be identified.  What compiler is 
being used?  
Can check with /usr/bin/c++ --version ?




-- 

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.5.2-1641-gf258626

[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  f258626f963518d54ae326471e9560e490f67de7 (commit)
   via  98eafa9b5f346f3695befcc0b52f5206904c8309 (commit)
   via  c5df7483f50876de5f5e50280ff6557e4ba39d15 (commit)
  from  5e4ac458141630cd1e2dc2cd68becd8ae18f58f5 (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=f258626f963518d54ae326471e9560e490f67de7
commit f258626f963518d54ae326471e9560e490f67de7
Merge: 5e4ac45 98eafa9
Author: Brad King 
AuthorDate: Wed Jun 1 10:32:37 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 10:32:37 2016 -0400

Merge topic 'doc-3.6-relnotes' into next

98eafa9b Help: Organize and revise 3.6 release notes
c5df7483 Help: Consolidate 3.6 release notes


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98eafa9b5f346f3695befcc0b52f5206904c8309
commit 98eafa9b5f346f3695befcc0b52f5206904c8309
Author: Brad King 
AuthorDate: Wed Jun 1 10:21:30 2016 -0400
Commit: Brad King 
CommitDate: Wed Jun 1 10:30:34 2016 -0400

Help: Organize and revise 3.6 release notes

Add section headers similar to the 3.5 release notes and move each
individual bullet into an appropriate section.  Revise a few bullets.

diff --git a/Help/release/3.6.rst b/Help/release/3.6.rst
index 7c3764a..5c08b39 100644
--- a/Help/release/3.6.rst
+++ b/Help/release/3.6.rst
@@ -7,31 +7,170 @@ CMake 3.6 Release Notes
 
 Changes made since CMake 3.5 include the following.
 
-* Support was added for the Bruce C Compiler with compiler id ``Bruce``.
+New Features
+
 
-* The :module:`FindLTTngUST` module was introduced to find the LTTng-UST
-  library.
+Generators
+--
 
-* :prop_tgt:`AUTOMOC` now diagnoses name collisions when multiple source
-  files in different directories use ``#include `` with the
-  same name (because the generated ``moc_foo.cpp`` files would collide).
+* The :generator:`Ninja` generator learned to produce phony targets
+  of the form ``sub/dir/all`` to drive the build of a subdirectory.
+  This is equivalent to ``cd sub/dir; make all`` with
+  :ref:`Makefile Generators`.
+
+* The :generator:`Ninja` generator now includes system header files in build
+  dependencies to ensure correct re-builds when system packages are updated.
+
+* The :generator:`Visual Studio 14 2015` generator learned to support the
+  Clang/C2 toolsets, e.g. with the ``-T v140_clang_3_7`` option.
+  This feature is experimental.
+
+Commands
+
+
+* The :command:`add_custom_command` and :command:`add_custom_target` commands
+  learned how to use the :prop_tgt:`CROSSCOMPILING_EMULATOR` executable
+  target property.
+
+* The :command:`install` command learned a new ``EXCLUDE_FROM_ALL`` option
+  to leave installation rules out of the default installation.
+
+* The :command:`list` command gained a ``FILTER`` sub-command to filter
+  list elements by regular expression.
+
+* The :command:`string(TIMESTAMP)` and :command:`file(TIMESTAMP)`
+  commands gained support for the ``%s`` placeholder.  This is
+  the number of seconds since the UNIX Epoch.
+
+* The :command:`try_compile` command source file signature now honors
+  configuration-specific flags (e.g. :variable:`CMAKE__FLAGS_DEBUG`)
+  in the generated test project.  Previously only the default such flags
+  for the current toolchain were used.
+
+Variables
+-
+
+* A :variable:`CMAKE_DEPENDS_IN_PROJECT_ONLY` variable was introduced
+  to tell :ref:`Makefile Generators` to limit dependency scanning only
+  to files in the project source and build trees.
+
+* A new :variable:`CMAKE_HOST_SOLARIS` variable was introduced to
+  indicate when CMake is running on an Oracle Solaris host.
+
+* A :variable:`CMAKE__STANDARD_INCLUDE_DIRECTORIES` variable was
+  added for use by toolchain files to specify system include directories
+  to be appended to all compiler command lines.
+
+* The :variable:`CMAKE__STANDARD_LIBRARIES` variable is now documented.
+  It is intended for use by toolchain files to specify system libraries to be
+  added to all linker command lines.
+
+* A :variable:`CMAKE_NINJA_OUTPUT_PATH_PREFIX` variable was introduced
+  to tell the :generator:`Ninja` generator to configure the generated
+  ``build.ninja`` file for use as a ``subninja``.
+
+* A :variable:`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable was
+  added for use by toolchain files to specify platform-specific
+  variables that must be propagated by the :command:`try_compile`
+  command into test projects.
+
+* A 

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Chuck Atkins]

>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>

This is definitely the reason for no debug symbols.  If the compiler is
unknown then CMake won't know the right flags to pass to generate debug
info.  The more important question though is why the compiler can't be
identified.  What compiler is being used?  Can check with /usr/bin/c++
--version ?
-- 

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 execute_process/signal_handler on Unix

[Yordanov, Dimitar]

Hey,

I'm looking into an issue with a CMake build on Linux hanging in a
select syscall, when using EXECUTE_PROCESS without any additional
arguments. The subprocess executed is "chmod". The child finishes and
is marked as a zombie, but CMake did not realize that. The only
descriptors left open are the one of the signaling pipe.

Looking through the code I couldn't see a place, where I could prove
that is directly related to the problem. Nevertheless I have a
question about the signal handler used. The function
kwsysProcessesSignalHandler in ProcessUnix.c. The problem that I see
is the use of a shared variable "kwsysProcesses" in the signal
handler. I think the usage of non volatile shared objects should be
avoided in signal handlers and we should just do as less as we
can in there. So my proposal would be:

1. Use just one SignalPipe for all subprocess
2. In the signal handler just write the one single byte into the w-end
of the pipe
3. Do the rest of the processing in the normal workflow.

A few more questions:
Why do we need the "(void)pipeStatus;" lines. For debugging?
Why do we need to read from the pipe in the signal handler?

Please let me know what is your opinion.

Best wishes
Dimitar
-- 

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.5.2-1638-g5e4ac45

[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  5e4ac458141630cd1e2dc2cd68becd8ae18f58f5 (commit)
   via  62adedbf5e4fd54fc017cf78a8127875260f84a4 (commit)
  from  067dd85ac5d2316209d5349c634a1e8966f3b386 (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=5e4ac458141630cd1e2dc2cd68becd8ae18f58f5
commit 5e4ac458141630cd1e2dc2cd68becd8ae18f58f5
Merge: 067dd85 62adedb
Author: Brad King 
AuthorDate: Wed Jun 1 09:06:08 2016 -0400
Commit: Brad King 
CommitDate: Wed Jun 1 09:06:08 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


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.5.2-805-g62adedb

[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  62adedbf5e4fd54fc017cf78a8127875260f84a4 (commit)
   via  bcf396885112670532bcde2f36d29a5a3c9b1815 (commit)
  from  4062d6d69419fa072bf9394ee1de9cab468113e0 (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=62adedbf5e4fd54fc017cf78a8127875260f84a4
commit 62adedbf5e4fd54fc017cf78a8127875260f84a4
Merge: 4062d6d bcf3968
Author: Brad King 
AuthorDate: Wed Jun 1 09:05:58 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 09:05:58 2016 -0400

Merge topic 'UseJava-fix-typo'

bcf39688 UseJava: Fix grammar error in documentation


---

Summary of changes:
 Modules/UseJava.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-commits] CMake branch, next, updated. v3.5.2-1636-g067dd85

[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  067dd85ac5d2316209d5349c634a1e8966f3b386 (commit)
   via  4062d6d69419fa072bf9394ee1de9cab468113e0 (commit)
   via  7642dde19e096826c22f5305bcb2dc3aa767a4a3 (commit)
   via  adc7fcd0138cd95fb857db31f14620526aa085e4 (commit)
  from  a4e984d5fdb0190c09e04b4138467150fb5ab3d8 (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=067dd85ac5d2316209d5349c634a1e8966f3b386
commit 067dd85ac5d2316209d5349c634a1e8966f3b386
Merge: a4e984d 4062d6d
Author: Brad King 
AuthorDate: Wed Jun 1 09:05:07 2016 -0400
Commit: Brad King 
CommitDate: Wed Jun 1 09:05:07 2016 -0400

Merge branch 'master' into next


---

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-commits] CMake branch, master, updated. v3.5.2-803-g4062d6d

[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  4062d6d69419fa072bf9394ee1de9cab468113e0 (commit)
   via  bd4fef6406786d2d5f9ba4a2b1a7c2da23976740 (commit)
   via  814e774eff4a01e709978736e442c6ed0c0b81c8 (commit)
  from  7642dde19e096826c22f5305bcb2dc3aa767a4a3 (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=4062d6d69419fa072bf9394ee1de9cab468113e0
commit 4062d6d69419fa072bf9394ee1de9cab468113e0
Merge: 7642dde bd4fef6
Author: Brad King 
AuthorDate: Wed Jun 1 09:04:48 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 09:04:48 2016 -0400

Merge topic 'minor-cleanups'

bd4fef64 cmSourceFileLocation: Fix typo in comment
814e774e cmSearchPath: Fix typo in comment


---

Summary of changes:
 Source/cmSearchPath.h |2 +-
 Source/cmSourceFileLocation.h |2 +-
 2 files changed, 2 insertions(+), 2 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.5.2-800-g7642dde

[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  7642dde19e096826c22f5305bcb2dc3aa767a4a3 (commit)
   via  20e55e4be857a2dc5245d14d4fc06b4f0a675038 (commit)
  from  adc7fcd0138cd95fb857db31f14620526aa085e4 (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=7642dde19e096826c22f5305bcb2dc3aa767a4a3
commit 7642dde19e096826c22f5305bcb2dc3aa767a4a3
Merge: adc7fcd 20e55e4
Author: Brad King 
AuthorDate: Wed Jun 1 09:04:44 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 09:04:44 2016 -0400

Merge topic 'cpack-documentation-improvements'

20e55e4b CPackRPM and CPackDeb documentation improvements


---

Summary of changes:
 Modules/CPackDeb.cmake |   71 +
 Modules/CPackRPM.cmake |  207 +---
 2 files changed, 165 insertions(+), 113 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.5.2-1632-ga4e984d

[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  a4e984d5fdb0190c09e04b4138467150fb5ab3d8 (commit)
   via  bd4fef6406786d2d5f9ba4a2b1a7c2da23976740 (commit)
   via  814e774eff4a01e709978736e442c6ed0c0b81c8 (commit)
  from  b8560be7b0697c90cce259998b5c64bdff039ccd (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=a4e984d5fdb0190c09e04b4138467150fb5ab3d8
commit a4e984d5fdb0190c09e04b4138467150fb5ab3d8
Merge: b8560be bd4fef6
Author: Brad King 
AuthorDate: Wed Jun 1 08:39:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 08:39:59 2016 -0400

Merge topic 'minor-cleanups' into next

bd4fef64 cmSourceFileLocation: Fix typo in comment
814e774e cmSearchPath: Fix typo in comment


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef6406786d2d5f9ba4a2b1a7c2da23976740
commit bd4fef6406786d2d5f9ba4a2b1a7c2da23976740
Author: Tobias Hunger 
AuthorDate: Tue May 31 17:15:56 2016 +0200
Commit: Brad King 
CommitDate: Wed Jun 1 08:33:48 2016 -0400

cmSourceFileLocation: Fix typo in comment

diff --git a/Source/cmSourceFileLocation.h b/Source/cmSourceFileLocation.h
index af3651a..7989173 100644
--- a/Source/cmSourceFileLocation.h
+++ b/Source/cmSourceFileLocation.h
@@ -39,7 +39,7 @@ public:
   cmSourceFileLocation& operator=(const cmSourceFileLocation& loc);
 
   /**
-   * Return whether the givne source file location could refers to the
+   * Return whether the given source file location could refers to the
* same source file as this location given the level of ambiguity in
* each location.
*/

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774eff4a01e709978736e442c6ed0c0b81c8
commit 814e774eff4a01e709978736e442c6ed0c0b81c8
Author: Tobias Hunger 
AuthorDate: Tue May 31 17:15:22 2016 +0200
Commit: Brad King 
CommitDate: Wed Jun 1 08:33:35 2016 -0400

cmSearchPath: Fix typo in comment

diff --git a/Source/cmSearchPath.h b/Source/cmSearchPath.h
index 4b37a3a..835196f 100644
--- a/Source/cmSearchPath.h
+++ b/Source/cmSearchPath.h
@@ -26,7 +26,7 @@ class cmSearchPath
 {
 public:
   // cmSearchPath must be initialized from a valid pointer.  The only reason
-  // for teh default is to allow it to be easily used in stl containers.
+  // for the default is to allow it to be easily used in stl containers.
   // Attempting to initialize with a NULL value will fail an assertion
   cmSearchPath(cmFindCommon* findCmd = 0);
   ~cmSearchPath();

---

Summary of changes:
 Source/cmSearchPath.h |2 +-
 Source/cmSourceFileLocation.h |2 +-
 2 files changed, 2 insertions(+), 2 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.5.2-1629-gb8560be

[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  b8560be7b0697c90cce259998b5c64bdff039ccd (commit)
   via  20e55e4be857a2dc5245d14d4fc06b4f0a675038 (commit)
  from  2fdaa209e13e01fff7186d55c1f11901262534b4 (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=b8560be7b0697c90cce259998b5c64bdff039ccd
commit b8560be7b0697c90cce259998b5c64bdff039ccd
Merge: 2fdaa20 20e55e4
Author: Brad King 
AuthorDate: Wed Jun 1 08:32:49 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 1 08:32:49 2016 -0400

Merge topic 'cpack-documentation-improvements' into next

20e55e4b CPackRPM and CPackDeb documentation improvements


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20e55e4be857a2dc5245d14d4fc06b4f0a675038
commit 20e55e4be857a2dc5245d14d4fc06b4f0a675038
Author: Domen Vrankar 
AuthorDate: Tue May 31 22:06:39 2016 +0200
Commit: Brad King 
CommitDate: Wed Jun 1 08:29:34 2016 -0400

CPackRPM and CPackDeb documentation improvements

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index ebeb387..c9678d6 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -2,29 +2,44 @@
 # CPackDeb
 # 
 #
-# The builtin (binary) CPack Deb generator (Unix only)
+# The built in (binary) CPack Deb generator (Unix only)
 #
 # Variables specific to CPack Debian (DEB) generator
 # ^^
 #
-# CPackDeb may be used to create Deb package using CPack.
-# CPackDeb is a CPack generator thus it uses the ``CPACK_XXX`` variables
-# used by CPack : https://cmake.org/Wiki/CMake:CPackConfiguration.
-# CPackDeb generator should work on any linux host but it will produce
-# better deb package when Debian specific tools 'dpkg-xxx' are usable on
+# CPackDeb may be used to create Deb package using :module:`CPack`.
+# CPackDeb is a :module:`CPack` generator thus it uses the ``CPACK_XXX``
+# variables used by :module:`CPack`.
+#
+# CPackDeb generator should work on any Linux host but it will produce
+# better deb package when Debian specific tools ``dpkg-xxx`` are usable on
 # the build system.
 #
 # CPackDeb has specific features which are controlled by the specifics
 # :code:`CPACK_DEBIAN_XXX` variables.
 #
 # :code:`CPACK_DEBIAN__` variables may be used in order to have
-# **component** specific values.  Note however that  refers to 
the
-# **grouping name** written in upper case. It may be either a component name or
-# a component GROUP name.
+# **component** specific values.  Note however that  refers to
+# the **grouping name** written in upper case. It may be either a component 
name
+# or a component GROUP name.
+#
+# Here are some CPackDeb wiki resources that are here for historic reasons and
+# are no longer maintained but may still prove useful:
+#
+#  - https://cmake.org/Wiki/CMake:CPackConfiguration
+#  - https://cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29
+#
+# List of CPackRPM specific variables:
+#
+# .. variable:: CPACK_DEB_PACKAGE_COMPONENT
+#
+#  Enable component packaging for CPackRPM
 #
-# You'll find a detailed usage on the wiki:
-# https://cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 .
-# However as a handy reminder here comes the list of specific variables:
+#  * Mandatory : NO
+#  * Default   : OFF
+#
+#  If enabled (ON) multiple packages are generated. By default a single package
+#  containing files of all components is generated.
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_NAME
 #   CPACK_DEBIAN__PACKAGE_NAME
@@ -55,7 +70,7 @@
 #
 #
_-_.deb
 #
-#  Alternatively provided package file name must end with ".deb" suffix.
+#  Alternatively provided package file name must end with ``.deb`` suffix.
 #
 #  .. note::
 #
@@ -98,7 +113,6 @@
 #  * Default   : Output of :code:`dpkg --print-architecture` (or :code:`i386`
 #if :code:`dpkg` is not found)
 #
-#
 # .. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS
 #   CPACK_DEBIAN__PACKAGE_DEPENDS
 #
@@ -141,7 +155,6 @@
 #  * Mandatory : YES
 #  * Default   : :code:`CPACK_PACKAGE_CONTACT`
 #
-#
 # .. variable:: CPACK_DEBIAN_PACKAGE_DESCRIPTION
 #   CPACK_COMPONENT__DESCRIPTION
 #
@@ -160,19 +173,23 @@
 #  Set Section control field e.g. admin, devel, doc, ...
 #
 #  * Mandatory : YES
-#  * Default   : 'devel'
+#  * Default   : "devel"
 #
 #  See https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
 #
-#
 # .. variable:: CPACK_DEBIAN_COMPRESSION_TYPE
 #
 #  The compression used for creating the 

[CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Esch Nigma]

Hello all,

I just registered to this mailing list, my apologies if this was already 
discussed.

I'm experiencing an issue where I'm unable to debug my code when the project is 
configured with CMake. When running gdb on the final binary, it mentions that 
no 
debugging symbols are found. I tried this via the command line, and through QT 
Creator.

After asking on StackOverflow, I was given a workaround - Cmake fails to figure 
out the 
compiler identification automatically. Adding 
-DCMAKE_CXX_COMPILER_ID:STRING=GNU 
makes it all work just fine. However, it should still detect it automatically.

I've built an empty Hello world to display this:

[eschnigma@manjaro quicktest]$ cat main.cpp  #include using 
namespace 
std; 

int main(){cout << "Hello there"; } 


When I build into a subdirectory and try to debug, this is the output:

   [eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" 

*Scanning dependencies of target qtest* 
[100%] Building CXX object CMakeFiles/qtest.dir/main.cpp.o 
*Linking CXX executable qtest* 
[100%] Built target qtest 


   [eschnigma@manjaro build]$ gdb qtest  GNU gdb (GDB) 7.11 Copyright (C) 2016 
Free 
Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later 
 This is free software: you are free to change and 
redistribute it. There is 
NO WARRANTY, to the extent permitted by law.  Type "show copying" and "show 
warranty" 
for details.
 This 
GDB was configured as "x86_64-pc-linux-gnu".


Type "show configuration" for configuration details. For bug reporting 
instructions, please 
see: . Find the GDB manual and other 
documentation resources online at: 
. 
For help, type "help". Type "apropos word" to search for commands related to 
"word"... 
Reading symbols from qtest...(no debugging symbols found)...done. (gdb)

However - when I compile manually, it works fine:

   [eschnigma@manjaro quicktest]$ c++ -g main.cpp [eschnigma@manjaro 
quicktest]$ 
gdb a.out GNU gdb (GDB) 7.11 Copyright (C) 2016 Free Software Foundation, Inc. 
License 
GPLv3+: GNU GPL version 3 or later  This is 
free 
software: you are free to change and redistribute it. There is NO WARRANTY, to 
the extent 
permitted by law.  Type "show copying" and "show warranty" for details. This 
GDB was 
configured as "x86_64-pc-linux-gnu". Type "show configuration" for 
configuration details. 
For bug reporting instructions, please see: 
. 
Find the GDB manual and other documentation resources online at: 
. For help, type "help". Type "apropos word" to 
search for 
commands related to "word"... Reading symbols from a.out...done. (gdb) quit


I have tested this on cmake version 2.8.11.2 and 3.5.2.
This problem started happening a few days ago, on two different machines, both 
running 
Manjaro Linux.

I'll be able to continue coding for now, but I wanted to report on this anyway 
- as far as I 
know, it should all be automatic.

Thanks,
Esch


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Konstantin Tokarev]

01.06.2016, 14:09, "Jakob van Bethlehem" :
>> Hey, that was the LTS release until 1 or 2 month ago!
>
> Oops, you're right, my mistake. Somewhere in the back of my head was that the 
> 4-series was in the 4.12.x or so version, not sure where that came from.

KDE 4 I guess (it went up to 4.14)

> I haven't worked with Qt4 ever, but have become extremely experienced with 
> Qt5 from Qt 5.4 onwards. Nevertheless, I should've checked before mentioning 
> it :P.
>
> Sincerely,
> Jakob van Bethlehem
>
> On Wed, Jun 1, 2016 at 10:47 AM, Hendrik Sattler  
> wrote:
>> Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem 
>> :
>>>That is what he said, but it seems to be a typo, because the
>>>CMakeLists.txt
>>>file clearly states 'set(QT_DIR
>>>${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'
>>
>> Ok, I overlooked that one...
>>
>>>- still a stone-age version of Qt actually :(
>>
>> Hey, that was the LTS release until 1 or 2 month ago!
>> And they made Qt 5.6 an LTS release also to quieten people that complain 
>> about dropping modules without proper replacement (means feature parity) and 
>> dropping compiler support.
>> You will see users of Qt 5.6 for a loong time.
>>
>>>On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler
>>>
>>>wrote:
>>>


 Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
 jsvanbethle...@gmail.com>:
 >Hej,
 >
 >Some things that come to mind:
 >* You're generating files *inside* the source tree - you're not
 >supposed to
 >do that
 >* Why do you want to have a special Qt_tmp directory? I don't see
>>>the
 >benefit, and without that requirement you can simply use the
 >qt4_wrap_cpp
 >macro explicitly and you still are not forced to use the automoc
 >feature
 >
 >And now for what is probably wrong in your CMakeLists.txt:
 >* It seems you made an important mistake regarding the behaviour of
 >'file(GLOB)'. That function will do the expansion *while running
 >CMake*.
 >But at that time the moc_* files *don't exist!* (as a matter of
>>>fact,
 >the
 >tmp directory doesn't even exist). In other words, your
>>>${Moc_SOURCES}
 >will
 >be empty, and hence they are not compiled, and hence you get
>>>precisely
 >the
 >linker errors you see (because these sources implement the functions
 >that
 >are listed as missing by the linker)
 >
 >If you would use the qt4_wrap_cpp() macro you don't run into this
 >problem,
 >so I'd strongly suggest using it.

 Except that he is using Qt3.

 >Sincerely,
 >Jakob van Bethlehem
 >
 >
 >
 >
 >On Tue, May 31, 2016 at 4:52 PM, irene w 
>>>wrote:
 >
 >> It seems CMakw could not find the generated moc_xxx files.  I
 >modified the
 >> scripts to specify moc_xxx files is generated, but it still has
>>>same
 >errors.
 >>
 >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
 >>                      COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
 >> ${Qt_tmp}/moc_GMWindow.cpp
 >>                      DEPENDS ${GM_DIR}/GMWindow.h
 >>                    )
 >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
 >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
 >> GENERATED 1)
 >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
 >OBJECT_DEPENDS
 >> ${Qt_tmp}/moc_GMWindow.cpp)
 >>
 >> .
 >> add_dependencies (GM generate_foo)
 >>
 >>
 >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
 >> setting work for this purposes?  Any help would be greatly
 >appreciated !
 >>
 >>
 >> On Wed, May 25, 2016 at 12:48 PM, irene w 
 >wrote:
 >>
 >>> Hi,
 >>>
 >>> I am compiling a simple Qt3 application on Linux using CMake. In
>>>my
 >case,
 >>> I need to build moc_xxx files with custom options and output to a
 >specified
 >>> directory, So, I was not using CAMKE_AUTO macros. My cmake
>>>scripts
 >create a
 >>> "Qt_tmp" directory and output moc_xxx there.
 >>>
 >>> It looked it always failed to link the moc_xxx files for the
>>>first
 >time
 >>> build when there is no "Qt_tmp" directory, and succeeded if I ran
 >build
 >>> again if the "Qt_tmp" directory and moc_xxx files created by the
 >failed
 >>> build were kept without removing.  However, it'll fail if I
>>>delete
 >>> the "Qt_tmp" directory.
 >>>
 >>> Even it failed at the first build, the moc_xxx files were
 >>> successfully created in the "Qt_tmp" directory.
 >>>
 >>> Here is my cmake scripts and the errors I got.  Can anyone help
>>>me
 >to
 >>> figure out the issues? Any help would be greatly appreciated.
 >Thanks.
 

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Jakob van Bethlehem]

> Hey, that was the LTS release until 1 or 2 month ago!

Oops, you're right, my mistake. Somewhere in the back of my head was that
the 4-series was in the 4.12.x or so version, not sure where that came
from. I haven't worked with Qt4 ever, but have become extremely experienced
with Qt5 from Qt 5.4 onwards. Nevertheless, I should've checked before
mentioning it :P.

Sincerely,
Jakob van Bethlehem

On Wed, Jun 1, 2016 at 10:47 AM, Hendrik Sattler 
wrote:

>
>
> Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem <
> jsvanbethle...@gmail.com>:
> >That is what he said, but it seems to be a typo, because the
> >CMakeLists.txt
> >file clearly states 'set(QT_DIR
> >${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'
>
> Ok, I overlooked that one...
>
> >- still a stone-age version of Qt actually :(
>
> Hey, that was the LTS release until 1 or 2 month ago!
> And they made Qt 5.6 an LTS release also to quieten people that complain
> about dropping modules without proper replacement (means feature parity)
> and dropping compiler support.
> You will see users of Qt 5.6 for a loong time.
>
> >On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler
> >
> >wrote:
> >
> >>
> >>
> >> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
> >> jsvanbethle...@gmail.com>:
> >> >Hej,
> >> >
> >> >Some things that come to mind:
> >> >* You're generating files *inside* the source tree - you're not
> >> >supposed to
> >> >do that
> >> >* Why do you want to have a special Qt_tmp directory? I don't see
> >the
> >> >benefit, and without that requirement you can simply use the
> >> >qt4_wrap_cpp
> >> >macro explicitly and you still are not forced to use the automoc
> >> >feature
> >> >
> >> >And now for what is probably wrong in your CMakeLists.txt:
> >> >* It seems you made an important mistake regarding the behaviour of
> >> >'file(GLOB)'. That function will do the expansion *while running
> >> >CMake*.
> >> >But at that time the moc_* files *don't exist!* (as a matter of
> >fact,
> >> >the
> >> >tmp directory doesn't even exist). In other words, your
> >${Moc_SOURCES}
> >> >will
> >> >be empty, and hence they are not compiled, and hence you get
> >precisely
> >> >the
> >> >linker errors you see (because these sources implement the functions
> >> >that
> >> >are listed as missing by the linker)
> >> >
> >> >If you would use the qt4_wrap_cpp() macro you don't run into this
> >> >problem,
> >> >so I'd strongly suggest using it.
> >>
> >> Except that he is using Qt3.
> >>
> >> >Sincerely,
> >> >Jakob van Bethlehem
> >> >
> >> >
> >> >
> >> >
> >> >On Tue, May 31, 2016 at 4:52 PM, irene w 
> >wrote:
> >> >
> >> >> It seems CMakw could not find the generated moc_xxx files.  I
> >> >modified the
> >> >> scripts to specify moc_xxx files is generated, but it still has
> >same
> >> >errors.
> >> >>
> >> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
> >> >>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> >> >> ${Qt_tmp}/moc_GMWindow.cpp
> >> >>  DEPENDS ${GM_DIR}/GMWindow.h
> >> >>)
> >> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
> >> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
> >> >> GENERATED 1)
> >> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
> >> >OBJECT_DEPENDS
> >> >> ${Qt_tmp}/moc_GMWindow.cpp)
> >> >>
> >> >> .
> >> >> add_dependencies (GM generate_foo)
> >> >>
> >> >>
> >> >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
> >> >> setting work for this purposes?  Any help would be greatly
> >> >appreciated !
> >> >>
> >> >>
> >> >> On Wed, May 25, 2016 at 12:48 PM, irene w 
> >> >wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> I am compiling a simple Qt3 application on Linux using CMake. In
> >my
> >> >case,
> >> >>> I need to build moc_xxx files with custom options and output to a
> >> >specified
> >> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake
> >scripts
> >> >create a
> >> >>> "Qt_tmp" directory and output moc_xxx there.
> >> >>>
> >> >>> It looked it always failed to link the moc_xxx files for the
> >first
> >> >time
> >> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran
> >> >build
> >> >>> again if the "Qt_tmp" directory and moc_xxx files created by the
> >> >failed
> >> >>> build were kept without removing.  However, it'll fail if I
> >delete
> >> >>> the "Qt_tmp" directory.
> >> >>>
> >> >>> Even it failed at the first build, the moc_xxx files were
> >> >>> successfully created in the "Qt_tmp" directory.
> >> >>>
> >> >>> Here is my cmake scripts and the errors I got.  Can anyone help
> >me
> >> >to
> >> >>> figure out the issues? Any help would be greatly appreciated.
> >> >Thanks.
> >> >>>
> >> >>> CMakeLists.txt
> >> >>>
> >> >>>
> >>
> >>
>
> 

[CMake] Unit Testing for CMake Scripts

[Walter Gray]

I was about to ask the list, but some googling lead me to this:

https://github.com/polysquare/cmake-unit

I am not the developer, but he doesn't appear to be on here so I thought I
should share. This looks incredibly useful
-- 

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 use CMAKE_MFC_FLAG for only one on executables?

[Zhang Peixuan]

Hello All,

I want to use CMake to manage my MFC projects, and I added the following
code:

set( CMAKE_MFC_FLAG 2)
add_executable(MFCDemo WIN32
${MFC_RESOURCE_FILES}
${MFC_HEADER_FILES}
${MFC_SOURCE_FILES}
)
target_compile_definitions(MFCDemo
PUBLIC -D_AFXDLL=1
PUBLIC -D_UNICODE
PUBLIC -DUNICODE
)

It works.
However, my question is that: In addition to the MFC executable, I still
have some non-MFC executables,
and once CMAKE_MFC_FLAG is set, all the add_executables' property should be
"Use MFC in a Shared DLL".
In fact, I want only one MFC executable, and make sure all other
executables are "Use Standard Windows Library".
Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work
with set_target_property or other commands.

Thanks,
Peixuan Zhang
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake error output and .vcxproj.filters files.

[Golebiewski, Jakub]

Hi,

We've recently switched to using cmake and I've got some 'issues'. We use 
Windows with Visual Studio and MSVC (Visual Studio 10 2010 Win64 generator).


1.   In cmake error output the output format is not compatible with VS so 
when the VS console displays it, you cannot click on the filename to open it:

I get this:


1>  CMake Error at D:/depot/ef/wrk/CMakeLists.txt:210 (GET_TARGET_PROPERTY):



And it should look like this for VS to work:


1>  CMake Error at D:/depot/ef/wrk/CMakeLists.txt(210) (GET_TARGET_PROPERTY):



Can I change the format in CMakeLists.txt or do I need to patch the sources? In 
the case of the latter could you point me to right place in the code?



2.   When I get an error in CMake it displays the CMakeListst.txt file, the 
error occurred in and the root file. Is this possible to get the whole 'stack 
trace' with all the files

That are involved (through ADD_SUBDIRECTORY)?



3.   CMake seems to generate .vcxproj.filters files as well as .vcxproj 
files. Is there a way to turn this off so people could use their own .filters 
files?

Thanks for help!


Best regards
for Det Norske Veritas Poland Sp. z o.o.

Jakub Golebiewski M.Sc
Software Engineer, Development Gdynia

E-mail jakub.golebiew...@dnvgl.com
Mobile +48 606 33 66 59
www.dnvgl.com  |  
LinkedIn

[DNV GL]


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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Some trivial patches

[Tobias Hunger]

Hi CMake Developers!

Attached you will find a couple of really small changes that add const to a
method and fix a couple of typos in comments. Trivial stuff.

This is mostly to figure out how to contribute code:-)

Is this the preferred way you want your patches? Or do I need to inline
them somehow?

How can I create an account in the bug tracker?

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
From 2e3d372dd5026a257cd11badd87dbfff7255851d Mon Sep 17 00:00:00 2001
From: Tobias Hunger 
Date: Tue, 31 May 2016 13:53:19 +0200
Subject: [PATCH 01/11] cmGlobalGenerator: Make IsMultiConfig() const

---
 Source/cmGlobalGenerator.h | 2 +-
 Source/cmGlobalVisualStudioGenerator.h | 2 +-
 Source/cmGlobalXCodeGenerator.cxx  | 2 +-
 Source/cmGlobalXCodeGenerator.h| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 2575911..68ff042 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -319,7 +319,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return false; }
+  virtual bool IsMultiConfig() const { return false; }
 
   std::string GetSharedLibFlagsForLanguage(std::string const& lang) const;
 
diff --git a/Source/cmGlobalVisualStudioGenerator.h b/Source/cmGlobalVisualStudioGenerator.h
index fb2cdbd..1d456ff 100644
--- a/Source/cmGlobalVisualStudioGenerator.h
+++ b/Source/cmGlobalVisualStudioGenerator.h
@@ -85,7 +85,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return true; }
+  virtual bool IsMultiConfig() const { return true; }
 
   /** Return true if building for Windows CE */
   virtual bool TargetsWindowsCE() const { return false; }
diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx
index 6628cfc..b666594 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3437,7 +3437,7 @@ std::string cmGlobalXCodeGenerator::ComputeInfoPListLocation(
 
 // Return true if the generated build tree may contain multiple builds.
 // i.e. "Can I build Debug and Release in the same tree?"
-bool cmGlobalXCodeGenerator::IsMultiConfig()
+bool cmGlobalXCodeGenerator::IsMultiConfig() const
 {
   // Old Xcode 1.5 is single config:
   if (this->XcodeVersion == 15) {
diff --git a/Source/cmGlobalXCodeGenerator.h b/Source/cmGlobalXCodeGenerator.h
index 2ca4c19..0485d4f 100644
--- a/Source/cmGlobalXCodeGenerator.h
+++ b/Source/cmGlobalXCodeGenerator.h
@@ -79,7 +79,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig();
+  virtual bool IsMultiConfig() const;
 
   virtual bool SetGeneratorToolset(std::string const& ts, cmMakefile* mf);
   void AppendFlag(std::string& flags, std::string const& flag);
-- 
2.8.3

From 122c333c7820fd245a7a04851e4ac29cf58573a9 Mon Sep 17 00:00:00 2001
From: Tobias Hunger 
Date: Tue, 31 May 2016 17:15:22 +0200
Subject: [PATCH 02/11] Fix typo

---
 Source/cmSearchPath.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmSearchPath.h b/Source/cmSearchPath.h
index 4b37a3a..835196f 100644
--- a/Source/cmSearchPath.h
+++ b/Source/cmSearchPath.h
@@ -26,7 +26,7 @@ class cmSearchPath
 {
 public:
   // cmSearchPath must be initialized from a valid pointer.  The only reason
-  // for teh default is to allow it to be easily used in stl containers.
+  // for the default is to allow it to be easily used in stl containers.
   // Attempting to initialize with a NULL value will fail an assertion
   cmSearchPath(cmFindCommon* findCmd = 0);
   ~cmSearchPath();
-- 
2.8.3

From dfc0409147b6bb07e95226e2dd56b001f2cc6dc8 Mon Sep 17 00:00:00 2001
From: Tobias Hunger 
Date: Tue, 31 May 2016 17:15:56 +0200
Subject: [PATCH 03/11] Fix typo

---
 Source/cmSourceFileLocation.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmSourceFileLocation.h b/Source/cmSourceFileLocation.h
index af3651a..7989173 100644
--- a/Source/cmSourceFileLocation.h
+++ b/Source/cmSourceFileLocation.h
@@ -39,7 +39,7 @@ public:
   cmSourceFileLocation& operator=(const cmSourceFileLocation& loc);
 
   /**
-   * Return whether the givne source file location could refers to the
+   * Return whether the given source file location could refers to the
* same source file as this location given the level of ambiguity in
* 

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Hendrik Sattler]

Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem 
:
>That is what he said, but it seems to be a typo, because the
>CMakeLists.txt
>file clearly states 'set(QT_DIR
>${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'

Ok, I overlooked that one...

>- still a stone-age version of Qt actually :(

Hey, that was the LTS release until 1 or 2 month ago!
And they made Qt 5.6 an LTS release also to quieten people that complain about 
dropping modules without proper replacement (means feature parity) and dropping 
compiler support.
You will see users of Qt 5.6 for a loong time.

>On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler
>
>wrote:
>
>>
>>
>> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
>> jsvanbethle...@gmail.com>:
>> >Hej,
>> >
>> >Some things that come to mind:
>> >* You're generating files *inside* the source tree - you're not
>> >supposed to
>> >do that
>> >* Why do you want to have a special Qt_tmp directory? I don't see
>the
>> >benefit, and without that requirement you can simply use the
>> >qt4_wrap_cpp
>> >macro explicitly and you still are not forced to use the automoc
>> >feature
>> >
>> >And now for what is probably wrong in your CMakeLists.txt:
>> >* It seems you made an important mistake regarding the behaviour of
>> >'file(GLOB)'. That function will do the expansion *while running
>> >CMake*.
>> >But at that time the moc_* files *don't exist!* (as a matter of
>fact,
>> >the
>> >tmp directory doesn't even exist). In other words, your
>${Moc_SOURCES}
>> >will
>> >be empty, and hence they are not compiled, and hence you get
>precisely
>> >the
>> >linker errors you see (because these sources implement the functions
>> >that
>> >are listed as missing by the linker)
>> >
>> >If you would use the qt4_wrap_cpp() macro you don't run into this
>> >problem,
>> >so I'd strongly suggest using it.
>>
>> Except that he is using Qt3.
>>
>> >Sincerely,
>> >Jakob van Bethlehem
>> >
>> >
>> >
>> >
>> >On Tue, May 31, 2016 at 4:52 PM, irene w 
>wrote:
>> >
>> >> It seems CMakw could not find the generated moc_xxx files.  I
>> >modified the
>> >> scripts to specify moc_xxx files is generated, but it still has
>same
>> >errors.
>> >>
>> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
>> >>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>> >> ${Qt_tmp}/moc_GMWindow.cpp
>> >>  DEPENDS ${GM_DIR}/GMWindow.h
>> >>)
>> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
>> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
>> >> GENERATED 1)
>> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
>> >OBJECT_DEPENDS
>> >> ${Qt_tmp}/moc_GMWindow.cpp)
>> >>
>> >> .
>> >> add_dependencies (GM generate_foo)
>> >>
>> >>
>> >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
>> >> setting work for this purposes?  Any help would be greatly
>> >appreciated !
>> >>
>> >>
>> >> On Wed, May 25, 2016 at 12:48 PM, irene w 
>> >wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I am compiling a simple Qt3 application on Linux using CMake. In
>my
>> >case,
>> >>> I need to build moc_xxx files with custom options and output to a
>> >specified
>> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake
>scripts
>> >create a
>> >>> "Qt_tmp" directory and output moc_xxx there.
>> >>>
>> >>> It looked it always failed to link the moc_xxx files for the
>first
>> >time
>> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran
>> >build
>> >>> again if the "Qt_tmp" directory and moc_xxx files created by the
>> >failed
>> >>> build were kept without removing.  However, it'll fail if I
>delete
>> >>> the "Qt_tmp" directory.
>> >>>
>> >>> Even it failed at the first build, the moc_xxx files were
>> >>> successfully created in the "Qt_tmp" directory.
>> >>>
>> >>> Here is my cmake scripts and the errors I got.  Can anyone help
>me
>> >to
>> >>> figure out the issues? Any help would be greatly appreciated.
>> >Thanks.
>> >>>
>> >>> CMakeLists.txt
>> >>>
>> >>>
>>
>>
>>-
>> >>> cmake_minimum_required(VERSION 3.4.1)
>> >>> project (GM_Application CXX)
>> >>> SET (CMAKE_SYSTEM_NAME Linux)
>> >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
>> >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>> >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)
>> >>> LINK_DIRECTORIES (${QT_DIR}/lib)
>> >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include"
>> >>>  "${GM_DIR}"
>> >>> )
>> >>> # Compiling QT moc and ui  #
>> >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++
>> >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui)
>> >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>> >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>> >>> 

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Jakob van Bethlehem]

That is what he said, but it seems to be a typo, because the CMakeLists.txt
file clearly states 'set(QT_DIR
${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'
- still a stone-age version of Qt actually :(

Sincerely,
Jakob van Bethlehem


On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler 
wrote:

>
>
> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
> jsvanbethle...@gmail.com>:
> >Hej,
> >
> >Some things that come to mind:
> >* You're generating files *inside* the source tree - you're not
> >supposed to
> >do that
> >* Why do you want to have a special Qt_tmp directory? I don't see the
> >benefit, and without that requirement you can simply use the
> >qt4_wrap_cpp
> >macro explicitly and you still are not forced to use the automoc
> >feature
> >
> >And now for what is probably wrong in your CMakeLists.txt:
> >* It seems you made an important mistake regarding the behaviour of
> >'file(GLOB)'. That function will do the expansion *while running
> >CMake*.
> >But at that time the moc_* files *don't exist!* (as a matter of fact,
> >the
> >tmp directory doesn't even exist). In other words, your ${Moc_SOURCES}
> >will
> >be empty, and hence they are not compiled, and hence you get precisely
> >the
> >linker errors you see (because these sources implement the functions
> >that
> >are listed as missing by the linker)
> >
> >If you would use the qt4_wrap_cpp() macro you don't run into this
> >problem,
> >so I'd strongly suggest using it.
>
> Except that he is using Qt3.
>
> >Sincerely,
> >Jakob van Bethlehem
> >
> >
> >
> >
> >On Tue, May 31, 2016 at 4:52 PM, irene w  wrote:
> >
> >> It seems CMakw could not find the generated moc_xxx files.  I
> >modified the
> >> scripts to specify moc_xxx files is generated, but it still has same
> >errors.
> >>
> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
> >>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> >> ${Qt_tmp}/moc_GMWindow.cpp
> >>  DEPENDS ${GM_DIR}/GMWindow.h
> >>)
> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
> >> GENERATED 1)
> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
> >OBJECT_DEPENDS
> >> ${Qt_tmp}/moc_GMWindow.cpp)
> >>
> >> .
> >> add_dependencies (GM generate_foo)
> >>
> >>
> >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
> >> setting work for this purposes?  Any help would be greatly
> >appreciated !
> >>
> >>
> >> On Wed, May 25, 2016 at 12:48 PM, irene w 
> >wrote:
> >>
> >>> Hi,
> >>>
> >>> I am compiling a simple Qt3 application on Linux using CMake. In my
> >case,
> >>> I need to build moc_xxx files with custom options and output to a
> >specified
> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts
> >create a
> >>> "Qt_tmp" directory and output moc_xxx there.
> >>>
> >>> It looked it always failed to link the moc_xxx files for the first
> >time
> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran
> >build
> >>> again if the "Qt_tmp" directory and moc_xxx files created by the
> >failed
> >>> build were kept without removing.  However, it'll fail if I delete
> >>> the "Qt_tmp" directory.
> >>>
> >>> Even it failed at the first build, the moc_xxx files were
> >>> successfully created in the "Qt_tmp" directory.
> >>>
> >>> Here is my cmake scripts and the errors I got.  Can anyone help me
> >to
> >>> figure out the issues? Any help would be greatly appreciated.
> >Thanks.
> >>>
> >>> CMakeLists.txt
> >>>
> >>>
>
> >-
> >>> cmake_minimum_required(VERSION 3.4.1)
> >>> project (GM_Application CXX)
> >>> SET (CMAKE_SYSTEM_NAME Linux)
> >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
> >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
> >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)
> >>> LINK_DIRECTORIES (${QT_DIR}/lib)
> >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include"
> >>>  "${GM_DIR}"
> >>> )
> >>> # Compiling QT moc and ui  #
> >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++
> >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui)
> >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
> >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
> >>> add_custom_target (Moc_GMWindows
> >>>COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> >>> ${Qt_tmp}/moc_GMWindow.cpp
> >>>   )
> >>>
> >>> # Compiling application  #
> >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp)
> >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp)
> >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES})
> >>> target_include_directories (GM PRIVATE ${Qt_tmp})
> >>> add_dependencies (GM Moc_GMWindows)
> >>> target_link_libraries (GM QtGui)
> >>>

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Hendrik Sattler]

Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem 
:
>Hej,
>
>Some things that come to mind:
>* You're generating files *inside* the source tree - you're not
>supposed to
>do that
>* Why do you want to have a special Qt_tmp directory? I don't see the
>benefit, and without that requirement you can simply use the
>qt4_wrap_cpp
>macro explicitly and you still are not forced to use the automoc
>feature
>
>And now for what is probably wrong in your CMakeLists.txt:
>* It seems you made an important mistake regarding the behaviour of
>'file(GLOB)'. That function will do the expansion *while running
>CMake*.
>But at that time the moc_* files *don't exist!* (as a matter of fact,
>the
>tmp directory doesn't even exist). In other words, your ${Moc_SOURCES}
>will
>be empty, and hence they are not compiled, and hence you get precisely
>the
>linker errors you see (because these sources implement the functions
>that
>are listed as missing by the linker)
>
>If you would use the qt4_wrap_cpp() macro you don't run into this
>problem,
>so I'd strongly suggest using it.

Except that he is using Qt3.

>Sincerely,
>Jakob van Bethlehem
>
>
>
>
>On Tue, May 31, 2016 at 4:52 PM, irene w  wrote:
>
>> It seems CMakw could not find the generated moc_xxx files.  I
>modified the
>> scripts to specify moc_xxx files is generated, but it still has same
>errors.
>>
>> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
>>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>> ${Qt_tmp}/moc_GMWindow.cpp
>>  DEPENDS ${GM_DIR}/GMWindow.h
>>)
>> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
>> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
>> GENERATED 1)
>> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
>OBJECT_DEPENDS
>> ${Qt_tmp}/moc_GMWindow.cpp)
>>
>> .
>> add_dependencies (GM generate_foo)
>>
>>
>> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
>> setting work for this purposes?  Any help would be greatly
>appreciated !
>>
>>
>> On Wed, May 25, 2016 at 12:48 PM, irene w 
>wrote:
>>
>>> Hi,
>>>
>>> I am compiling a simple Qt3 application on Linux using CMake. In my
>case,
>>> I need to build moc_xxx files with custom options and output to a
>specified
>>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts
>create a
>>> "Qt_tmp" directory and output moc_xxx there.
>>>
>>> It looked it always failed to link the moc_xxx files for the first
>time
>>> build when there is no "Qt_tmp" directory, and succeeded if I ran
>build
>>> again if the "Qt_tmp" directory and moc_xxx files created by the
>failed
>>> build were kept without removing.  However, it'll fail if I delete
>>> the "Qt_tmp" directory.
>>>
>>> Even it failed at the first build, the moc_xxx files were
>>> successfully created in the "Qt_tmp" directory.
>>>
>>> Here is my cmake scripts and the errors I got.  Can anyone help me
>to
>>> figure out the issues? Any help would be greatly appreciated. 
>Thanks.
>>>
>>> CMakeLists.txt
>>>
>>>
>-
>>> cmake_minimum_required(VERSION 3.4.1)
>>> project (GM_Application CXX)
>>> SET (CMAKE_SYSTEM_NAME Linux)
>>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
>>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)
>>> LINK_DIRECTORIES (${QT_DIR}/lib)
>>> INCLUDE_DIRECTORIES ("${QT_DIR}/include"
>>>  "${GM_DIR}"
>>> )
>>> # Compiling QT moc and ui  #
>>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++
>>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui)
>>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>>> add_custom_target (Moc_GMWindows
>>>COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>>> ${Qt_tmp}/moc_GMWindow.cpp
>>>   )
>>>
>>> # Compiling application  #
>>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp)
>>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp)
>>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES})
>>> target_include_directories (GM PRIVATE ${Qt_tmp})
>>> add_dependencies (GM Moc_GMWindows)
>>> target_link_libraries (GM QtGui)
>>>
>>>
>>>
>---
>>> Errors:
>>>
>>> Scanning dependencies of target Moc_GMWindows
>>> [  0%] Built target Moc_GMWindows
>>> Scanning dependencies of target GM
>>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o
>>> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o
>>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o
>>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o
>>> [100%] Linking CXX executable ../bin/GM
>>> 

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Jakob van Bethlehem]

Hej,

Some things that come to mind:
* You're generating files *inside* the source tree - you're not supposed to
do that
* Why do you want to have a special Qt_tmp directory? I don't see the
benefit, and without that requirement you can simply use the qt4_wrap_cpp
macro explicitly and you still are not forced to use the automoc feature

And now for what is probably wrong in your CMakeLists.txt:
* It seems you made an important mistake regarding the behaviour of
'file(GLOB)'. That function will do the expansion *while running CMake*.
But at that time the moc_* files *don't exist!* (as a matter of fact, the
tmp directory doesn't even exist). In other words, your ${Moc_SOURCES} will
be empty, and hence they are not compiled, and hence you get precisely the
linker errors you see (because these sources implement the functions that
are listed as missing by the linker)

If you would use the qt4_wrap_cpp() macro you don't run into this problem,
so I'd strongly suggest using it.

Sincerely,
Jakob van Bethlehem




On Tue, May 31, 2016 at 4:52 PM, irene w  wrote:

> It seems CMakw could not find the generated moc_xxx files.  I modified the
> scripts to specify moc_xxx files is generated, but it still has same errors.
>
> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> ${Qt_tmp}/moc_GMWindow.cpp
>  DEPENDS ${GM_DIR}/GMWindow.h
>)
> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
> GENERATED 1)
> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY OBJECT_DEPENDS
> ${Qt_tmp}/moc_GMWindow.cpp)
>
> .
> add_dependencies (GM generate_foo)
>
>
> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
> setting work for this purposes?  Any help would be greatly appreciated !
>
>
> On Wed, May 25, 2016 at 12:48 PM, irene w  wrote:
>
>> Hi,
>>
>> I am compiling a simple Qt3 application on Linux using CMake. In my case,
>> I need to build moc_xxx files with custom options and output to a specified
>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts create a
>> "Qt_tmp" directory and output moc_xxx there.
>>
>> It looked it always failed to link the moc_xxx files for the first time
>> build when there is no "Qt_tmp" directory, and succeeded if I ran build
>> again if the "Qt_tmp" directory and moc_xxx files created by the failed
>> build were kept without removing.  However, it'll fail if I delete
>> the "Qt_tmp" directory.
>>
>> Even it failed at the first build, the moc_xxx files were
>> successfully created in the "Qt_tmp" directory.
>>
>> Here is my cmake scripts and the errors I got.  Can anyone help me to
>> figure out the issues? Any help would be greatly appreciated.  Thanks.
>>
>> CMakeLists.txt
>>
>> -
>> cmake_minimum_required(VERSION 3.4.1)
>> project (GM_Application CXX)
>> SET (CMAKE_SYSTEM_NAME Linux)
>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)
>> LINK_DIRECTORIES (${QT_DIR}/lib)
>> INCLUDE_DIRECTORIES ("${QT_DIR}/include"
>>  "${GM_DIR}"
>> )
>> # Compiling QT moc and ui  #
>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++
>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui)
>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>> add_custom_target (Moc_GMWindows
>>COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>> ${Qt_tmp}/moc_GMWindow.cpp
>>   )
>>
>> # Compiling application  #
>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp)
>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp)
>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES})
>> target_include_directories (GM PRIVATE ${Qt_tmp})
>> add_dependencies (GM Moc_GMWindows)
>> target_link_libraries (GM QtGui)
>>
>>
>> ---
>> Errors:
>>
>> Scanning dependencies of target Moc_GMWindows
>> [  0%] Built target Moc_GMWindows
>> Scanning dependencies of target GM
>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o
>> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o
>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o
>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o
>> [100%] Linking CXX executable ../bin/GM
>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function
>> `GM::GMWindow::emitAppendMessage(QStrin
>> g)':
>> /GM/GMWindow.cpp:217: undefined reference to
>> `GM::GMWindow::appendMessage(QString)'
>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable
>> for