[CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing

2016-07-09 Thread Dvir Yitzchaki
Hi.

I use cmake 3.3.1 on Red-Hat 5 and 6.
When I generate a project I get the following error:

CMake Error: Error required internal CMake variable not set, cmake may be not 
be built correctly.
Missing variable is:
CMAKE_C++_CREATE_SHARED_LIBRARY

However, after the error the generation succeeds and I can build the project 
successfully.
The same project is generated without errors on Windows 7 with Visual Studio 
generators and other projects are also generated without errors on the same 
Linux machine.

Does anyone knows the source of that error?

Thanks,

Dvir
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-351-g03a5096

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

The branch, master has been updated
   via  03a50961f338462acc65db876c59e0045f0754d9 (commit)
  from  325288455eb4a0e7dad9689b6ebac1afe7ef7cc3 (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=03a50961f338462acc65db876c59e0045f0754d9
commit 03a50961f338462acc65db876c59e0045f0754d9
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sun Jul 10 00:01:03 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sun Jul 10 00:01:03 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6923bf8..29d0133 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 20160709)
+set(CMake_VERSION_PATCH 20160710)
 #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] [PATCH v4] For consoles output on Windows use our own std::streambuf

2016-07-09 Thread Dāvis Mosāns
Currently Microsoft's C++ libraries implementation of std::cout/cerr
can't output Unicode characters but only ASCII or ANSI if locale is set
so we implement and use our own ConsoleBuf which can output Unicode
characters to console and it doesn't matter what locale or console's
codepage is set.
---
 CMakeLists.txt |   1 +
 Source/cmakemain.cxx   |  27 
 Source/kwsys/CMakeLists.txt|   6 +-
 Source/kwsys/ConsoleBuf.hxx.in | 282 +
 bootstrap  |   1 +
 5 files changed, 316 insertions(+), 1 deletion(-)
 create mode 100644 Source/kwsys/ConsoleBuf.hxx.in

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ae5990e..792b5a5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -258,6 +258,7 @@ macro (CMAKE_BUILD_UTILITIES)
   set(KWSYS_USE_MD5 1)
   set(KWSYS_USE_Process 1)
   set(KWSYS_USE_CommandLineArguments 1)
+  set(KWSYS_USE_ConsoleBuf 1)
   set(KWSYS_HEADER_ROOT ${CMake_BINARY_DIR}/Source)
   set(KWSYS_INSTALL_DOC_DIR "${CMAKE_DOC_DIR}")
   add_subdirectory(Source/kwsys)
diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index 521a5bf..95eb154 100644
--- a/Source/cmakemain.cxx
+++ b/Source/cmakemain.cxx
@@ -26,6 +26,7 @@
 #include "cmake.h"
 #include "cmcmd.h"
 #include 
+#include 
 
 #ifdef CMAKE_BUILD_WITH_CMAKE
 static const char* cmDocumentationName[][2] = {
@@ -153,6 +154,22 @@ static void cmakemainProgressCallback(const char* m, float 
prog,
 
 int main(int ac, char const* const* av)
 {
+#if defined(_WIN32)
+  // Replace streambuf so we can output Unicode to console
+  cmsys::ConsoleBuf *cbufio = CM_NULLPTR;
+  cmsys::ConsoleBuf *cbuferr = CM_NULLPTR;
+  std::streambuf *coutbuf = std::cout.rdbuf();
+  std::streambuf *cerrbuf = std::cerr.rdbuf();
+  try {
+cbufio = new cmsys::ConsoleBuf();
+coutbuf = std::cout.rdbuf(cbufio);
+cbuferr = new cmsys::ConsoleBuf(true);
+cerrbuf = std::cerr.rdbuf(cbuferr);
+  } catch (const std::runtime_error& ex) {
+std::cerr << "Failed to create ConsoleBuf!" << std::endl
+  << ex.what() << std::endl;
+  };
+#endif
   cmsys::Encoding::CommandLineArguments args =
 cmsys::Encoding::CommandLineArguments::Main(ac, av);
   ac = args.argc();
@@ -171,6 +188,16 @@ int main(int ac, char const* const* av)
 #ifdef CMAKE_BUILD_WITH_CMAKE
   cmDynamicLoader::FlushCache();
 #endif
+#if defined(_WIN32)
+  if (cbufio) {
+delete cbufio;
+std::cout.rdbuf(coutbuf);
+  }
+  if (cbuferr) {
+delete cbuferr;
+std::cerr.rdbuf(cerrbuf);
+  }
+#endif
   return ret;
 }
 
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 65203c0..33a97e6 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -123,6 +123,7 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
   SET(KWSYS_USE_FStream 1)
   SET(KWSYS_USE_String 1)
   SET(KWSYS_USE_SystemInformation 1)
+  SET(KWSYS_USE_ConsoleBuf 1)
 ENDIF()
 
 # Enforce component dependencies.
@@ -154,6 +155,9 @@ ENDIF()
 IF(KWSYS_USE_FStream)
   SET(KWSYS_USE_Encoding 1)
 ENDIF()
+IF(KWSYS_USE_ConsoleBuf)
+  SET(KWSYS_USE_Encoding 1)
+ENDIF()
 
 # Setup the large file support default.
 IF(KWSYS_LFS_DISABLE)
@@ -668,7 +672,7 @@ SET(KWSYS_HXX_FILES Configure String
 # Add selected C++ classes.
 SET(cppclasses
   Directory DynamicLoader Encoding Glob RegularExpression SystemTools
-  CommandLineArguments IOStream FStream SystemInformation
+  CommandLineArguments IOStream FStream SystemInformation ConsoleBuf
   )
 FOREACH(cpp ${cppclasses})
   IF(KWSYS_USE_${cpp})
diff --git a/Source/kwsys/ConsoleBuf.hxx.in b/Source/kwsys/ConsoleBuf.hxx.in
new file mode 100644
index 000..4ee37dd
--- /dev/null
+++ b/Source/kwsys/ConsoleBuf.hxx.in
@@ -0,0 +1,282 @@
+/*
+  KWSys - Kitware System Library
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+*/
+#ifndef @KWSYS_NAMESPACE@_ConsoleBuf_hxx
+#define @KWSYS_NAMESPACE@_ConsoleBuf_hxx
+
+#include <@KWSYS_NAMESPACE@/Configure.hxx>
+#include <@KWSYS_NAMESPACE@/Encoding.hxx>
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(_WIN32)
+#  include 
+#  if __cplusplus >= 201103L
+#include 
+#  endif
+#endif
+
+namespace @KWSYS_NAMESPACE@
+{
+#if defined(_WIN32)
+
+  template >
+  class @KWSYS_NAMESPACE@_EXPORT BasicConsoleBuf : public 
std::basic_streambuf {
+public:
+  typedef typename Traits::int_type int_type;
+  typedef typename Traits::char_type char_type;
+
+  BasicConsoleBuf(const bool err = false) :
+

Re: [CMake] Unable to find source files in different directory using target_sources(INTERFACE)

2016-07-09 Thread Robert Dailey
Thanks, I just verified that doing absolute path works. I find it
frustrating though that relative paths aren't calculated to absolute
at the time the function is called, though. I feel like CMake should
be doing this for me.

On Sat, Jul 9, 2016 at 7:23 PM, Craig Scott  wrote:
> Sorry, hit the send button prematurely. To achieve your desired goal of
> creating a header only library as a target in Visual Studio, it somewhat
> depends on what you want to do with that library. If you just want it to be
> there so you can see the header in the IDE, then simply defining a dummy
> custom target is one approach I've seen people use. E.g.
>
>   add_custom_target(foo SOURCES foo.h)
>
> If you want to actually link to the target so it can provide header search
> path dependencies, then the approach you tried is probably the closest (with
> the use of absolute paths as described in my previous email). As you
> discovered though, it adds the header to the sources list of each project
> linking against it, which it sounds like you want to avoid. An interface
> library doesn't create build output on its own, so it doesn't make sense for
> it to have its own list of sources. The only way sources make sense for it
> is for those sources to be added to anything linking against it, which is
> the behaviour you are seeing.
>
>
>
>
>
> On Sun, Jul 10, 2016 at 10:04 AM, Craig Scott 
> wrote:
>>
>> When using target_sources(), if you specify the source file(s) with a
>> relative path, CMake does not convert that to an absolute path when storing
>> it in the target's SOURCES property (that's my interpretation anyway). The
>> end result is that the source you specify is going to be interpreted as
>> being relative to the source directory the dependent target is defined in,
>> not the directory where you called target_sources().  You can prevent the
>> problem you described by ensuring the path for the source file(s) is always
>> an absolute one. For example:
>>
>> target_sources(foo INTERFACE "${CMAKE_CURRENT_LIST_DIR}/foo.h")
>>
>> You may find the following blog article useful (it discusses the above
>> problem and also other related material):
>>
>>
>> https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/
>>
>>
>>
>>
>> On Sun, Jul 10, 2016 at 9:03 AM, Robert Dailey 
>> wrote:
>>>
>>> I have the following:
>>>
>>> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
>>> project(foo)
>>> add_library(foo INTERFACE)
>>> target_sources(foo INTERFACE foo.h)
>>> add_subdirectory(subdir)
>>>
>>> And inside subdir, I specify add_executable() and then
>>> target_link_libraries(myexe foo).
>>>
>>> I get an error:
>>>
>>> Cannot find source file: foo.h
>>>
>>> I'm using CMake 3.6. What am I doing wrong here?
>>>
>>> My goal is to generate a header-only project in Visual Studio.
>>> According to the documentation, what I'm trying to do won't give me
>>> that. Instead, foo.h would exist in every project that links to it as
>>> a dependency (that's what it seems like anyhow).
>>>
>>> Advice is appreciated.
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> http://crascit.com
>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> http://crascit.com
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [CMake] Unable to find source files in different directory using target_sources(INTERFACE)

2016-07-09 Thread Craig Scott
Sorry, hit the send button prematurely. To achieve your desired goal of
creating a header only library as a target in Visual Studio, it somewhat
depends on what you want to do with that library. If you just want it to be
there so you can see the header in the IDE, then simply defining a dummy
custom target is one approach I've seen people use. E.g.

  add_custom_target(foo SOURCES foo.h)

If you want to actually link to the target so it can provide header search
path dependencies, then the approach you tried is probably the closest
(with the use of absolute paths as described in my previous email). As you
discovered though, it adds the header to the sources list of each project
linking against it, which it sounds like you want to avoid. An interface
library doesn't create build output on its own, so it doesn't make sense
for it to have its own list of sources. The only way sources make sense for
it is for those sources to be added to anything linking against it, which
is the behaviour you are seeing.





On Sun, Jul 10, 2016 at 10:04 AM, Craig Scott 
wrote:

> When using target_sources(), if you specify the source file(s) with a
> relative path, CMake does not convert that to an absolute path when storing
> it in the target's SOURCES property (that's my interpretation anyway). The
> end result is that the source you specify is going to be interpreted as
> being relative to the source directory the dependent target is defined in,
> not the directory where you called target_sources().  You can prevent the
> problem you described by ensuring the path for the source file(s) is always
> an absolute one. For example:
>
> target_sources(foo INTERFACE "${CMAKE_CURRENT_LIST_DIR}/foo.h")
>
> You may find the following blog article useful (it discusses the above
> problem and also other related material):
>
>
> https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/
>
>
>
>
> On Sun, Jul 10, 2016 at 9:03 AM, Robert Dailey 
> wrote:
>
>> I have the following:
>>
>> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
>> project(foo)
>> add_library(foo INTERFACE)
>> target_sources(foo INTERFACE foo.h)
>> add_subdirectory(subdir)
>>
>> And inside subdir, I specify add_executable() and then
>> target_link_libraries(myexe foo).
>>
>> I get an error:
>>
>> Cannot find source file: foo.h
>>
>> I'm using CMake 3.6. What am I doing wrong here?
>>
>> My goal is to generate a header-only project in Visual Studio.
>> According to the documentation, what I'm trying to do won't give me
>> that. Instead, foo.h would exist in every project that links to it as
>> a dependency (that's what it seems like anyhow).
>>
>> Advice is appreciated.
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> http://crascit.com
>



-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Unable to find source files in different directory using target_sources(INTERFACE)

2016-07-09 Thread Craig Scott
When using target_sources(), if you specify the source file(s) with a
relative path, CMake does not convert that to an absolute path when storing
it in the target's SOURCES property (that's my interpretation anyway). The
end result is that the source you specify is going to be interpreted as
being relative to the source directory the dependent target is defined in,
not the directory where you called target_sources().  You can prevent the
problem you described by ensuring the path for the source file(s) is always
an absolute one. For example:

target_sources(foo INTERFACE "${CMAKE_CURRENT_LIST_DIR}/foo.h")

You may find the following blog article useful (it discusses the above
problem and also other related material):

https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/




On Sun, Jul 10, 2016 at 9:03 AM, Robert Dailey 
wrote:

> I have the following:
>
> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> project(foo)
> add_library(foo INTERFACE)
> target_sources(foo INTERFACE foo.h)
> add_subdirectory(subdir)
>
> And inside subdir, I specify add_executable() and then
> target_link_libraries(myexe foo).
>
> I get an error:
>
> Cannot find source file: foo.h
>
> I'm using CMake 3.6. What am I doing wrong here?
>
> My goal is to generate a header-only project in Visual Studio.
> According to the documentation, what I'm trying to do won't give me
> that. Instead, foo.h would exist in every project that links to it as
> a dependency (that's what it seems like anyhow).
>
> Advice is appreciated.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Unable to find source files in different directory using target_sources(INTERFACE)

2016-07-09 Thread Robert Dailey
I have the following:

cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
project(foo)
add_library(foo INTERFACE)
target_sources(foo INTERFACE foo.h)
add_subdirectory(subdir)

And inside subdir, I specify add_executable() and then
target_link_libraries(myexe foo).

I get an error:

Cannot find source file: foo.h

I'm using CMake 3.6. What am I doing wrong here?

My goal is to generate a header-only project in Visual Studio.
According to the documentation, what I'm trying to do won't give me
that. Instead, foo.h would exist in every project that links to it as
a dependency (that's what it seems like anyhow).

Advice is appreciated.
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [CMake] Issues when cmake prints compiler messages

2016-07-09 Thread Jakob van Bethlehem
Hej Santiago,

Before being able to help you further, I guess it makes sense to fill in some 
details here: which OS, which compiler (version), which version of CMake. 
Personally I have never seen anything like this on a broad range of OS/compiler 
combinations. Also, since you suspect the background color of the terminal is 
the problem here, you could tell us about the background color you set for your 
terminal. 

Even simpler would be for you to change the background color of the terminal, 
and run the compiler again to verify whether your suspicion is correct or not.

Sincerely,
Jakob


> On 09 Jul 2016, at 12:18, Santiago Pagola  wrote:
> 
> Hello everyone!
> 
> I am new on this list, and I would like to ask if someone here has 
> experienced the same error me:
> 
> When I try to compile any project (or even simple programs), the compiler 
> starts printing information. It seems normal except for the fact that when it 
> comes to variable names, these are not shown (that is, instead of showing 
> something like:
> 
> Warning: unused parameter 'm_dummy_variable'
> 
> It shows the following:
> 
> Warning: unused parameter '   '
> 
> The thing is that, when I try to copy-paste the output from the console to a 
> text file, the variables are indeed there, which leads me to believe that the 
> variable names in the terminal may be of the same color that the background 
> of the terminal itself.
> 
> Has anyone had this little issue before? Is is something directly related 
> with cmake or is it the compiler? Any suggestions?
> 
> Thanks in advance!
> 
> Best regards,
> /Santiago
> -- 
> 
> 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] Issues when cmake prints compiler messages

2016-07-09 Thread Santiago Pagola

Hello everyone!

I am new on this list, and I would like to ask if someone here has experienced 
the same error me:

When I try to compile any project (or even simple programs), the compiler 
starts printing information. It seems normal except for the fact that when it 
comes to variable names, these are not shown (that is, instead of showing 
something like:

Warning: unused parameter 'm_dummy_variable'

It shows the following:

Warning: unused parameter '               '

The thing is that, when I try to copy-paste the output from the console to a 
text file, the variables are indeed there, which leads me to believe that the 
variable names in the terminal may be of the same color that the background of 
the terminal itself.

Has anyone had this little issue before? Is is something directly related with 
cmake or is it the compiler? Any suggestions?

Thanks in advance!

Best regards,
/Santiago-- 

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