[CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing
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
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
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)
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 Scottwrote: > 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)
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 Scottwrote: > 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)
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 Daileywrote: > 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)
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
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 Pagolawrote: > > 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
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