From mantis at public.kitware.com Fri Jan 1 10:10:47 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 2 Jan 2016 02:10:47 +1100 Subject: [cmake-developers] [CMake 0015897]: Clang CXX feature detection disabled on WIN32 platforms Message-ID: <42b46fa932464ba8eea075c32ff4d11a@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15897 ====================================================================== Reported By: Paul "TBBle" Hampson Assigned To: ====================================================================== Project: CMake Issue ID: 15897 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-02 02:10 AEDT Last Modified: 2016-01-02 02:10 AEDT ====================================================================== Summary: Clang CXX feature detection disabled on WIN32 platforms Description: When using clang from mingw64 under msys, the supplied repro case fails with: CMake Error at CMakeLists.txt:12 (target_compile_features): target_compile_features no known features for CXX compiler "Clang" version 3.7.0. This is because when Clang C++ feature detection support was added in https://cmake.org/gitweb?p=cmake.git;a=commit;h=cda233194f9caab8867b2451f3d859080a233d45 (specifically Modules/Compiler/Clang-CXX.cmake, although Modules/Compiler/Clang-C.cmake has the same conditions) the following was done: * The condition to bail out detecting a -std= flag for clang was expanded to also cover WIN32 (This breaks the CXX_STANDARD property) - line 9 * If not UNIX, no compiler features are recorded (This breaks target_compile_features) - line 52 It's not clear why these conditions were used, perhaps there's some interaction with clang-cl (Clang emulating MSVC)? If that was the case, then the first condition should be changed to test that, as done earlier in the file, rather than blocking all WIN32-based clang compilers. Steps to Reproduce: Given CMakeLists.txt: cmake_minimum_required(VERSION 3.4.1 FATAL_ERROR) project(test1 CXX) # Globally C++11 set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) file(WRITE test1.cpp "int main(int argc, char** argv) {auto x=argc; return x;}") add_executable(test1 test1.cpp) target_compile_features(test1 PRIVATE cxx_auto_type) Running the following in the MINGW64 environment of msys2 works: CXX=g++ cmake .. -G"MSYS Makefiles" && cmake --build . but the following fails to generate: CXX=clang++ cmake .. -G"MSYS Makefiles" && cmake --build . If the target_compile_features directive is removed, then both generate, but the latter will fail to build, noting that 'auto' is a C++11 feature. Test based on https://cmake.org/pipermail/cmake/2015-January/059593.html Additional Information: I tested that removing the WIN32 and UNIX parts of the conditionals I mentioned got MSYS working, but I don't happen to have clang-cl installed to verify that it wasn't broken by doing this. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-02 02:10 Paul "TBBle" HampsonNew Issue ====================================================================== From mantis at public.kitware.com Sat Jan 2 05:18:01 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 2 Jan 2016 05:18:01 -0500 Subject: [cmake-developers] [CMake 0015898]: CMake must provide a magic method to do right escaping of commands being executed in shell Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15898 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15898 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-02 05:18 EST Last Modified: 2016-01-02 05:18 EST ====================================================================== Summary: CMake must provide a magic method to do right escaping of commands being executed in shell Description: Right now it's very hard to write a command that should be executed in shell and will work on various platforms. Here is the notable example we came across recently: https://gist.github.com/Kentzo/00198d5cfc03ebdedddf CMake should provide a function or some way to specify a literal that will be correctly escaped according to the rules of the shell where the command will be executed. Additional Information: https://gist.github.com/Kentzo/00198d5cfc03ebdedddf ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-02 05:18 Ilya New Issue ====================================================================== From mantis at public.kitware.com Sat Jan 2 14:14:07 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 2 Jan 2016 14:14:07 -0500 Subject: [cmake-developers] [CMake 0015899]: The DragNDrop CPack generator has an off-by-one in its code line-wrapping LICENSE files configured in CPack Message-ID: <7c69b62ea1a23e9c6bcc14b13c7b529b@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15899 ====================================================================== Reported By: Andrey M. Mishchenko Assigned To: ====================================================================== Project: CMake Issue ID: 15899 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-02 14:14 EST Last Modified: 2016-01-02 14:14 EST ====================================================================== Summary: The DragNDrop CPack generator has an off-by-one in its code line-wrapping LICENSE files configured in CPack Description: The package target fails to build given the simple CMakeLists.txt and license.txt attached. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-02 14:14 Andrey M. MishchenkoNew Issue 2016-01-02 14:14 Andrey M. MishchenkoFile Added: CMakeLists.txt ====================================================================== From mishchea at gmail.com Sat Jan 2 16:11:00 2016 From: mishchea at gmail.com (Andrey Mishchenko) Date: Sat, 2 Jan 2016 16:11:00 -0500 Subject: [cmake-developers] [PATCH] Fix some bugs in CPack's DragNDrop generator's handling of LICENSE files Message-ID: There were issues in the special-character-escaping and line-wrapping code which caused DragNDrop packaging to fail mysteriously at a later step with parsing errors in the sla.r file generated by the following code. --- Source/CPack/cmCPackDragNDropGenerator.cxx | 89 +++++++++++++++++++++++------- Source/CPack/cmCPackDragNDropGenerator.h | 12 ++-- 2 files changed, 76 insertions(+), 25 deletions(-) diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx b/Source/CPack/cmCPackDragNDropGenerator.cxx index 1a694ea..2413b7f 100644 --- a/Source/CPack/cmCPackDragNDropGenerator.cxx +++ b/Source/CPack/cmCPackDragNDropGenerator.cxx @@ -693,27 +693,48 @@ int cmCPackDragNDropGenerator::CreateDMG(const std::string& src_dir, ofs << std::dec << std::nouppercase << std::setfill(' '); } + bool have_write_license_error = false; + std::string error; + if(oldStyle) { - WriteLicense(ofs, 0, "", cpack_license_file); + if(!this->WriteLicense(ofs, 0, "", cpack_license_file, &error)) + { + have_write_license_error = true; + } } else { - for(size_t i = 0; i < languages.size(); ++i) + for(size_t i = 0; i < languages.size() && !have_write_license_error; ++i) { if(singleLicense) { - WriteLicense(ofs, i + 5000, languages[i], cpack_license_file); + if(!this->WriteLicense(ofs, i + 5000, languages[i], cpack_license_file, &error)) + { + have_write_license_error = true; + } } else { - WriteLicense(ofs, i + 5000, languages[i]); + if(!this->WriteLicense(ofs, i + 5000, languages[i], "", &error)) + { + have_write_license_error = true; + } } } } ofs.Close(); + if(have_write_license_error) + { + cmCPackLogger(cmCPackLog::LOG_ERROR, + "Error writing license file to SLA." << std::endl + << error + << std::endl); + return 0; + } + // convert to UDCO std::string temp_udco = this->GetOption("CPACK_TOPLEVEL_DIRECTORY"); temp_udco += "/temp-udco.dmg"; @@ -724,7 +745,6 @@ int cmCPackDragNDropGenerator::CreateDMG(const std::string& src_dir, udco_image_command << " -format UDCO"; udco_image_command << " -ov -o \"" << temp_udco << "\""; - std::string error; if(!this->RunCommand(udco_image_command, &error)) { cmCPackLogger(cmCPackLog::LOG_ERROR, @@ -855,9 +875,10 @@ cmCPackDragNDropGenerator::GetComponentInstallDirNameSuffix( return GetComponentPackageFileName(package_file_name, componentName, false); } -void +bool cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, - int licenseNumber, std::string licenseLanguage, std::string licenseFile) + int licenseNumber, std::string licenseLanguage, std::string licenseFile, + std::string *error) { if(!licenseFile.empty() && !singleLicense) { @@ -881,9 +902,12 @@ cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, std::getline(license_ifs, line); if(!line.empty()) { - EscapeQuotes(line); + EscapeQuotesAndBackslashes(line); std::vector lines; - BreakLongLine(line, lines); + if(!this->BreakLongLine(line, lines, error)) + { + return false; + } for(size_t i = 0; i < lines.size(); ++i) { outputStream << " \"" << lines[i] << "\"\n"; @@ -920,9 +944,12 @@ cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, std::getline(menu_ifs, line); if(!line.empty()) { - EscapeQuotes(line); + EscapeQuotesAndBackslashes(line); std::vector lines; - BreakLongLine(line, lines); + if(!this->BreakLongLine(line, lines, error)) + { + return false; + } for(size_t i = 0; i < lines.size(); ++i) { std::string comma; @@ -949,31 +976,53 @@ cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, outputStream << "};\n"; outputStream << "\n"; } + + return true; } -void +bool cmCPackDragNDropGenerator::BreakLongLine(const std::string& line, - std::vector& lines) + std::vector& lines, std::string *error) { const size_t max_line_length = 512; for(size_t i = 0; i < line.size(); i += max_line_length) { - int line_length = max_line_length; - if(i + max_line_length > line.size()) + size_t line_length = max_line_length; + if(i + line_length > line.size()) { line_length = line.size() - i; } + else while(line_length > 0 && line[i + line_length - 1] != ' ') + { + line_length = line_length - 1; + } + + if(line_length == 0) + { + *error = "Please make sure there are no words " + "(or character sequences not broken up by spaces or newlines) " + "in your license file which are more than 512 characters long."; + return false; + } lines.push_back(line.substr(i, line_length)); } + return true; } void -cmCPackDragNDropGenerator::EscapeQuotes(std::string& line) +cmCPackDragNDropGenerator::EscapeQuotesAndBackslashes(std::string& line) { - std::string::size_type pos = line.find('\"'); - while(pos != std::string::npos) + std::string::size_type backslash_pos = line.find('\\'); + while(backslash_pos != std::string::npos) + { + line.replace(backslash_pos, 1, "\\\\"); + backslash_pos = line.find('\\', backslash_pos + 2); + } + + std::string::size_type quote_pos = line.find('\"'); + while(quote_pos != std::string::npos) { - line.replace(pos, 1, "\\\""); - pos = line.find('\"', pos + 2); + line.replace(quote_pos, 1, "\\\""); + quote_pos = line.find('\"', quote_pos + 2); } } diff --git a/Source/CPack/cmCPackDragNDropGenerator.h b/Source/CPack/cmCPackDragNDropGenerator.h index b5e5ffe..604cdf5 100644 --- a/Source/CPack/cmCPackDragNDropGenerator.h +++ b/Source/CPack/cmCPackDragNDropGenerator.h @@ -50,11 +50,13 @@ private: std::string slaDirectory; bool singleLicense; - void WriteLicense(cmGeneratedFileStream& outputStream, int licenseNumber, - std::string licenseLanguage, std::string licenseFile = ""); - void BreakLongLine(const std::string& line, - std::vector& lines); - void EscapeQuotes(std::string& line); + bool WriteLicense(cmGeneratedFileStream& outputStream, int licenseNumber, + std::string licenseLanguage, std::string licenseFile, + std::string *error); + bool BreakLongLine(const std::string& line, + std::vector& lines, + std::string *error); + void EscapeQuotesAndBackslashes(std::string& line); }; #endif -- 2.5.4 (Apple Git-61) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mishchea at gmail.com Sat Jan 2 16:16:04 2016 From: mishchea at gmail.com (Andrey Mishchenko) Date: Sat, 2 Jan 2016 16:16:04 -0500 Subject: [cmake-developers] [PATCH] Fix some bugs in CPack's DragNDrop generator's handling of LICENSE files In-Reply-To: References: Message-ID: I forgot to note that this patch "addresses" https://cmake.org/Bug/view.php?id=15899. On Sat, Jan 2, 2016 at 4:11 PM, Andrey Mishchenko wrote: > There were issues in the special-character-escaping and line-wrapping code > which caused DragNDrop packaging to fail mysteriously at a later step with > parsing errors in the sla.r file generated by the following code. > > --- > Source/CPack/cmCPackDragNDropGenerator.cxx | 89 > +++++++++++++++++++++++------- > Source/CPack/cmCPackDragNDropGenerator.h | 12 ++-- > 2 files changed, 76 insertions(+), 25 deletions(-) > > diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx > b/Source/CPack/cmCPackDragNDropGenerator.cxx > index 1a694ea..2413b7f 100644 > --- a/Source/CPack/cmCPackDragNDropGenerator.cxx > +++ b/Source/CPack/cmCPackDragNDropGenerator.cxx > @@ -693,27 +693,48 @@ int cmCPackDragNDropGenerator::CreateDMG(const > std::string& src_dir, > ofs << std::dec << std::nouppercase << std::setfill(' '); > } > > + bool have_write_license_error = false; > + std::string error; > + > if(oldStyle) > { > - WriteLicense(ofs, 0, "", cpack_license_file); > + if(!this->WriteLicense(ofs, 0, "", cpack_license_file, &error)) > + { > + have_write_license_error = true; > + } > } > else > { > - for(size_t i = 0; i < languages.size(); ++i) > + for(size_t i = 0; i < languages.size() && > !have_write_license_error; ++i) > { > if(singleLicense) > { > - WriteLicense(ofs, i + 5000, languages[i], cpack_license_file); > + if(!this->WriteLicense(ofs, i + 5000, languages[i], > cpack_license_file, &error)) > + { > + have_write_license_error = true; > + } > } > else > { > - WriteLicense(ofs, i + 5000, languages[i]); > + if(!this->WriteLicense(ofs, i + 5000, languages[i], "", &error)) > + { > + have_write_license_error = true; > + } > } > } > } > > ofs.Close(); > > + if(have_write_license_error) > + { > + cmCPackLogger(cmCPackLog::LOG_ERROR, > + "Error writing license file to SLA." << std::endl > + << error > + << std::endl); > + return 0; > + } > + > // convert to UDCO > std::string temp_udco = this->GetOption("CPACK_TOPLEVEL_DIRECTORY"); > temp_udco += "/temp-udco.dmg"; > @@ -724,7 +745,6 @@ int cmCPackDragNDropGenerator::CreateDMG(const > std::string& src_dir, > udco_image_command << " -format UDCO"; > udco_image_command << " -ov -o \"" << temp_udco << "\""; > > - std::string error; > if(!this->RunCommand(udco_image_command, &error)) > { > cmCPackLogger(cmCPackLog::LOG_ERROR, > @@ -855,9 +875,10 @@ > cmCPackDragNDropGenerator::GetComponentInstallDirNameSuffix( > return GetComponentPackageFileName(package_file_name, componentName, > false); > } > > -void > +bool > cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& > outputStream, > - int licenseNumber, std::string licenseLanguage, std::string licenseFile) > + int licenseNumber, std::string licenseLanguage, std::string licenseFile, > + std::string *error) > { > if(!licenseFile.empty() && !singleLicense) > { > @@ -881,9 +902,12 @@ > cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, > std::getline(license_ifs, line); > if(!line.empty()) > { > - EscapeQuotes(line); > + EscapeQuotesAndBackslashes(line); > std::vector lines; > - BreakLongLine(line, lines); > + if(!this->BreakLongLine(line, lines, error)) > + { > + return false; > + } > for(size_t i = 0; i < lines.size(); ++i) > { > outputStream << " \"" << lines[i] << "\"\n"; > @@ -920,9 +944,12 @@ > cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, > std::getline(menu_ifs, line); > if(!line.empty()) > { > - EscapeQuotes(line); > + EscapeQuotesAndBackslashes(line); > std::vector lines; > - BreakLongLine(line, lines); > + if(!this->BreakLongLine(line, lines, error)) > + { > + return false; > + } > for(size_t i = 0; i < lines.size(); ++i) > { > std::string comma; > @@ -949,31 +976,53 @@ > cmCPackDragNDropGenerator::WriteLicense(cmGeneratedFileStream& outputStream, > outputStream << "};\n"; > outputStream << "\n"; > } > + > + return true; > } > > -void > +bool > cmCPackDragNDropGenerator::BreakLongLine(const std::string& line, > - std::vector& lines) > + std::vector& lines, std::string *error) > { > const size_t max_line_length = 512; > for(size_t i = 0; i < line.size(); i += max_line_length) > { > - int line_length = max_line_length; > - if(i + max_line_length > line.size()) > + size_t line_length = max_line_length; > + if(i + line_length > line.size()) > { > line_length = line.size() - i; > } > + else while(line_length > 0 && line[i + line_length - 1] != ' ') > + { > + line_length = line_length - 1; > + } > + > + if(line_length == 0) > + { > + *error = "Please make sure there are no words " > + "(or character sequences not broken up by spaces or > newlines) " > + "in your license file which are more than 512 characters > long."; > + return false; > + } > lines.push_back(line.substr(i, line_length)); > } > + return true; > } > > void > -cmCPackDragNDropGenerator::EscapeQuotes(std::string& line) > +cmCPackDragNDropGenerator::EscapeQuotesAndBackslashes(std::string& line) > { > - std::string::size_type pos = line.find('\"'); > - while(pos != std::string::npos) > + std::string::size_type backslash_pos = line.find('\\'); > + while(backslash_pos != std::string::npos) > + { > + line.replace(backslash_pos, 1, "\\\\"); > + backslash_pos = line.find('\\', backslash_pos + 2); > + } > + > + std::string::size_type quote_pos = line.find('\"'); > + while(quote_pos != std::string::npos) > { > - line.replace(pos, 1, "\\\""); > - pos = line.find('\"', pos + 2); > + line.replace(quote_pos, 1, "\\\""); > + quote_pos = line.find('\"', quote_pos + 2); > } > } > diff --git a/Source/CPack/cmCPackDragNDropGenerator.h > b/Source/CPack/cmCPackDragNDropGenerator.h > index b5e5ffe..604cdf5 100644 > --- a/Source/CPack/cmCPackDragNDropGenerator.h > +++ b/Source/CPack/cmCPackDragNDropGenerator.h > @@ -50,11 +50,13 @@ private: > std::string slaDirectory; > bool singleLicense; > > - void WriteLicense(cmGeneratedFileStream& outputStream, int > licenseNumber, > - std::string licenseLanguage, std::string licenseFile = ""); > - void BreakLongLine(const std::string& line, > - std::vector& lines); > - void EscapeQuotes(std::string& line); > + bool WriteLicense(cmGeneratedFileStream& outputStream, int > licenseNumber, > + std::string licenseLanguage, std::string licenseFile, > + std::string *error); > + bool BreakLongLine(const std::string& line, > + std::vector& lines, > + std::string *error); > + void EscapeQuotesAndBackslashes(std::string& line); > }; > > #endif > -- > 2.5.4 (Apple Git-61) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Jan 2 19:20:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 2 Jan 2016 19:20:15 -0500 Subject: [cmake-developers] [CMake 0015900]: Problem with Cmake and VStudio 2013 in windows 7/64 plaform Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15900 ====================================================================== Reported By: Taher Assigned To: ====================================================================== Project: CMake Issue ID: 15900 Category: (No Category) Reproducibility: have not tried Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-02 19:20 EST Last Modified: 2016-01-02 19:20 EST ====================================================================== Summary: Problem with Cmake and VStudio 2013 in windows 7/64 plaform Description: CMake Error: install(EXPORT "OpenCVModules" ...) includes target "opencv_world" which requires target "zlib" that is not in the export set. CMake Error: install(EXPORT "OpenCVModules" ...) includes target "opencv_world" which requires target "libjpeg" that is not in the export set. CMake Error: install(EXPORT "OpenCVModules" ...) includes target "opencv_world" which requires target "libpng" that is not in the export set. Steps to Reproduce: How to solve these. Additional Information: I am badly in such problem ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-02 19:20 Taher New Issue ====================================================================== From steveire at gmail.com Sun Jan 3 19:16:00 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 04 Jan 2016 01:16 +0100 Subject: [cmake-developers] Using CMake as a library from Python References: Message-ID: Charles Huet wrote: > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure > cannot be used from python (it check for the existence of a CMakeLists.txt > file, which does not exist in this scenario) and the cache variables it > sets seem to be necessary. Because of the above, I worry that you are basing your work on an old version of CMake. As of April 2015 cmState is used as the interface to the cache. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 Also note that the C++ interfaces in CMake are not stable. In the last year they have been changed utterly and that will continue to happen without notice. I'm sure you know this, but I thought I'd say it anyway. > I will try to make a layer of abstraction on top of the python bindings > before publishing this work on github, in order to show the syntactic > sugar python can provide, but I will publish this before if anybody is > interested in working on this. I would be interested in seeing it. > Now, does anyone beside me think this is a good idea ? I did something similar some years ago with QML instead of python, so it sounds interesting to me. In fact, one of the reasons for introducing cmState and doing all the refactoring I did in cmake was to make it possible to cleanly replace the language, some day. My guess is that you are using python to instantiate a cmAddLibraryCommand and then executing it. I think a better approach would be to leave all the cm*Command classes behind as they carry a lot of backward compatibility baggage and policies which a new language shouldn't be burdened with. Even much of cmMakefile shouldn't be used by a new language. Instead certain parts of cmMakefile should be extracted as other classes (cmVariableExpander which should have the ExpandVariablesInString and ConfigureString stuff, cmMessenger for the IssueMessage stuff, some other class for the CompileFeature stuff etc). Then cmMakefile would be just about executing and scoping the CMake language. A new language would not need that, but would use the refactored extracted classes. So, you would implement new cmPython*Command or whatever which operate on those classes and cmState. cmState is designed to be a language-agnostic store of data, like a database of buildsystem state. As I said though, this would require further refactoring of the cmake code. I can provide guidance on how to do that if you are interested in pursuing that route. It would take some months I think, but be very valuable for many reasons and long-term cmake features. Another example of the kind of refactoring I mean is putting target state in cmState and making it accessible through cmState::Target, similar to how cmState::Directory currently works. Having said all that, Brad favors Lua I believe, and he favors a different approach (which no one is working on as far as I know) to adding a new language. So wait to hear from him to know whether it is something that would be upstreamable. I would prefer an approach similar to what I described above, which is close to what you are doing, so as a proof of concept I would like to see your work. I would guide/support you in refactoring cmake as needed. The refactoring part would definitely be upstreamable. I would very much like to see a proof of concept alternative language even if that wasn't upstreamed. It would prove that another language is possible, and that's one of the steps to replacing the current cmake language I think. Thanks, Steve. From charles.huet at gmail.com Mon Jan 4 02:41:47 2016 From: charles.huet at gmail.com (Charles Huet) Date: Mon, 4 Jan 2016 08:41:47 +0100 Subject: [cmake-developers] Using CMake as a library from Python In-Reply-To: References: Message-ID: Hi, Because of the above, I worry that you are basing your work on an old > version of CMake. As of April 2015 cmState is used as the interface to the > cache. Yeah, that is sadly right. I wanted to rebase on master before publishing, thinking it should not be too hard, and I have lots to re-do, mostly understand how things are done now. I did something similar some years ago with QML instead of python, so it > sounds interesting to me. I'm trying to be as declarative as possible, because really like how readable simple QML programs are, and I think it would be perfect for a buildsystem. My guess is that you are using python to instantiate a cmAddLibraryCommand > and then executing it. Actually, I'm directly using the cmMakefile, because I did not want to wrap all the commands, and it seemed backwards to me to wrap them. Even much of cmMakefile shouldn't be used by a new language. Instead certain > parts of cmMakefile should be extracted as other classes > (cmVariableExpander > which should have the ExpandVariablesInString and ConfigureString stuff, > cmMessenger for the IssueMessage stuff, some other class for the > CompileFeature stuff etc). Then cmMakefile would be just about executing > and > scoping the CMake language. A new language would not need that, but would > use the refactored extracted classes. Ah, this is very interesting, thanks. Having said all that, Brad favors Lua I believe, and he favors a different > approach (which no one is working on as far as I know) to adding a new > language. So wait to hear from him to know whether it is something that > would be upstreamable. Have any details on the approach in question ? SWIG would allow for Lua bindings as easily, but I don't think having multiple languages would be a good idea. I went with Python because I'm familiar with it and have already written bindings for it with SWIG. Also, buildbot is written in python and it could provide a really interesting integration I think. I would guide/support you in refactoring cmake as needed. The refactoring > part would definitely be upstreamable. I would very much like to see a > proof > of concept alternative language even if that wasn't upstreamed. It would > prove that another language is possible, and that's one of the steps to > replacing the current cmake language I think. I will need to work on it to make it work again with master, but I'll try and do this soon. Here is what my test POC looked like for generating a simple shared library: #!/usr/bin/env python > # -*- coding: utf-8 -*- > import cmake > cmake.init("Ninja", "/media/dev/src/cmaketest", > "/media/dev/build/cmaketest") > myProject = cmake.Project("MyTestProject") > myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] > cmake.generate() Thanks a lot for your comments, I'm happy to see this was not just a dumb idea, and that others have thought about it. I'll update with the github as soon as I get it working. Best Le lun. 4 janv. 2016 ? 01:16, Stephen Kelly a ?crit : > Charles Huet wrote: > > > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure > > cannot be used from python (it check for the existence of a > CMakeLists.txt > > file, which does not exist in this scenario) and the cache variables it > > sets seem to be necessary. > > Because of the above, I worry that you are basing your work on an old > version of CMake. As of April 2015 cmState is used as the interface to the > cache. > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 > > Also note that the C++ interfaces in CMake are not stable. In the last year > they have been changed utterly and that will continue to happen without > notice. I'm sure you know this, but I thought I'd say it anyway. > > > I will try to make a layer of abstraction on top of the python bindings > > before publishing this work on github, in order to show the syntactic > > sugar python can provide, but I will publish this before if anybody is > > interested in working on this. > > I would be interested in seeing it. > > > Now, does anyone beside me think this is a good idea ? > > I did something similar some years ago with QML instead of python, so it > sounds interesting to me. > > In fact, one of the reasons for introducing cmState and doing all the > refactoring I did in cmake was to make it possible to cleanly replace the > language, some day. > > My guess is that you are using python to instantiate a cmAddLibraryCommand > and then executing it. I think a better approach would be to leave all the > cm*Command classes behind as they carry a lot of backward compatibility > baggage and policies which a new language shouldn't be burdened with. > > Even much of cmMakefile shouldn't be used by a new language. Instead > certain > parts of cmMakefile should be extracted as other classes > (cmVariableExpander > which should have the ExpandVariablesInString and ConfigureString stuff, > cmMessenger for the IssueMessage stuff, some other class for the > CompileFeature stuff etc). Then cmMakefile would be just about executing > and > scoping the CMake language. A new language would not need that, but would > use the refactored extracted classes. > > So, you would implement new cmPython*Command or whatever which operate on > those classes and cmState. cmState is designed to be a language-agnostic > store of data, like a database of buildsystem state. > > As I said though, this would require further refactoring of the cmake code. > I can provide guidance on how to do that if you are interested in pursuing > that route. It would take some months I think, but be very valuable for > many > reasons and long-term cmake features. Another example of the kind of > refactoring I mean is putting target state in cmState and making it > accessible through cmState::Target, similar to how cmState::Directory > currently works. > > Having said all that, Brad favors Lua I believe, and he favors a different > approach (which no one is working on as far as I know) to adding a new > language. So wait to hear from him to know whether it is something that > would be upstreamable. > > I would prefer an approach similar to what I described above, which is > close > to what you are doing, so as a proof of concept I would like to see your > work. > > I would guide/support you in refactoring cmake as needed. The refactoring > part would definitely be upstreamable. I would very much like to see a > proof > of concept alternative language even if that wasn't upstreamed. It would > prove that another language is possible, and that's one of the steps to > replacing the current cmake language I think. > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Mon Jan 4 03:50:02 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 4 Jan 2016 03:50:02 -0500 Subject: [cmake-developers] [CMake 0015901]: `-Og` dose not produce debug symbol in CMake Message-ID: <974c38a4010b522c779eac84d9b4a063@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15901 ====================================================================== Reported By: acgtyrant Assigned To: ====================================================================== Project: CMake Issue ID: 15901 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-04 03:50 EST Last Modified: 2016-01-04 03:50 EST ====================================================================== Summary: `-Og` dose not produce debug symbol in CMake Description: Use `-Og` in CMAKE_CXX_FLAGS, the compiled result does not contain any `.debug_*` section. Steps to Reproduce: CMakeList.txt: set(CMAKE_CXX_FLAGS "-std=c++11 -Wall -Wextra -Og") add_executable(Demo tmp.cc) tmp.cc: #include int main(void) { std::cout << "Hello, world" << std::endl; return 0; } Put CMakeList.txt and tmp.cc in the same directory, then execute `cmake .; make; objdump -h Demo | grep .debug`, no result. For comparison, I compile the tmp.cc by myself: `g++ -std=c++11 -Wall -Wextra -Og tmp.cc; objdump -h a.out | grep .debug`. It returns: 26 .debug_aranges 00000030 0000000000000000 0000000000000000 00000d32 2**0 27 .debug_info 00002a64 0000000000000000 0000000000000000 00000d62 2**0 28 .debug_abbrev 00000651 0000000000000000 0000000000000000 000037c6 2**0 29 .debug_line 00000372 0000000000000000 0000000000000000 00003e17 2**0 30 .debug_str 00001a02 0000000000000000 0000000000000000 00004189 2**0 31 .debug_loc 0000009e 0000000000000000 0000000000000000 00005b8b 2**0 Additional Information: $ LANG=C gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-04 03:50 acgtyrant New Issue ====================================================================== From charles.huet at gmail.com Mon Jan 4 05:11:36 2016 From: charles.huet at gmail.com (Charles Huet) Date: Mon, 04 Jan 2016 10:11:36 +0000 Subject: [cmake-developers] Using CMake as a library from Python In-Reply-To: References: Message-ID: I took the time to make it work again, so I pushed it here: https://github.com/packadal/CMake/tree/cmake-python The whole branch is ugly as can be, and because I started with an old CMake and recently rebased, the python abstraction might be bloated already, but it works in the nominal case, and it would be pretty easy to add most of the CMake basic functionalities. I am not used to writing python, so it might not be idiomatic either, but hey, it works as a simple proof of concept, and it's all I wanted to do for now :) Le lun. 4 janv. 2016 ? 08:41, Charles Huet a ?crit : > Hi, > > Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. > > > Yeah, that is sadly right. I wanted to rebase on master before publishing, > thinking it should not be too hard, and I have lots to re-do, mostly > understand how things are done now. > > I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. > > > I'm trying to be as declarative as possible, because really like how > readable simple QML programs are, and I think it would be perfect for a > buildsystem. > > My guess is that you are using python to instantiate a cmAddLibraryCommand >> and then executing it. > > > Actually, I'm directly using the cmMakefile, because I did not want to > wrap all the commands, and it seemed backwards to me to wrap them. > > Even much of cmMakefile shouldn't be used by a new language. Instead >> certain >> parts of cmMakefile should be extracted as other classes >> (cmVariableExpander >> which should have the ExpandVariablesInString and ConfigureString stuff, >> cmMessenger for the IssueMessage stuff, some other class for the >> CompileFeature stuff etc). Then cmMakefile would be just about executing >> and >> scoping the CMake language. A new language would not need that, but would >> use the refactored extracted classes. > > > Ah, this is very interesting, thanks. > > > Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. > > > Have any details on the approach in question ? SWIG would allow for Lua > bindings as easily, but I don't think having multiple languages would be a > good idea. > I went with Python because I'm familiar with it and have already written > bindings for it with SWIG. Also, buildbot is written in python and it could > provide a really interesting integration I think. > > I would guide/support you in refactoring cmake as needed. The refactoring >> part would definitely be upstreamable. I would very much like to see a >> proof >> of concept alternative language even if that wasn't upstreamed. It would >> prove that another language is possible, and that's one of the steps to >> replacing the current cmake language I think. > > > I will need to work on it to make it work again with master, but I'll try > and do this soon. > > Here is what my test POC looked like for generating a simple shared > library: > > #!/usr/bin/env python >> # -*- coding: utf-8 -*- >> import cmake >> cmake.init("Ninja", "/media/dev/src/cmaketest", >> "/media/dev/build/cmaketest") >> myProject = cmake.Project("MyTestProject") >> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] >> cmake.generate() > > > Thanks a lot for your comments, I'm happy to see this was not just a dumb > idea, and that others have thought about it. > > I'll update with the github as soon as I get it working. > > Best > > > Le lun. 4 janv. 2016 ? 01:16, Stephen Kelly a ?crit : > >> Charles Huet wrote: >> >> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure >> > cannot be used from python (it check for the existence of a >> CMakeLists.txt >> > file, which does not exist in this scenario) and the cache variables it >> > sets seem to be necessary. >> >> Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. >> >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 >> >> Also note that the C++ interfaces in CMake are not stable. In the last >> year >> they have been changed utterly and that will continue to happen without >> notice. I'm sure you know this, but I thought I'd say it anyway. >> >> > I will try to make a layer of abstraction on top of the python bindings >> > before publishing this work on github, in order to show the syntactic >> > sugar python can provide, but I will publish this before if anybody is >> > interested in working on this. >> >> I would be interested in seeing it. >> >> > Now, does anyone beside me think this is a good idea ? >> >> I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. >> >> In fact, one of the reasons for introducing cmState and doing all the >> refactoring I did in cmake was to make it possible to cleanly replace the >> language, some day. >> >> My guess is that you are using python to instantiate a cmAddLibraryCommand >> and then executing it. I think a better approach would be to leave all the >> cm*Command classes behind as they carry a lot of backward compatibility >> baggage and policies which a new language shouldn't be burdened with. >> >> Even much of cmMakefile shouldn't be used by a new language. Instead >> certain >> parts of cmMakefile should be extracted as other classes >> (cmVariableExpander >> which should have the ExpandVariablesInString and ConfigureString stuff, >> cmMessenger for the IssueMessage stuff, some other class for the >> CompileFeature stuff etc). Then cmMakefile would be just about executing >> and >> scoping the CMake language. A new language would not need that, but would >> use the refactored extracted classes. >> >> So, you would implement new cmPython*Command or whatever which operate on >> those classes and cmState. cmState is designed to be a language-agnostic >> store of data, like a database of buildsystem state. >> >> As I said though, this would require further refactoring of the cmake >> code. >> I can provide guidance on how to do that if you are interested in pursuing >> that route. It would take some months I think, but be very valuable for >> many >> reasons and long-term cmake features. Another example of the kind of >> refactoring I mean is putting target state in cmState and making it >> accessible through cmState::Target, similar to how cmState::Directory >> currently works. >> >> Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. >> >> I would prefer an approach similar to what I described above, which is >> close >> to what you are doing, so as a proof of concept I would like to see your >> work. >> >> I would guide/support you in refactoring cmake as needed. The refactoring >> part would definitely be upstreamable. I would very much like to see a >> proof >> of concept alternative language even if that wasn't upstreamed. It would >> prove that another language is possible, and that's one of the steps to >> replacing the current cmake language I think. >> >> Thanks, >> >> Steve. >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Mon Jan 4 05:54:48 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Mon, 4 Jan 2016 11:54:48 +0100 Subject: [cmake-developers] Using CMake as a library from Python In-Reply-To: References: Message-ID: Charles, I'd like to comment on a minor issue: CMakeLists.txt files don't specify user-specific data like source and build dirs (for a reason) yet your POC listfile contains this line: cmake.init("Ninja", "/media/dev/src/cmaketest", "/media/dev/build/cmaketest") which sets the source and build directories. Is this some temporary solution for the POC only? Tamas On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet wrote: > Hi, > > Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. > > > Yeah, that is sadly right. I wanted to rebase on master before publishing, > thinking it should not be too hard, and I have lots to re-do, mostly > understand how things are done now. > > I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. > > > I'm trying to be as declarative as possible, because really like how > readable simple QML programs are, and I think it would be perfect for a > buildsystem. > > My guess is that you are using python to instantiate a cmAddLibraryCommand >> and then executing it. > > > Actually, I'm directly using the cmMakefile, because I did not want to > wrap all the commands, and it seemed backwards to me to wrap them. > > Even much of cmMakefile shouldn't be used by a new language. Instead >> certain >> parts of cmMakefile should be extracted as other classes >> (cmVariableExpander >> which should have the ExpandVariablesInString and ConfigureString stuff, >> cmMessenger for the IssueMessage stuff, some other class for the >> CompileFeature stuff etc). Then cmMakefile would be just about executing >> and >> scoping the CMake language. A new language would not need that, but would >> use the refactored extracted classes. > > > Ah, this is very interesting, thanks. > > > Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. > > > Have any details on the approach in question ? SWIG would allow for Lua > bindings as easily, but I don't think having multiple languages would be a > good idea. > I went with Python because I'm familiar with it and have already written > bindings for it with SWIG. Also, buildbot is written in python and it could > provide a really interesting integration I think. > > I would guide/support you in refactoring cmake as needed. The refactoring >> part would definitely be upstreamable. I would very much like to see a >> proof >> of concept alternative language even if that wasn't upstreamed. It would >> prove that another language is possible, and that's one of the steps to >> replacing the current cmake language I think. > > > I will need to work on it to make it work again with master, but I'll try > and do this soon. > > Here is what my test POC looked like for generating a simple shared > library: > > #!/usr/bin/env python >> # -*- coding: utf-8 -*- >> import cmake >> cmake.init("Ninja", "/media/dev/src/cmaketest", >> "/media/dev/build/cmaketest") >> myProject = cmake.Project("MyTestProject") >> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] >> cmake.generate() > > > Thanks a lot for your comments, I'm happy to see this was not just a dumb > idea, and that others have thought about it. > > I'll update with the github as soon as I get it working. > > Best > > > Le lun. 4 janv. 2016 ? 01:16, Stephen Kelly a ?crit : > >> Charles Huet wrote: >> >> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure >> > cannot be used from python (it check for the existence of a >> CMakeLists.txt >> > file, which does not exist in this scenario) and the cache variables it >> > sets seem to be necessary. >> >> Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. >> >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 >> >> Also note that the C++ interfaces in CMake are not stable. In the last >> year >> they have been changed utterly and that will continue to happen without >> notice. I'm sure you know this, but I thought I'd say it anyway. >> >> > I will try to make a layer of abstraction on top of the python bindings >> > before publishing this work on github, in order to show the syntactic >> > sugar python can provide, but I will publish this before if anybody is >> > interested in working on this. >> >> I would be interested in seeing it. >> >> > Now, does anyone beside me think this is a good idea ? >> >> I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. >> >> In fact, one of the reasons for introducing cmState and doing all the >> refactoring I did in cmake was to make it possible to cleanly replace the >> language, some day. >> >> My guess is that you are using python to instantiate a cmAddLibraryCommand >> and then executing it. I think a better approach would be to leave all the >> cm*Command classes behind as they carry a lot of backward compatibility >> baggage and policies which a new language shouldn't be burdened with. >> >> Even much of cmMakefile shouldn't be used by a new language. Instead >> certain >> parts of cmMakefile should be extracted as other classes >> (cmVariableExpander >> which should have the ExpandVariablesInString and ConfigureString stuff, >> cmMessenger for the IssueMessage stuff, some other class for the >> CompileFeature stuff etc). Then cmMakefile would be just about executing >> and >> scoping the CMake language. A new language would not need that, but would >> use the refactored extracted classes. >> >> So, you would implement new cmPython*Command or whatever which operate on >> those classes and cmState. cmState is designed to be a language-agnostic >> store of data, like a database of buildsystem state. >> >> As I said though, this would require further refactoring of the cmake >> code. >> I can provide guidance on how to do that if you are interested in pursuing >> that route. It would take some months I think, but be very valuable for >> many >> reasons and long-term cmake features. Another example of the kind of >> refactoring I mean is putting target state in cmState and making it >> accessible through cmState::Target, similar to how cmState::Directory >> currently works. >> >> Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. >> >> I would prefer an approach similar to what I described above, which is >> close >> to what you are doing, so as a proof of concept I would like to see your >> work. >> >> I would guide/support you in refactoring cmake as needed. The refactoring >> part would definitely be upstreamable. I would very much like to see a >> proof >> of concept alternative language even if that wasn't upstreamed. It would >> prove that another language is possible, and that's one of the steps to >> replacing the current cmake language I think. >> >> Thanks, >> >> Steve. >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.huet at gmail.com Mon Jan 4 05:58:30 2016 From: charles.huet at gmail.com (Charles Huet) Date: Mon, 04 Jan 2016 10:58:30 +0000 Subject: [cmake-developers] Using CMake as a library from Python In-Reply-To: References: Message-ID: Yes, this is POC-only. I felt too lazy to make an argparse object and properly perform these tasks. Obviously, the generator and source dir should be arguments. The build dir should be the execution dir of the script, to mimic CMake behavior. This should not be difficult, but as I said I wanted first to get this disussion started. Le lun. 4 janv. 2016 ? 11:54, Tam?s Ken?z a ?crit : > Charles, > > I'd like to comment on a minor issue: > > CMakeLists.txt files don't specify user-specific data like source and > build dirs (for a reason) yet your POC listfile contains this line: > > cmake.init("Ninja", "/media/dev/src/cmaketest", > "/media/dev/build/cmaketest") > > which sets the source and build directories. Is this some temporary > solution for the POC only? > > Tamas > > On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet > wrote: > >> Hi, >> >> Because of the above, I worry that you are basing your work on an old >>> version of CMake. As of April 2015 cmState is used as the interface to >>> the >>> cache. >> >> >> Yeah, that is sadly right. I wanted to rebase on master before >> publishing, thinking it should not be too hard, and I have lots to re-do, >> mostly understand how things are done now. >> >> I did something similar some years ago with QML instead of python, so it >>> sounds interesting to me. >> >> >> I'm trying to be as declarative as possible, because really like how >> readable simple QML programs are, and I think it would be perfect for a >> buildsystem. >> >> My guess is that you are using python to instantiate a cmAddLibraryCommand >>> and then executing it. >> >> >> Actually, I'm directly using the cmMakefile, because I did not want to >> wrap all the commands, and it seemed backwards to me to wrap them. >> >> Even much of cmMakefile shouldn't be used by a new language. Instead >>> certain >>> parts of cmMakefile should be extracted as other classes >>> (cmVariableExpander >>> which should have the ExpandVariablesInString and ConfigureString stuff, >>> cmMessenger for the IssueMessage stuff, some other class for the >>> CompileFeature stuff etc). Then cmMakefile would be just about executing >>> and >>> scoping the CMake language. A new language would not need that, but would >>> use the refactored extracted classes. >> >> >> Ah, this is very interesting, thanks. >> >> >> Having said all that, Brad favors Lua I believe, and he favors a different >>> approach (which no one is working on as far as I know) to adding a new >>> language. So wait to hear from him to know whether it is something that >>> would be upstreamable. >> >> >> Have any details on the approach in question ? SWIG would allow for Lua >> bindings as easily, but I don't think having multiple languages would be a >> good idea. >> I went with Python because I'm familiar with it and have already written >> bindings for it with SWIG. Also, buildbot is written in python and it could >> provide a really interesting integration I think. >> >> I would guide/support you in refactoring cmake as needed. The refactoring >>> part would definitely be upstreamable. I would very much like to see a >>> proof >>> of concept alternative language even if that wasn't upstreamed. It would >>> prove that another language is possible, and that's one of the steps to >>> replacing the current cmake language I think. >> >> >> I will need to work on it to make it work again with master, but I'll try >> and do this soon. >> >> Here is what my test POC looked like for generating a simple shared >> library: >> >> #!/usr/bin/env python >>> # -*- coding: utf-8 -*- >>> import cmake >>> cmake.init("Ninja", "/media/dev/src/cmaketest", >>> "/media/dev/build/cmaketest") >>> myProject = cmake.Project("MyTestProject") >>> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] >>> cmake.generate() >> >> >> Thanks a lot for your comments, I'm happy to see this was not just a dumb >> idea, and that others have thought about it. >> >> I'll update with the github as soon as I get it working. >> >> Best >> >> >> Le lun. 4 janv. 2016 ? 01:16, Stephen Kelly a >> ?crit : >> >>> Charles Huet wrote: >>> >>> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure >>> > cannot be used from python (it check for the existence of a >>> CMakeLists.txt >>> > file, which does not exist in this scenario) and the cache variables it >>> > sets seem to be necessary. >>> >>> Because of the above, I worry that you are basing your work on an old >>> version of CMake. As of April 2015 cmState is used as the interface to >>> the >>> cache. >>> >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 >>> >>> Also note that the C++ interfaces in CMake are not stable. In the last >>> year >>> they have been changed utterly and that will continue to happen without >>> notice. I'm sure you know this, but I thought I'd say it anyway. >>> >>> > I will try to make a layer of abstraction on top of the python bindings >>> > before publishing this work on github, in order to show the syntactic >>> > sugar python can provide, but I will publish this before if anybody is >>> > interested in working on this. >>> >>> I would be interested in seeing it. >>> >>> > Now, does anyone beside me think this is a good idea ? >>> >>> I did something similar some years ago with QML instead of python, so it >>> sounds interesting to me. >>> >>> In fact, one of the reasons for introducing cmState and doing all the >>> refactoring I did in cmake was to make it possible to cleanly replace the >>> language, some day. >>> >>> My guess is that you are using python to instantiate a >>> cmAddLibraryCommand >>> and then executing it. I think a better approach would be to leave all >>> the >>> cm*Command classes behind as they carry a lot of backward compatibility >>> baggage and policies which a new language shouldn't be burdened with. >>> >>> Even much of cmMakefile shouldn't be used by a new language. Instead >>> certain >>> parts of cmMakefile should be extracted as other classes >>> (cmVariableExpander >>> which should have the ExpandVariablesInString and ConfigureString stuff, >>> cmMessenger for the IssueMessage stuff, some other class for the >>> CompileFeature stuff etc). Then cmMakefile would be just about executing >>> and >>> scoping the CMake language. A new language would not need that, but would >>> use the refactored extracted classes. >>> >>> So, you would implement new cmPython*Command or whatever which operate on >>> those classes and cmState. cmState is designed to be a language-agnostic >>> store of data, like a database of buildsystem state. >>> >>> As I said though, this would require further refactoring of the cmake >>> code. >>> I can provide guidance on how to do that if you are interested in >>> pursuing >>> that route. It would take some months I think, but be very valuable for >>> many >>> reasons and long-term cmake features. Another example of the kind of >>> refactoring I mean is putting target state in cmState and making it >>> accessible through cmState::Target, similar to how cmState::Directory >>> currently works. >>> >>> Having said all that, Brad favors Lua I believe, and he favors a >>> different >>> approach (which no one is working on as far as I know) to adding a new >>> language. So wait to hear from him to know whether it is something that >>> would be upstreamable. >>> >>> I would prefer an approach similar to what I described above, which is >>> close >>> to what you are doing, so as a proof of concept I would like to see your >>> work. >>> >>> I would guide/support you in refactoring cmake as needed. The refactoring >>> part would definitely be upstreamable. I would very much like to see a >>> proof >>> of concept alternative language even if that wasn't upstreamed. It would >>> prove that another language is possible, and that's one of the steps to >>> replacing the current cmake language I think. >>> >>> Thanks, >>> >>> Steve. >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >>> >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Mon Jan 4 09:09:29 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 4 Jan 2016 09:09:29 -0500 Subject: [cmake-developers] [CMake 0015902]: ExternalProject Module doesn't work with GHS Multi Generator and Git Message-ID: <8b19b608d939858346a402ba145fea3b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15902 ====================================================================== Reported By: iainmeikle Assigned To: ====================================================================== Project: CMake Issue ID: 15902 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-04 09:09 EST Last Modified: 2016-01-04 09:09 EST ====================================================================== Summary: ExternalProject Module doesn't work with GHS Multi Generator and Git Description: When using the ExternalProject module with the GHS Multi generator external project dependencies are not obtained and built, rule files are missing but the external project GPJ files still report success when building. Steps to Reproduce: 1. Create a CMake project which makes use of the ExternalProject module to pull in an external project using Git. 2. Execute CMake to generate the GPJ files. 3. Build the generated default GPJ. 4. Note that the dependency is not resolved and that *.rule files referenced by any "CMake Rules.gpj" which is in turn referenced by each external project GPJ, which is referenced by the ExternalProjectTargets.gpj are missing. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-04 09:09 iainmeikle New Issue ====================================================================== From ben.boeckel at kitware.com Mon Jan 4 11:39:31 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 4 Jan 2016 11:39:31 -0500 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: References: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> Message-ID: <20160104163931.GA2193@megas.khq.kitware.com> On Sun, Dec 27, 2015 at 22:04:14 +0100, Dimitar Yordanov wrote: > I agree with you. Running valgrind directly on the cmake binary > provides useful information: I can see which internal cmake functions > are used the most and consume most of the time. > > Nevertheless, I think it would be useful to have a higher level > overview. E.g. to see if there are some issues with the scripts > themselves that I use in my project ... I had patches which did this, but it doesn't really help much. At least I didn't think it did. The problems are mainly in CMake itself (regular expressions, path parsing, etc.). I think the next big improvement would be caching variable values which are parsed as numbers, on/off, and paths as a more structured state so that if you have a path, path operations don't have to keep searching for directory separators since it is already in a std::vector structure. > > Usually you see mostly string handling related functions. > > malloc and free are on the top of what I see for a random project used > mostly by std::string. Maybe we can optimize something here too? I did a lot of profiling of CMake two years ago. I fixed the low-hanging fruit (rewriting the CMakeLists.txt parser/variable expander (CMP0053 if you aren't using it), fixing other mini-parsers (escape routines, the genex parser) to chunk rather than do char-by-char iteration, etc.). The big remaining problem is passing char* as an argument where functions do std::string(arg) right away. I fixed all of those which did explicit std::string conversions (via assignment or otherwise), but those which are conditional should get std::string overloads to avoid a malloc/copy/free penalty. There is a *lot* of work here though. The branch I had been working on (which is now woefully out-of-date) is 100 commits long. --Ben From mantis at public.kitware.com Mon Jan 4 11:49:16 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 4 Jan 2016 17:49:16 +0100 Subject: [cmake-developers] [CMake 0015903]: pkg_search_module no longer caches _PREFIX, _LIBDIR, _INCLUDEDIR Message-ID: <9eaca32160d2b2cdbe2db4848a8f1115@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15903 ====================================================================== Reported By: Bernd L?rwald Assigned To: ====================================================================== Project: CMake Issue ID: 15903 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-04 17:49 CET Last Modified: 2016-01-04 17:49 CET ====================================================================== Summary: pkg_search_module no longer caches _PREFIX, _LIBDIR, _INCLUDEDIR Description: Beginning with https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70e8db6e20749a484dd677d7094780c5f4b451c6, the pkgconfig module no longer caches the _PREFIX, _LIBDIR, _INCLUDEDIR variables. This was introduced by using pkg_get_variable which sets for PARENT_SCOPE but not CACHE as _pkgconfig_set did previously. Instead, a helper variable is cached. Steps to Reproduce: $ cat > CMakeLists.txt cmake_minimum_required (VERSION 3.3) find_package (PkgConfig) pkg_search_module (PREFIX REQUIRED gl) if (NOT PREFIX_PREFIX) message (FATAL_ERROR "BUMMER") endif() ^D $ cmake-3.4.1 . -- [?snip] -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- Checking for one of the modules 'gl' -- Configuring done -- Generating done -- Build files have been written to: [?snip] $ cmake-3.4.1 . CMake Error at CMakeLists.txt:5 (message): BUMMER $ grep -E "prefix_result|PREFIX_PREFIX" CMakeCache.txt PREFIX_PREFIX:INTERNAL= prefix_result:INTERNAL=/usr/lib64 $ cmake-3.3.2 . -- [?snip] -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- checking for one of the modules 'gl' -- Configuring done -- Generating done -- Build files have been written to: [?snip] $ cmake-3.3.2 . -- Configuring done -- Generating done -- Build files have been written to: [?snip] $ grep -E "prefix_result|PREFIX_PREFIX" CMakeCache.txt PREFIX_PREFIX:INTERNAL=/usr ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-04 17:49 Bernd L?rwald New Issue ====================================================================== From michael.scott250 at gmail.com Mon Jan 4 18:52:27 2016 From: michael.scott250 at gmail.com (Michael Scott) Date: Mon, 4 Jan 2016 23:52:27 +0000 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <566833DF.8080407@kitware.com> References: <566833DF.8080407@kitware.com> Message-ID: <568B05BB.6060606@gmail.com> Hi Brad, To round off the -W options functionality, I've implemented the -Werror and -Wno-error set of options for the two current types of messages, dev and deprecated. This includes updating the QT GUI to include new options for controlling this functionality. The third patch is not for new functionality, but addresses two small inconsistencies relating to dev and deprecated messages functionality, it's not needed at the end of the day but I thought it would be good to make the code consistent while I was in the area. Lastly I'm also looking at changing all the current usages of the cmake::IssueMessage command, where the message type is dev warning. To check if the warning got upgraded to an error (by checking if the error state has been signalled with the cmSystemTools class), and change the return value of the calling function for example. I think this was discussed previously, however I think this might not be the right change to make. There's quite a few instances of the above code and changing them all is dangerous I imagine where I don't know exactly what all of the callers are generally doing and should be doing. It also implies an undocumented rule that future users of the above functionality should also do this check, which doesn't sound like a good idea to me. What are your thoughts on this last point? Cheers, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-Werror-and-Wno-error-cmake-options.patch Type: text/x-diff Size: 30400 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-New-warnings-as-errors-settings-in-the-GUI.patch Type: text/x-diff Size: 9214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Consistent-author-warning-output.patch Type: text/x-diff Size: 66022 bytes Desc: not available URL: From gang65 at poczta.onet.pl Tue Jan 5 03:18:49 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Tue, 5 Jan 2016 09:18:49 +0100 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: <20160104163931.GA2193@megas.khq.kitware.com> References: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> <20160104163931.GA2193@megas.khq.kitware.com> Message-ID: Hi Ben. 2016-01-04 17:39 GMT+01:00 Ben Boeckel : > The > big remaining problem is passing char* as an argument where functions do > std::string(arg) right away. I fixed all of those which did explicit > std::string conversions (via assignment or otherwise), but those which > are conditional should get std::string overloads to avoid a > malloc/copy/free penalty. There is a *lot* of work here though. The > branch I had been working on (which is now woefully out-of-date) is 100 > commits long. > That's great news. What is the branch name/link to these improvement? Is it possible to push these improvements partially? Maybe CMake community could continue working on that improvement? It will be great to create ticket, in which propose solution will be described. BTW: Do you know why the Xcode and MS Visual Studio is slower than CMake one ? Here is the benchmarks for my internal project: Xcode generation: real 6m31.733s user 4m51.862s sys 0m20.268s Make generation: real 4m45.089s user 2m56.117s sys 0m17.481s Ninja generation: real 2m48.585s user 2m30.712s sys 0m6.313s > > --Ben > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Tue Jan 5 07:33:00 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 5 Jan 2016 13:33:00 +0100 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: References: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> <20160104163931.GA2193@megas.khq.kitware.com> Message-ID: On Tue, Jan 5, 2016 at 9:18 AM, Bartosz Kosiorek wrote: > > Hi Ben. > > 2016-01-04 17:39 GMT+01:00 Ben Boeckel : >> >> The >> big remaining problem is passing char* as an argument where functions do >> std::string(arg) right away. I fixed all of those which did explicit >> std::string conversions (via assignment or otherwise), but those which >> are conditional should get std::string overloads to avoid a >> malloc/copy/free penalty. There is a *lot* of work here though. The >> branch I had been working on (which is now woefully out-of-date) is 100 >> commits long. This improvement should be semi-automated with clang-tidy. We have many functions that take `const char*` and are called by passing a `string.c_str()`. The function signature should be changed to `const std::string&` manually, but changing all the call sites should be done automatically (ideally by kwrobot, periodically, on multiple platforms). Here is how to run clang-tidy on projects built with CMake: $ cd $ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON $ run-clang-tidy.py -p -fix -checks='-*,readability-redundant-string-cstr' /Source/ The run-clang-tidy.py script is here: https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py The `-fix` argument tells clang-tidy to fix the violations inplace. Without this argument the diagnostics are just printed. I wanted to demonstrage the ability of the `redundant-string-cstr` checker, but apparently there are no violations found. I have attached a patch that was generated by the `container-size-empty` checker. Please don't apply it. Such changes should be performed by kwrobot. You can output all possible checks with: $ clang-tidy -p -checks='*' -list-checks > That's great news. > What is the branch name/link to these improvement? > Is it possible to push these improvements partially? > > Maybe CMake community could continue working on that improvement? > It will be great to create ticket, in which propose solution will be > described. > > BTW: Do you know why the Xcode and MS Visual Studio is slower than CMake one > ? > > Here is the benchmarks for my internal project: > > Xcode generation: > real 6m31.733s > user 4m51.862s > sys 0m20.268s > > Make generation: > real 4m45.089s > user 2m56.117s > sys 0m17.481s > > Ninja generation: > real 2m48.585s > user 2m30.712s > sys 0m6.313s Generators for Xcode and Visual Studio have to generate more files. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-demonstrate-clang-tidy.patch Type: text/x-patch Size: 1935 bytes Desc: not available URL: From petr.kmoch at gmail.com Tue Jan 5 07:43:18 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 5 Jan 2016 13:43:18 +0100 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: References: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> <20160104163931.GA2193@megas.khq.kitware.com> Message-ID: On Tue, Jan 5, 2016 at 1:33 PM, Daniel Pfeifer wrote: > > Generators for Xcode and Visual Studio have to generate more files. > ... and they have to process all configurations (Debug, Release, MinSizeRel, RelWithDbgInfo) during the generation stage, instead of just one being processed for single-config generators like Makefiles or Ninja. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Jan 5 10:33:57 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 5 Jan 2016 10:33:57 -0500 Subject: [cmake-developers] [CMake 0015904]: ExternalProject UPDATE_DISCONNECTED does not work with custom UPDATE_COMMAND Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15904 ====================================================================== Reported By: Jaak Ristioja Assigned To: ====================================================================== Project: CMake Issue ID: 15904 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-05 10:33 EST Last Modified: 2016-01-05 10:33 EST ====================================================================== Summary: ExternalProject UPDATE_DISCONNECTED does not work with custom UPDATE_COMMAND Description: This CMakeLists.txt file: CMAKE_MINIMUM_REQUIRED(VERSION 3.1) PROJECT(test NONE) INCLUDE(ExternalProject) SET_PROPERTY(DIRECTORY PROPERTY EP_UPDATE_DISCONNECTED 1) ExternalProject_Add(sf GIT_REPOSITORY "https://github.com/sharemind-sdk/vm_m4.git" UPDATE_COMMAND ${CMAKE_COMMAND} -E echo "Hello, World!") yields in the following `make`output: Scanning dependencies of target sf [ 14%] Creating directories for 'sf' [ 28%] Performing download step (git clone) for 'sf' Cloning into 'sf'... Already on 'master' Your branch is up-to-date with 'origin/master'. [ 42%] No patch step for 'sf' make[2]: *** No rule to make target 'sf-prefix/src/sf-stamp/sf-skip-update', needed by 'sf-prefix/src/sf-stamp/sf-configure'. Stop. CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/sf.dir/all' failed make[1]: *** [CMakeFiles/sf.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 Same error with UPDATE_DISCONNECTED set on the external project itself. Additional Information: Tested with cmake-3.3.2 and cmake-3.4.1. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-05 10:33 Jaak Ristioja New Issue ====================================================================== From hobbsk at ohio.edu Tue Jan 5 11:04:54 2016 From: hobbsk at ohio.edu (Kevin H. Hobbs) Date: Tue, 5 Jan 2016 11:04:54 -0500 Subject: [cmake-developers] Retire expected builds Message-ID: <568BE9A6.4020303@ohio.edu> I'm moving to a new job, and will no longer be able to maintain my nightly builds (even in their neglected state.) Please expect the expected builds from bubbles, murron, and k450e to dissapear. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: OpenPGP digital signature URL: From ben.boeckel at kitware.com Tue Jan 5 12:04:39 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 5 Jan 2016 12:04:39 -0500 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: References: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> <20160104163931.GA2193@megas.khq.kitware.com> Message-ID: <20160105170439.GB14738@megas.kitware.com> On Tue, Jan 05, 2016 at 09:18:49 +0100, Bartosz Kosiorek wrote: > That's great news. > What is the branch name/link to these improvement? > Is it possible to push these improvements partially? Because the changes are so pervasive, I'd like for the branch to be bisectable, so every commit should pass the test suite on at least the common platforms (make, ninja, visual studio, xcode). https://github.com/mathstuf/cmake/tree/dev/string-overloads > Maybe CMake community could continue working on that improvement? I have no problem with anyone taking over the branch as long as the branch ends up bisectable. If anyone wants to take it over and put the branch together, I can run the test suite. > It will be great to create ticket, in which propose solution will be > described. > > BTW: Do you know why the Xcode and MS Visual Studio is slower than CMake > one ? As Petr said, it is because these generators generate a build for each configuration. You can help this by removing configurations you don't care about from CMAKE_CONFIGURATION_TYPES (like, say, MinSizeRel) to help reduce the time. There are also probably some places in the genex evaluator where computed values could be cached to improve times (e.g., make a cache of the transitive closure for each target's include directories, link libraries, etc. when evaluating $ and friends). Alternatively, cmTarget could cache them (but that may not be as straight forward since cmTarget is editable while genex evaluation occurs when everything is read-only). Not sure how much it would help the multi-config generators since they already memoize configuration-independent evaluations. --Ben From neundorf at kde.org Tue Jan 5 17:10:17 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 05 Jan 2016 23:10:17 +0100 Subject: [cmake-developers] (Experimental) Refactored extra-generators Message-ID: <2440518.7ptVlVJX7Q@tuxedo.neundorf.net> Hi, I spent a few hours on the extra-generators, and you can find the result here on github: https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental In this branch, the extra-generators are not tied anymore hardcoded to the generators (so the generator list is short again), but each extra-generator can be enabled and disabled via a cmake option CMAKE_ENABLE_EXTRA_GENERATOR_. I.e. for every build directory zero, one or multiple extra-generators can be enabled and disabled (in an existing build tree). This would e.g. also be suitable for a generic JSON-generator. The code on github is not ready to be merged, and unfortunately I don't have the time to bring it into mergeable state, including tests, documentation, etc. But if somebody is interested, you can have a look and give it a try. Alex From mantis at public.kitware.com Wed Jan 6 02:06:20 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 6 Jan 2016 02:06:20 -0500 Subject: [cmake-developers] [CMake 0015905]: It seems that CMake ignores "Debug" in CMAKE_TRY_COMPILE_CONFIGURATION Message-ID: <88882660be685bcad4e441bd5a6b4336@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15905 ====================================================================== Reported By: Ivan K Assigned To: ====================================================================== Project: CMake Issue ID: 15905 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-06 02:06 EST Last Modified: 2016-01-06 02:06 EST ====================================================================== Summary: It seems that CMake ignores "Debug" in CMAKE_TRY_COMPILE_CONFIGURATION Description: https://github.com/urho3d/Urho3D/issues/1136#issuecomment-169250581 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-06 02:06 Ivan K New Issue ====================================================================== From nicolas.despres at gmail.com Wed Jan 6 05:14:32 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Wed, 6 Jan 2016 11:14:32 +0100 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file Message-ID: Hello, I would like to be able to use a build.ninja file generated by CMake as a subninja file of a super build.ninja file generated by a custom generator. This way I could include a CMake projects in a bigger one. Currently, I call ninja recursively to build the CMake sub-project. But this approach goes against ninja philosophy (one file to ease parallel job handling because recursive makefile are considered harmful, etc...) and the maintainers are not willing to accept patches to properly support it [1, 2]. Consider the following build directory layout: top/build.ninja top/sub/build.ninja Where: - top/build.ninja contains, among other things, "subninja sub/build.ninja" and is generated by a custom generator - "top/sub/build.ninja" is generated by CMake. To properly work, build edge outputs in "top/sub/build.ninja" must be relative to the "top/" directory. Currently, it is impossible because to generate the "top/sub/build.ninja" file CMake must be invoked like this: "cd top/sub && cmake -G Ninja ". It has no knowledge of the "top/" directory being special and generates all the outputs relative to the "top/sub/" directory instead of the "top/" directory. For example, we should have this kind of generated build statements for an helloworld project: build sub/build.ninja: RERUN_CMAKE .... build sub/clean: CLEAN build hello: C_EXECUTABLE_LINKER__hello sub/CMakeFiles/hello.dir/hello.c.o build sub/all: phony sub/hello default sub/all To enable this type of generation, the "top/" directory must be passed to CMake somehow. An environment variable or a CMake variable called CMAKE_NINJA_TOP_BUILD_DIR would do the trick. Note that such a change requires scoped rules which was introduced by ninja 1.6. [3] I am willing to write the patch if you think there is a chance that it will be accepted. Best regards, [1] https://github.com/ninja-build/ninja/pull/1079 [2] https://github.com/ninja-build/ninja/pull/1078 [3] https://ninja-build.org/manual.html#ref_scope -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jan 6 12:25:04 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 6 Jan 2016 12:25:04 -0500 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: References: Message-ID: <20160106172504.GB6998@megas.kitware.com> On Wed, Jan 06, 2016 at 11:14:32 +0100, Nicolas Despr?s wrote: > To enable this type of generation, the "top/" directory must be passed to > CMake somehow. An environment variable or a CMake variable called > CMAKE_NINJA_TOP_BUILD_DIR would do the trick. I think CMAKE_NINJA_OUTPUT_PATH_PREFIX would work fine (passed as a -D on the command line). Note that the ninja file CMake generates is then invalid except as a subninja file (since the build rules paths won't line up from its directory). I don't know how acceptable that would be. Maybe a separate Subninja generator which uses it and writes out a build.subninja file instead? --Ben From nicolas.despres at gmail.com Wed Jan 6 13:26:11 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Wed, 6 Jan 2016 19:26:11 +0100 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: <20160106172504.GB6998@megas.kitware.com> References: <20160106172504.GB6998@megas.kitware.com> Message-ID: On Wed, Jan 6, 2016 at 6:25 PM, Ben Boeckel wrote: > On Wed, Jan 06, 2016 at 11:14:32 +0100, Nicolas Despr?s wrote: > > To enable this type of generation, the "top/" directory must be passed to > > CMake somehow. An environment variable or a CMake variable called > > CMAKE_NINJA_TOP_BUILD_DIR would do the trick. > > I think CMAKE_NINJA_OUTPUT_PATH_PREFIX would work fine (passed as a -D > on the command line). > Is that variable already available or a name suggestion? I cannot find any reference to it neither in the source nor in the documentation. > > Note that the ninja file CMake generates is then invalid except as a > subninja file (since the build rules paths won't line up from its > directory). I don't know how acceptable that would be. Maybe a separate > Subninja generator which uses it and writes out a build.subninja file > instead? > This is acceptable for me since I have a custom generator that would write the top build.ninja containing "subninja sub/build.ninja". The end-user is supposed to run ninja from the top directory not from the top/sub/ directory. -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jan 6 13:35:52 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 6 Jan 2016 13:35:52 -0500 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: References: <20160106172504.GB6998@megas.kitware.com> Message-ID: <20160106183552.GA29325@megas.kitware.com> On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Despr?s wrote: > Is that variable already available or a name suggestion? I cannot find any > reference to it neither in the source nor in the documentation. It's a suggestion. > This is acceptable for me since I have a custom generator that would write > the top build.ninja containing "subninja sub/build.ninja". The end-user is > supposed to run ninja from the top directory not from the top/sub/ > directory. It looks like subclassing cmLocalNinjaGenerator to override some path-related bits and it should work (though it has changed enough with cmState that I can't tell what exactly without doing more digging). The hardest problem is going to be with testing. Every generate step will also have to dump a build.ninja file out so that it can be properly tested. Brad is back later this week and may have other ideas too. --Ben From nicolas.despres at gmail.com Wed Jan 6 13:46:26 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Wed, 6 Jan 2016 19:46:26 +0100 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: <20160106183552.GA29325@megas.kitware.com> References: <20160106172504.GB6998@megas.kitware.com> <20160106183552.GA29325@megas.kitware.com> Message-ID: On Wed, Jan 6, 2016 at 7:35 PM, Ben Boeckel wrote: > On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Despr?s wrote: > > Is that variable already available or a name suggestion? I cannot find > any > > reference to it neither in the source nor in the documentation. > > It's a suggestion. > Ok, works for me too. > > This is acceptable for me since I have a custom generator that would > write > > the top build.ninja containing "subninja sub/build.ninja". The end-user > is > > supposed to run ninja from the top directory not from the top/sub/ > > directory. > > It looks like subclassing cmLocalNinjaGenerator to override some > path-related bits and it should work (though it has changed enough with > cmState that I can't tell what exactly without doing more digging). > > The hardest problem is going to be with testing. Every generate step > will also have to dump a build.ninja file out so that it can be properly > tested. > > Brad is back later this week and may have other ideas too. > > I will try to have a patch working on a helloworld project first and I will get back to you for the testing part. That would be the hardest part indeed. Thanks for your help. -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Thu Jan 7 20:18:53 2016 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 7 Jan 2016 17:18:53 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: Message-ID: On 12/24/15, Eric Wing wrote: >> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h) > > Quick addendum: Just realized the bridging header should probably be > per-target. > For reference, we have an Xcode specific, per-target variable for the bridging header: XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER. set_property(TARGET ${BLURRR_USER_EXECUTABLE_NAME} PROPERTY XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER "${PROJECT_SOURCE_DIR}/source/MySwiftBridgingHeader.h") From michaeljohnfitzgerald at gmail.com Thu Jan 7 22:36:50 2016 From: michaeljohnfitzgerald at gmail.com (Mike Fitzgerald) Date: Thu, 7 Jan 2016 21:36:50 -0600 Subject: [cmake-developers] patch building and testing Message-ID: Hi cmake-developers, I'm a bit new to this, so please bear with me! I wanted to fix an issue (#13666), so I did the following: 1.) Cloned the git repo, ran bootstrap and make. 2.) Wrote some code in cmVisualStudio10TargetGenerator.cxx. Running make again didn't seem to recompile anything, which seemed strange. Am I meant to run bootstrap (or bin/cmake, I guess) each time I want to recompile? The relationship of these tools and the source files isn't clear to me. Once I recompile, I want to make sure I didn't break anything. There appears to be a full suite of tests in the Tests folder, but how exactly do I run them, and from where? I couldn't find instructions for this on the wiki or in source. The README in the Tests folder mostly concerns how to add a test, not run the existing ones. Thanks for the help (and patience)! - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Jan 8 11:30:44 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Jan 2016 11:30:44 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: Message-ID: <568FE434.1020501@kitware.com> On 12/24/2015 06:13 AM, Eric Wing wrote: > Now that Swift is officially open source and already available for > Linux, I started looking at the build process on Linux which I hope we > can figure out how to incorporate into the CMake Makefile generator. Thanks for digging in to this! > To start with, there actually seem to be two different approaches. > 1) The swiftc command line compiler (similar to gcc, clang with > switches and output that seem to resemble them as well) > 2) A formal package/module system for Swift which works with a Swift > command line build tool ?swift build? > > So far, for my usage cases, I?ve found the (2) package/module system > to be annoying and a bunch of indirection and extra steps. I also > don?t feel I have completely wrapped my head around it, so I?m not > going to focus on this for now. However, as more pure Swift libraries > get written, I think interoperating with the module system will become > extremely important, which we?ll ultimately need to deal with. Yes. A few months ago I spent a few hours looking at the commands Xcode uses to build Swift code. For reference, here are some notes I took (not well organized): ---------------------------------------------------------------------------- MergeSwiftModule produces .swiftmodule files, which seem to be serialized copies of swift modules, like binary headers, each covering an entire module over multiple source files. MergeSwiftModule merges partial modules from individual sources into one for the whole module. The .swiftmodule for a shared library can be consumed while compiling other projects whose "import" statements search the -I path for the .swiftmodule files. The .swiftmodule file is a binary header for the whole shared library. The compiler leaves in .o files a decl that tells the linker what libraries to link. The linker hopefully tolerates seeing those libraries explicitly on the command line too, since CMake will generate those. Swift does have conditional compilation that affects imports. See the -emit-dependencies and output file map options to control where .d files are generated. swift -help swift -help-hidden swift -frontend -help swift -frontend -help-hidden If one imports a library written in C/objc then something generates a module map pointing to the headers. It seems to lazily generate from the headers a module that can be loaded. To use a C library from Swift one must write a module map explicitly. Some lib providers may support modules directly and provide the module map next to the library file. ---------------------------------------------------------------------------- > But in the meantime, back to (1) swiftc, this I found much more > straight-forward, at least for dealing with C code and C libraries and > I think maps pretty well to the current CMake design. Great. > There is a pretty good example/write up found here: > http://dev.iachieved.it/iachievedit/more-swift-on-linux/ Good link. > For a Swift application that also has C code, and uses C libraries, > this is the basic procedure: > > 1) Compile the C files into .o > clang -c escapetext.c > > 2) Compile the Swift files into .o (note: The header seems to be the > ?Bridging Header? discussed in the prior thread) > swiftc -c escapeswift.swift -import-objc-header escapetext.h > > 3) Link all the object files together to build the final app executable > swiftc escapeswift.o escapetext.o -o escapeswift -lcurl Okay. > (Note: ?main.swift? seems get > special handling by the swift compiler and is always treated as your > application entry point.) Yes, that seems to be the case. Furthermore the file can just have code directly in the top level because the whole thing is the "main" function. > So I?d like to talk about how to further enhance CMake to do the above. Okay. Ideally I'd like a solution designed with understanding of the module system as mentioned in my notes above. > In my head, for the above examples, I think I would want to do > something like: > > find_package(SDL) > include_directories(${SDL_INCLUDE_DIR}) > > # Forgot if we already had a convention for controlling this in the > Xcode generator > set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h) As you noted in another response, we have a per-target property XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER. The bridging header does need to be per-target, yes. > add_executable(MyAppExe > SDLSwiftBinding.c > main.swift > MyApp.swift > ) > target_link_libraries(MyAppExe ${SDL_LIBRARY}) Yes, that looks like what we want to achieve. Thanks, -Brad From brad.king at kitware.com Fri Jan 8 11:30:50 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Jan 2016 11:30:50 -0500 Subject: [cmake-developers] FindSTLSoft.cmake, Problems? In-Reply-To: References: Message-ID: <568FE43A.8000401@kitware.com> On 12/28/2015 07:31 AM, mikkoi wrote: > A CMake project depends on the header only library STLSoft > (http://www.stlsoft.org/). > We rely on the developer having STLSoft installed or "installed" > (pointed to by an environment variable) on his system for compilation. Ideally packages should provide CMake packaging files as documented here: https://cmake.org/cmake/help/v3.4/manual/cmake-packages.7.html However, since header-only libraries tend to have no build system this may be a tough sell upstream. Find modules are the fallback approach. > To make sure the developer's version is high enough, I created this > FindSTLSoft.cmake file. > > Can someone read it through, and say if there are any errors or > antipatterns. > I'm still learning CMake, so I might have made mistakes. Please read through the cmake-developer(7) manual section on modules and find modules: https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#modules -Brad From brad.king at kitware.com Fri Jan 8 11:30:56 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Jan 2016 11:30:56 -0500 Subject: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python) In-Reply-To: References: Message-ID: <568FE440.5090009@kitware.com> Hi Charles, Thanks for your efforts in exploring this topic. CMake's current language grew incrementally out of something that was not originally intended as a programming language. The cmState refactoring Stephen Kelly has started is a huge step toward enabling alternative languages, but there is a long way to go. A few general thoughts: * One rule we have for CMake is to never expose any public SDK of the C++ implementation structures. We want to be able to rewrite them arbitrarily at any time. Therefore any solution that needs to access the C++ structures must be integrated into CMake upstream and expose functionality only through other languages or file formats. * The cmState infrastructure builds on a "snapshot" design with a goal of being able to "fork" configuration/generation temporarily and then revert back, and to be able to re-start configuration from the middle. These goals may be incompatible with any language whose implementation we do not fully control unless it is allowed to execute only in isolated and independent snippets. These are not hard goals, but it is a trade-off to keep in mind. Stephen may be able to elaborate more on the snapshot approach if needed. * A problem with the current design is that the entire configuration process is logically serial making parallel evaluation hard or impossible. In many cases each add_subdirectory can be processed independently, but this will require semantic changes to allow. On 01/04/2016 02:41 AM, Charles Huet wrote: > I'm trying to be as declarative as possible, because really like how readable > simple QML programs are, and I think it would be perfect for a buildsystem. Ideally most of the specification (sources, libraries, executables, etc.) should be in a pure format that can be evaluated without side effects (e.g. declarative or functional). This rules out both Python and Lua, but the specification format does not have to be the main entry point. There could be some imperative configuration step that does system introspection and then loads the pure specification and evaluates it as needed for the specific environment. If we're going to go through the effort to provide an alternative input format, I think we should strive for this approach because it will be more flexible in the long run. A pure specification format will allow easy loading/saving by other tools, IDEs, etc., without having to process any imperative logic. > Actually, I'm directly using the cmMakefile, because I did not want to wrap all > the commands, and it seemed backwards to me to wrap them. Yes. Any alternative format should be processed directly into the structures used by the generators. The cmState work has separated the generate-time representation quite a bit from the configuration-time (cmake-language-specific) representation, but I think there is still further work needed to finish that. >> Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. > > Have any details on the approach in question? See above. Lua has come up several times in the past in particular because its implementation is meant to be small and embeddable. I've thought a few times about how to make Lua scripting available from within the CMake language in a clean way, but that will not be as valuable as the above pure-spec approach. > Here is what my test POC looked like for generating a simple shared library: > > #!/usr/bin/env python > # -*- coding: utf-8 -*- > importcmake > cmake.init("Ninja","/media/dev/src/cmaketest","/media/dev/build/cmaketest") > myProject=cmake.Project("MyTestProject") > myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] > cmake.generate() I do not think we should have the build specification depend on processing code like this. It is not compatible with cmake-gui where the configuration and generation steps are triggered by the user. However, this does serve as a good POC that we can populate the generator structures with another language. In summary, I think work in this direction should first focus on designing a declarative (or functional) specification format where most of the project information can be specified. Then a cmake-language command can be written to load and evaluate a specification file (as a transition). Finally we could look at replacing the entry-point language with something else. At that point we could have closures passed as parameters to the evaluation of the pure spec in order to get custom generate-time logic. Thanks, -Brad From brad.king at kitware.com Fri Jan 8 11:31:01 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Jan 2016 11:31:01 -0500 Subject: [cmake-developers] patch building and testing In-Reply-To: References: Message-ID: <568FE445.5040503@kitware.com> On 01/07/2016 10:36 PM, Mike Fitzgerald wrote: > I wanted to fix an issue (#13666) Great! > 1.) Cloned the git repo, ran bootstrap and make. > 2.) Wrote some code in cmVisualStudio10TargetGenerator.cxx. > > Running make again didn't seem to recompile anything On what platform did you build? That source file is used only on Windows platforms. It won't compile at all on Linux or OS X hosts so it is not expected to re-compile after modification on those platforms. > There appears to be a full suite of tests in the Tests folder After compiling, run bin/ctest to run the tests. If you used a VS (or Xcode) generator then run bin/Debug/ctest -C Debug where "Debug" is whatever configuration you built after generating. You don't actually have to use the bootstrap script to build for development. You can configure/build CMake with an already-installed CMake. This is required on Windows to build with VS. With this approach you should run the tests using the ctest that comes next to the already-installed cmake you ran to configure the build tree. -Brad From brad.king at kitware.com Fri Jan 8 11:31:27 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Jan 2016 11:31:27 -0500 Subject: [cmake-developers] [PATCH] Fix some bugs in CPack's DragNDrop generator's handling of LICENSE files In-Reply-To: References: Message-ID: <568FE45F.6000207@kitware.com> On 01/02/2016 04:11 PM, Andrey Mishchenko wrote: > There were issues in the special-character-escaping and line-wrapping code > which caused DragNDrop packaging to fail mysteriously at a later step with > parsing errors in the sla.r file generated by the following code. Thanks, applied and merged to 'next' for testing: CPack/DragNDrop: Fix handling of certain license file content (#15899) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bbb3c4ff Simon, these changes affect code you contributed. Please check that they still work for you. Thanks, -Brad From michaeljohnfitzgerald at gmail.com Fri Jan 8 17:56:49 2016 From: michaeljohnfitzgerald at gmail.com (Mike Fitzgerald) Date: Fri, 8 Jan 2016 17:56:49 -0500 Subject: [cmake-developers] patch building and testing In-Reply-To: <568FE445.5040503@kitware.com> References: <568FE445.5040503@kitware.com> Message-ID: Thanks, that was exactly what I needed to know! I was compiling on OS X, which is what caused the make confusion. After moving back to Windows, I've got the attached, which gives me the results I'd expect and doesn't cause any new test failures. I tried to follow the code conventions as best I could. If I should be adding a test for this property, or submitting the patch differently, please let me know! - Mike >From 2a831f0752ad9e97c5e4e729ced92d640b792386 Mon Sep 17 00:00:00 2001 From: Mike Fitzgerald Date: Fri, 8 Jan 2016 17:33:28 -0500 Subject: [PATCH] fix VS_GLOBAL_* properties in VS 10+ --- Source/cmVisualStudio10TargetGenerator.cxx | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index 6e1fb5b..0406d25 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -448,6 +448,32 @@ void cmVisualStudio10TargetGenerator::Generate() (*this->BuildFileStream) << cmVS10EscapeXML(targetFrameworkVersion) << "\n"; } + + std::vector keys = this->GeneratorTarget->GetPropertyKeys(); + for(std::vector::const_iterator keyIt = keys.begin(); + keyIt != keys.end(); ++keyIt) + { + static const char* prefix = "VS_GLOBAL_"; + if(keyIt->find(prefix) != 0) + continue; + std::string globalKey = keyIt->substr(strlen(prefix)); + // Skip invalid or separately-handled properties. + if(globalKey == "" || + globalKey == "PROJECT_TYPES" || + globalKey == "ROOTNAMESPACE" || + globalKey == "KEYWORD") + { + continue; + } + const char* value = this->GeneratorTarget->GetProperty(keyIt->c_str()); + if (!value) + continue; + this->WriteString("<", 2); + (*this->BuildFileStream) << globalKey << ">" + << cmVS10EscapeXML(value) + << "\n"; + } + this->WriteString("\n", 1); this->WriteString("\n", -- 1.9.4.msysgit.2 On Fri, Jan 8, 2016 at 11:31 AM, Brad King wrote: > On 01/07/2016 10:36 PM, Mike Fitzgerald wrote: > > I wanted to fix an issue (#13666) > > Great! > > > 1.) Cloned the git repo, ran bootstrap and make. > > 2.) Wrote some code in cmVisualStudio10TargetGenerator.cxx. > > > > Running make again didn't seem to recompile anything > > On what platform did you build? That source file is used only on > Windows platforms. It won't compile at all on Linux or OS X hosts > so it is not expected to re-compile after modification on those > platforms. > > > There appears to be a full suite of tests in the Tests folder > > After compiling, run > > bin/ctest > > to run the tests. If you used a VS (or Xcode) generator then run > > bin/Debug/ctest -C Debug > > where "Debug" is whatever configuration you built after generating. > > You don't actually have to use the bootstrap script to build for > development. You can configure/build CMake with an already-installed > CMake. This is required on Windows to build with VS. With this > approach you should run the tests using the ctest that comes next to > the already-installed cmake you ran to configure the build tree. > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Fri Jan 8 18:15:03 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 8 Jan 2016 15:15:03 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <568FE434.1020501@kitware.com> References: <568FE434.1020501@kitware.com> Message-ID: > Yes. A few months ago I spent a few hours looking at the commands Xcode > uses to build Swift code. For reference, here are some notes I took > (not well organized): > > ---------------------------------------------------------------------------- > MergeSwiftModule produces .swiftmodule files, which seem to be serialized > copies of swift modules, like binary headers, each covering an entire module > over multiple source files. MergeSwiftModule merges partial modules from > individual sources into one for the whole module. > > The .swiftmodule for a shared library can be consumed while compiling > other projects whose "import" statements search the -I path for the > .swiftmodule files. The .swiftmodule file is a binary header for the > whole shared library. > > The compiler leaves in .o files a decl that tells the linker what libraries > to link. The linker hopefully tolerates seeing those libraries explicitly > on the command line too, since CMake will generate those. > That article I linked to also mentions the .swiftmodule system via swiftc. ========= swiftc -emit-library translator.swift -module-name translator -import-objc-header bridgingHeader.h clang -shared -o libtranslator.so translator.o # Now, create the module: swiftc -emit-module -module-name translator translator.swift -import-objc-header bridgingHeader.h # This leaves us with three files: libtranslator.so, translator.swiftmodule, and translator.swiftdoc. # You must have a translator.swiftmodule in your module search path, which we add with -I.: swiftc -I. -c main.swift -import-objc-header bridgingHeader.h # Let?s link everything together: swiftc -o translate.exe jsonparse.o main.o -L. -ltranslator -lcurl -ljson-c -lswiftGlibc -lFoundation ========= I haven't given deep thought to libraries yet (still just trying to get applications going), I'm thinking ADD_LIBRARY most needs to just invoke the -emit-library flag on swiftc, and automatically add the -I (include path) to the output directory for the linking. Maybe -module-name can be inferred from the TARGET name? > See the -emit-dependencies and output file map options to control where .d > files are generated. > > swift -help > swift -help-hidden > swift -frontend -help > swift -frontend -help-hidden > > If one imports a library written in C/objc then something generates a > module map pointing to the headers. It seems to lazily generate from > the headers a module that can be loaded. To use a C library from Swift > one must write a module map explicitly. Some lib providers may support > modules directly and provide the module map next to the library file. It looks like the 'swift' front-end build and packaging system is still a work in progress and doesn't seem to fully work on Linux yet. > Swift does have conditional compilation that affects imports. Yes. I'm wondering at least with a swiftc backend, this is up to the user to manually specify (mirror) in the CMake description to say what files are compiled/linked, like they do now with C/C++/Obj-C. Maybe when the 'swift' front-end gets farther, we can try to make this more automatic. But since the 'swift' front-end is entangled with git, and introduces its own package file conventions, it's not something I've given much thought to. Anyway, I have a couple of hours on a train this weekend. I was wondering if you could give me guidance on what I need to do to get a simple 'swiftc' integration going for ADD_EXECUTABLE, as described in the original post. Thanks, Eric From gour at atmarama.com Sat Jan 9 03:28:33 2016 From: gour at atmarama.com (=?UTF-8?Q?Sa=C5=A1a_Jani=C5=A1ka?=) Date: Sat, 09 Jan 2016 09:28:33 +0100 Subject: [cmake-developers] Cython support Message-ID: <1452328113.2187.15.camel@atmarama.com> Hello, I'm evaluating which build system to use for Python3+PyQt5+Cython open-source multi-platform project and find out about Matt's project (https://github.com/thewtex/cython-cmake-example), and wonder whether Cython support is going to be added to official CMake release or not? Sincerely, Gour --? There is no possibility of one's becoming a yog?, O Arjuna,? if one eats too much or eats too little, sleeps too much? or does not sleep enough. From mantis at public.kitware.com Sat Jan 9 12:37:40 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 9 Jan 2016 12:37:40 -0500 Subject: [cmake-developers] [CMake 0015906]: With Microsoft Visual Studio CMake should use the C++ compiler for C files, if C standard >= C99 is set Message-ID: <52a47a874975d456dda18af5e2de58dd@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15906 ====================================================================== Reported By: Jan Henke Assigned To: ====================================================================== Project: CMake Issue ID: 15906 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-09 12:37 EST Last Modified: 2016-01-09 12:37 EST ====================================================================== Summary: With Microsoft Visual Studio CMake should use the C++ compiler for C files, if C standard >= C99 is set Description: The Mircosoft Visual Studio C compiler only supports ISO 9899:1989 (aka C89). Newer C features are only implemented in the C++ compiler and only for the subset of C, which is part of the C++ standard (see for reference: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/) Since a few versions CMake provides a way to specify the features or standard for your application. Thus if the requested standard level is C99 or above, or any of the features introduced in C99 or above, CMake should use the C++ compiler for C files. To quote from above web site: "We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code." Please change the generator for Visual Studio solutions accordingly. That way we can use modern C feature with CMake and the Visual Studio compilers. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-09 12:37 Jan Henke New Issue ====================================================================== From steveire at gmail.com Sun Jan 10 06:10:43 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 10 Jan 2016 12:10:43 +0100 Subject: [cmake-developers] CMake daemon for user tools Message-ID: <56923C33.6030506@gmail.com> Hello, I've been working on adding a daemon mode for cmake to provide information to user tools - such as IDEs - about the buildsystem. Following the discussion about providing metadata for IDEs to consume I proposed creating a long-running process which would provide a protocol to access information about the buildsystem, and about the content of the cmake files themselves: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 The original post in that thread lists design goals. This design is independent of any generator, and compared to the solution of writing json to a file, this solution doesn't require generating anything that is not asked for. This also side-steps the problem of 'stale' files remaining in the build directory, and the problem of needing to trigger re-generation of the file, or watching it for changes. This solution also allows parameters (eg the config) to be specified in requests, side-stepping a difficulty we encountered before to represent things like that. This solution also does not require actually generating the buildsystem files. Only the configure and compute steps of cmake are executed. I am scheduled to give a talk at FOSDEM about the feature and how user tools can interact with it: https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code with a preview in Berlin: http://www.meetup.com/berlincplusplus/events/227896427/ I have now also pushed a branch to my github clone with the start of the server mode: https://github.com/steveire/CMake/commits/cmake-daemon Currently the branch only makes targets and backtraces etc available via the protocol. I have also created a plan for extending the protocol to make code completion and variable debugging possible, and analysed the depedencies of the tasks: http://www.steveire.com/cmake-daemon-tasks.png However, I can't complete those tasks myself: I don't have relevant experience building IDEs to know how best to design the protocol, what IDE tools really need, how to design a fail-safe parser etc. Additionally, I think a design which incorporates design ideas and implementation from more than one person will be better in the end. So, this needs to be a collaborative effort if it is to go anywhere, with more people writing commits in the cmake repo. The above (copied below) task list would be enough to get a read-only browser of a cmake project quite quickly. Following that, an effort would be needed to handle the difference between the dirty state of an editor and the on-disk file content. That's a solvable problem and together with filesystem notifications provided by libuv, it will lead to features like code completion. Also necessary eventually would be to make the cmake parser more fail-safe, so that information is still available if the user had not yet closed a command argument list for example, and make the processing more fail-safe in the case where they have written add_subdirectory(foo), but have not yet created foo/CMakeLists.txt. I would be looking to people who work on IDEs for guidance on how to do things like that, as some of them are likely already for handling C++ code in the IDEs. So, this needs to be a collaborative effort. I can provide guidance to anyone who wishes to participate in changing the source code of CMake to make it possible. Is anyone interested enough in this potential cmake feature to join the development effort? Thanks, Steve. * Provide basic daemon mode with event loop and communication protocol -- Written, but not reviewed * Provide protocol to query the buildsystem structure -- Written, but not complete or reviewed * Extend cmListFileParser to record location of start and end of commands * Rewrite cmIfCommand to record which branches are executed * Store the location of start and end of user-defined functions * Provide protocol to query for unexecuted lines * Define a new snapshot type to occur at an arbitrary point * Create snapshots after branching to other files (after an include() or find_package() or add_subdirectory etc) * Create snapshots after points with external effects (file(WRITE), configure_file(), execute_process etc) * Find most recent snapshot occuring before a specified line * Implement feature to start at a specific snapshot and execute commands up to a particular line * Make server find correct snapshot to start at and execute required commands up to specified line * Provide protocol to dump variable defintions at a particular line * Extract implementation of IssueMessage from cmMakefile and cmLocalGenerator into cmake * Extract computed target properties from cmTarget::GetProperty into cmComputedTargetProperties * Implement cmGeneratorTarget::GetProperties in terms of cmComputedTargetProperties * Move implementation of cmTarget::{Get,Set,Append}Property to cmState * Extract all IssueMessage parts of cmake into a cmMessenger * Extract the cmSystemTools::Message part of cmMessenger into a virtual method * Publish messages through server protocol * Implement snapshot-versioning of target properties * Dump target property content * Implement snapshot versioning of policies * Implement snapshot-versioning of directory properties * Implement snapshot-versioning of global properties * Dump directory, global properties and policies * Extend protocol to provide dirty buffers from editors, instead of only executing on-disk commands * Provide code completion protocol From mantis at public.kitware.com Sun Jan 10 11:15:57 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 10 Jan 2016 11:15:57 -0500 Subject: [cmake-developers] [CMake 0015907]: [ninja] wrong dependency management with imported targets from external project or custom target Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15907 ====================================================================== Reported By: Philippe Assigned To: ====================================================================== Project: CMake Issue ID: 15907 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-10 11:15 EST Last Modified: 2016-01-10 11:15 EST ====================================================================== Summary: [ninja] wrong dependency management with imported targets from external project or custom target Description: Here is a simple CMakeLists to reproduce my problem: # in my case, this line is actually an ExternalProject_Add add_custom_target(outfile COMMAND gcc ${CMAKE_CURRENT_SOURCE_DIR}/lib.c -shared -o liboutfile.so) add_library( mylib SHARED IMPORTED ) set_property( TARGET mylib PROPERTY IMPORTED_LOCATION liboutfile.so ) add_dependencies( mylib outfile ) add_executable( testexe test.c ) target_link_libraries( testexe mylib ) This ensures that before we try to link with the mylib target, the outfile target is built. Except it works only with the Unix Makefiles generator but not with the Ninja one. With Ninja I get this error before it tries to do any work: ninja: error: 'liboutfile.so', needed by 'testexe', missing and no known rule to make it I'm attaching a simple and complete test project to reproduce. Steps to Reproduce: 1. download and uncompress the attached testproj 2. configure with the Ninja generator 3. try build with ninja and get an error ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-10 11:15 Philippe New Issue 2016-01-10 11:15 Philippe File Added: testproj.tar.bz2 ====================================================================== From mantis at public.kitware.com Sun Jan 10 16:15:24 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 10 Jan 2016 16:15:24 -0500 Subject: [cmake-developers] [CMake 0015908]: Ampersand in CMake path is not escaped Message-ID: <7a01cbd12aaa7a56725eda9fa5a9232c@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15908 ====================================================================== Reported By: Marko Havu Assigned To: ====================================================================== Project: CMake Issue ID: 15908 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-10 16:15 EST Last Modified: 2016-01-10 16:15 EST ====================================================================== Summary: Ampersand in CMake path is not escaped Description: Ampersands in CMake path (e.g. /Applications/Xcode & Developer Tools/CMake.app) are not escaped in the cmake scripts. Thus the scripts fail as the commands are split at the ampersand. Steps to Reproduce: Install CMake in path with an ampersand. Generate a project. (I used Xcode generator. I am not sure whether this affects other generators as well.) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-10 16:15 Marko Havu New Issue ====================================================================== From petr.kmoch at gmail.com Mon Jan 11 04:54:01 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 11 Jan 2016 10:54:01 +0100 Subject: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python) In-Reply-To: <568FE440.5090009@kitware.com> References: <568FE440.5090009@kitware.com> Message-ID: Hi all. I'd like to voice my opinion as a somewhat advanced CMake user here. For me, one of the strongest points of CMake is the fact that its project specification is procedural rather than declarative. In my current job, for example, we have a significant framework built in CMake which handles a lot of unique setups we have (which were largely inherited from a previous inhouse buildsystem). Yes, the end result of our framework is that the CMakeLists consist mostly of declarative commands from our framework, but the implementation of these commands is heavily procedural. I am convinced that if CMake didn't give us the procedural power required to make this work, we couldn't have adopted it. (I had previously tried emulating bits of this setup in a more declarative system and failed miserably). Of course (having written much of this framework I'm talking about above), I know all too well that a better front-end language would do a world of good for CMake. I also understand that taking a more declarative approach could help that, and I'm not opposed to such a change in principle. However, please take care not to throw the baby out with the bathwater and nerf the expressiveness of what can be done with CMake (in a procedural way). If I understand Brad's suggestion correctly, it would amount to a (possibly empty) procedural step being used to generate a declarative description of the buildsystem. This would work well in our scenario, I believe, as long as that procedural step could be sufficiently modularised on the client side. I fully support introducing an alternative input language to CMake and taking all steps necessary for this to happen, but please do this in a way which will not restrict what CMake is capable of doing. Petr On Fri, Jan 8, 2016 at 5:30 PM, Brad King wrote: > Hi Charles, > > Thanks for your efforts in exploring this topic. CMake's current language > grew incrementally out of something that was not originally intended as a > programming language. The cmState refactoring Stephen Kelly has started > is a huge step toward enabling alternative languages, but there is a long > way to go. > > A few general thoughts: > > * One rule we have for CMake is to never expose any public SDK of the C++ > implementation structures. We want to be able to rewrite them > arbitrarily > at any time. Therefore any solution that needs to access the C++ > structures must be integrated into CMake upstream and expose > functionality > only through other languages or file formats. > > * The cmState infrastructure builds on a "snapshot" design with a goal of > being able to "fork" configuration/generation temporarily and then revert > back, and to be able to re-start configuration from the middle. These > goals may be incompatible with any language whose implementation we do > not fully control unless it is allowed to execute only in isolated and > independent snippets. These are not hard goals, but it is a trade-off > to keep in mind. Stephen may be able to elaborate more on the snapshot > approach if needed. > > * A problem with the current design is that the entire configuration > process > is logically serial making parallel evaluation hard or impossible. In > many cases each add_subdirectory can be processed independently, but this > will require semantic changes to allow. > > On 01/04/2016 02:41 AM, Charles Huet wrote: > > I'm trying to be as declarative as possible, because really like how > readable > > simple QML programs are, and I think it would be perfect for a > buildsystem. > > Ideally most of the specification (sources, libraries, executables, etc.) > should be in a pure format that can be evaluated without side effects (e.g. > declarative or functional). This rules out both Python and Lua, but the > specification format does not have to be the main entry point. There could > be some imperative configuration step that does system introspection and > then loads the pure specification and evaluates it as needed for the > specific > environment. > > If we're going to go through the effort to provide an alternative input > format, > I think we should strive for this approach because it will be more > flexible in > the long run. A pure specification format will allow easy loading/saving > by > other tools, IDEs, etc., without having to process any imperative logic. > > > Actually, I'm directly using the cmMakefile, because I did not want to > wrap all > > the commands, and it seemed backwards to me to wrap them. > > Yes. Any alternative format should be processed directly into the > structures > used by the generators. The cmState work has separated the generate-time > representation quite a bit from the configuration-time > (cmake-language-specific) > representation, but I think there is still further work needed to finish > that. > > >> Having said all that, Brad favors Lua I believe, and he favors a > different > >> approach (which no one is working on as far as I know) to adding a new > >> language. So wait to hear from him to know whether it is something that > >> would be upstreamable. > > > > Have any details on the approach in question? > > See above. Lua has come up several times in the past in particular because > its implementation is meant to be small and embeddable. I've thought a few > times about how to make Lua scripting available from within the CMake > language > in a clean way, but that will not be as valuable as the above pure-spec > approach. > > > Here is what my test POC looked like for generating a simple shared > library: > > > > #!/usr/bin/env python > > # -*- coding: utf-8 -*- > > importcmake > > > cmake.init("Ninja","/media/dev/src/cmaketest","/media/dev/build/cmaketest") > > myProject=cmake.Project("MyTestProject") > > myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] > > cmake.generate() > > I do not think we should have the build specification depend on processing > code like this. It is not compatible with cmake-gui where the > configuration > and generation steps are triggered by the user. However, this does serve > as a good POC that we can populate the generator structures with another > language. > > In summary, I think work in this direction should first focus on designing > a declarative (or functional) specification format where most of the > project > information can be specified. Then a cmake-language command can be written > to load and evaluate a specification file (as a transition). Finally we > could look at replacing the entry-point language with something else. At > that point we could have closures passed as parameters to the evaluation of > the pure spec in order to get custom generate-time logic. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Mon Jan 11 09:59:35 2016 From: aleixpol at kde.org (Aleix Pol) Date: Mon, 11 Jan 2016 15:59:35 +0100 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: <56923C33.6030506@gmail.com> References: <56923C33.6030506@gmail.com> Message-ID: On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly wrote: > > Hello, > > I've been working on adding a daemon mode for cmake to provide > information to user tools - such as IDEs - about the buildsystem. > > Following the discussion about providing metadata for IDEs to consume > I proposed creating a long-running process which would provide a protocol > to access information about the buildsystem, and about the content of the > cmake files themselves: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 > > The original post in that thread lists design goals. > > This design is independent of any generator, and compared to the solution of > writing json to a file, this solution doesn't require generating > anything that is > not asked for. This also side-steps the problem of 'stale' files remaining > in the build directory, and the problem of needing to trigger re-generation > of the file, or watching it for changes. This solution also allows > parameters (eg the config) to be specified in requests, side-stepping a > difficulty we encountered before to represent things like that. This > solution also does not require actually generating the buildsystem > files. Only the configure and compute steps of cmake are executed. > > I am scheduled to give a talk at FOSDEM about the feature and how user > tools can interact with it: > > https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code > > with a preview in Berlin: > > http://www.meetup.com/berlincplusplus/events/227896427/ > > I have now also pushed a branch to my github clone with the start of the > server mode: > > https://github.com/steveire/CMake/commits/cmake-daemon > > Currently the branch only makes targets and backtraces etc available via > the protocol. I have also created a plan for extending the protocol to > make code completion and variable debugging possible, and analysed the > depedencies of the tasks: > > http://www.steveire.com/cmake-daemon-tasks.png > > However, I can't complete those tasks myself: I don't have > relevant experience building IDEs to know how best to design the > protocol, what IDE tools really need, how to design a fail-safe parser > etc. Additionally, I think a design which incorporates design ideas > and implementation from more than one person will be better in the end. > > So, this needs to be a collaborative effort if it is to go anywhere, with > more people writing commits in the cmake repo. > > The above (copied below) task list would be enough to get a read-only > browser of a cmake project quite quickly. > > Following that, an effort would be needed to handle the difference > between the dirty state of an editor and the on-disk file content. That's > a solvable problem and together with filesystem notifications provided > by libuv, it will lead to features like code completion. > > Also necessary eventually would be to make the cmake parser more > fail-safe, so that information is still available if the user > had not yet closed a command argument list for example, and make the > processing more fail-safe in the case where they have written > add_subdirectory(foo), but have not yet created foo/CMakeLists.txt. > > I would be looking to people who work on IDEs for guidance on how to do > things like that, as some of them are likely already for handling C++ > code in the IDEs. > > So, this needs to be a collaborative effort. I can provide guidance to > anyone who wishes to participate in changing the source code of CMake > to make it possible. > > Is anyone interested enough in this potential cmake feature to > join the development effort? > > Thanks, > > Steve. > > > * Provide basic daemon mode with event loop and communication protocol > -- Written, but not reviewed > * Provide protocol to query the buildsystem structure > -- Written, but not complete or reviewed > * Extend cmListFileParser to record location of start and end of commands > * Rewrite cmIfCommand to record which branches are executed > * Store the location of start and end of user-defined functions > * Provide protocol to query for unexecuted lines > * Define a new snapshot type to occur at an arbitrary point > * Create snapshots after branching to other files (after an include() or > find_package() or add_subdirectory etc) > * Create snapshots after points with external effects (file(WRITE), > configure_file(), execute_process etc) > * Find most recent snapshot occuring before a specified line > * Implement feature to start at a specific snapshot and execute commands > up to a particular line > * Make server find correct snapshot to start at and execute required > commands up to specified line > * Provide protocol to dump variable defintions at a particular line > * Extract implementation of IssueMessage from cmMakefile and > cmLocalGenerator into cmake > * Extract computed target properties from cmTarget::GetProperty into > cmComputedTargetProperties > * Implement cmGeneratorTarget::GetProperties in terms of > cmComputedTargetProperties > * Move implementation of cmTarget::{Get,Set,Append}Property to cmState > * Extract all IssueMessage parts of cmake into a cmMessenger > * Extract the cmSystemTools::Message part of cmMessenger into a virtual > method > * Publish messages through server protocol > * Implement snapshot-versioning of target properties > * Dump target property content > * Implement snapshot versioning of policies > * Implement snapshot-versioning of directory properties > * Implement snapshot-versioning of global properties > * Dump directory, global properties and policies > * Extend protocol to provide dirty buffers from editors, instead of only > executing on-disk commands > * Provide code completion protocol Hi Stephen, everyone, I've already discussed this in private with you. I think it's a good idea and I'd like to make sure we can benefit from this. I'm unsure of the feasibility of the project though. Getting any changes in cmake takes forever (this initiative started almost 2 years ago already and it hasn't had any impact yet) and we still need to proof the approach and make sure it has mechanisms to provide retro-compatibility. At least to some extent. At the very least, I'd like to see cmake maintainers committing to the initiative, to make sure I don't waste more of my time. Regards, Aleix From charles.huet at gmail.com Mon Jan 11 12:24:20 2016 From: charles.huet at gmail.com (Charles Huet) Date: Mon, 11 Jan 2016 17:24:20 +0000 Subject: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python) In-Reply-To: References: <568FE440.5090009@kitware.com> Message-ID: Hi, > * The cmState infrastructure builds on a "snapshot" design with a goal of being able to "fork" configuration/generation temporarily and then revert back, and to be able to re-start configuration from the middle. These goals may be incompatible with any language whose implementation we do not fully control unless it is allowed to execute only in isolated and independent snippets. These are not hard goals, but it is a trade-off to keep in mind. Stephen may be able to elaborate more on the snapshot approach if needed. I think these goals aim towards a faster configure, and the ability to only partly reconfigure, right ? > * A problem with the current design is that the entire configuration process is logically serial making parallel evaluation hard or impossible. In many cases each add_subdirectory can be processed independently, but this will require semantic changes to allow. I know I am largely biased by the project I work on, but I do not see how parallel evaluation woud be a huge benefit. We basically have a "core" library, and lots of libs that link against it (and other libs, such as third parties). How would a target B that depends on lib A be processed in this case ? Wouldn't the evaluation of the link_libraries of B be waiting for the evaluation of A to finish ? If this is the case, then parallel evaluation would be only a slight benefit (again, heavily biased by the project I work on). And how would that work with CMakeLists that affect their parent scope ? > Ideally most of the specification (sources, libraries, executables, etc.) should be in a pure format that can be evaluated without side effects (e.g. declarative or functional). I'm not sure I understand how this could be done without losing a lot of what CMake offers, such as copying or generating files. I'm leaning towards a declarative approach as it is quite easy to learn (since you declare objects, and every C++ programmer I know is familiar with those), and functional, while powerfull and very elegant for some things, is quite foreign to C+ programmers as a whole (I know C++11 adds this, but it will be years until this can be used in production for lots of C++ users, because of old compilers that are still supported for business reasons). Moreover, object-oriented is easy to introspect, offering an abstract representation for IDEs and tools. It seems you are leaning towards pure functional, but I do not see how this would work with the current way CMake handles variables and scope, could you elaborate ? > I do not think we should have the build specification depend on processing code like this. It is not compatible with cmake-gui where the configuration and generation steps are triggered by the user. My POC is far from complete, and what I had in mind to keep the CMake-gui approach was to make generating optional in CLI through a parameter. Thus executing the script would only configure, which would populate the CMakeCache, allowing the user to modify variables and such, then configure. To clarify, only the following lines should be considered when looking at the POC. > myProject=cmake.Project("MyTestProject") > myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] > In summary, I think work in this direction should first focus on designing a declarative (or functional) specification format where most of the project information can be specified. Then a cmake-language command can be written to load and evaluate a specification file (as a transition). Finally we could look at replacing the entry-point language with something else. At that point we could have closures passed as parameters to the evaluation of the pure spec in order to get custom generate-time logic. It seems you have in mind to write a new CMake language. I'd rather see an existing language used, such as OCaml or lisp if you want a pure functional language. Those are supported by SWIG so prototyping would be easy. Javascript is even an option that is not *completely* crazy, as it has a C-Style syntax so it would be an easy language to write in for C++ programmers. I think using an existing language has quite a few benefits: * no need to design or implement a language * lots of existing resources on how to do things * lots of existing libraries (data structures, file system operations, etc) * tooling (auto-complete, debugging, profiling, linting, etc) Maybe I should take my POC further, in order to see the failings of this approach, and maybe the same should be done for a more functional approach. CMake's own buildsystem seems like a good testing ground for this, but it is a little too big for a first go, do you know of a small CMake-based project that would be better suited ? I don't have a clear view of what a pure functional CMake would look like, but if you give me some mock code, I could give a try at bringing some pure functional language up to the level of my POC and we could use it as a more cconcrete discussion support. Best Le lun. 11 janv. 2016 ? 10:54, Petr Kmoch a ?crit : > Hi all. > > I'd like to voice my opinion as a somewhat advanced CMake user here. > > For me, one of the strongest points of CMake is the fact that its project > specification is procedural rather than declarative. In my current job, for > example, we have a significant framework built in CMake which handles a lot > of unique setups we have (which were largely inherited from a previous > inhouse buildsystem). Yes, the end result of our framework is that the > CMakeLists consist mostly of declarative commands from our framework, but > the implementation of these commands is heavily procedural. I am convinced > that if CMake didn't give us the procedural power required to make this > work, we couldn't have adopted it. (I had previously tried emulating bits > of this setup in a more declarative system and failed miserably). > > Of course (having written much of this framework I'm talking about above), > I know all too well that a better front-end language would do a world of > good for CMake. I also understand that taking a more declarative approach > could help that, and I'm not opposed to such a change in principle. > However, please take care not to throw the baby out with the bathwater and > nerf the expressiveness of what can be done with CMake (in a procedural > way). > > If I understand Brad's suggestion correctly, it would amount to a > (possibly empty) procedural step being used to generate a declarative > description of the buildsystem. This would work well in our scenario, I > believe, as long as that procedural step could be sufficiently modularised > on the client side. > > I fully support introducing an alternative input language to CMake and > taking all steps necessary for this to happen, but please do this in a way > which will not restrict what CMake is capable of doing. > > Petr > > On Fri, Jan 8, 2016 at 5:30 PM, Brad King wrote: > >> Hi Charles, >> >> Thanks for your efforts in exploring this topic. CMake's current language >> grew incrementally out of something that was not originally intended as a >> programming language. The cmState refactoring Stephen Kelly has started >> is a huge step toward enabling alternative languages, but there is a long >> way to go. >> >> A few general thoughts: >> >> * One rule we have for CMake is to never expose any public SDK of the C++ >> implementation structures. We want to be able to rewrite them >> arbitrarily >> at any time. Therefore any solution that needs to access the C++ >> structures must be integrated into CMake upstream and expose >> functionality >> only through other languages or file formats. >> >> * The cmState infrastructure builds on a "snapshot" design with a goal of >> being able to "fork" configuration/generation temporarily and then >> revert >> back, and to be able to re-start configuration from the middle. These >> goals may be incompatible with any language whose implementation we do >> not fully control unless it is allowed to execute only in isolated and >> independent snippets. These are not hard goals, but it is a trade-off >> to keep in mind. Stephen may be able to elaborate more on the snapshot >> approach if needed. >> >> * A problem with the current design is that the entire configuration >> process >> is logically serial making parallel evaluation hard or impossible. In >> many cases each add_subdirectory can be processed independently, but >> this >> will require semantic changes to allow. >> >> On 01/04/2016 02:41 AM, Charles Huet wrote: >> > I'm trying to be as declarative as possible, because really like how >> readable >> > simple QML programs are, and I think it would be perfect for a >> buildsystem. >> >> Ideally most of the specification (sources, libraries, executables, etc.) >> should be in a pure format that can be evaluated without side effects >> (e.g. >> declarative or functional). This rules out both Python and Lua, but the >> specification format does not have to be the main entry point. There >> could >> be some imperative configuration step that does system introspection and >> then loads the pure specification and evaluates it as needed for the >> specific >> environment. >> >> If we're going to go through the effort to provide an alternative input >> format, >> I think we should strive for this approach because it will be more >> flexible in >> the long run. A pure specification format will allow easy loading/saving >> by >> other tools, IDEs, etc., without having to process any imperative logic. >> >> > Actually, I'm directly using the cmMakefile, because I did not want to >> wrap all >> > the commands, and it seemed backwards to me to wrap them. >> >> Yes. Any alternative format should be processed directly into the >> structures >> used by the generators. The cmState work has separated the generate-time >> representation quite a bit from the configuration-time >> (cmake-language-specific) >> representation, but I think there is still further work needed to finish >> that. >> >> >> Having said all that, Brad favors Lua I believe, and he favors a >> different >> >> approach (which no one is working on as far as I know) to adding a new >> >> language. So wait to hear from him to know whether it is something that >> >> would be upstreamable. >> > >> > Have any details on the approach in question? >> >> See above. Lua has come up several times in the past in particular >> because >> its implementation is meant to be small and embeddable. I've thought a >> few >> times about how to make Lua scripting available from within the CMake >> language >> in a clean way, but that will not be as valuable as the above pure-spec >> approach. >> >> > Here is what my test POC looked like for generating a simple shared >> library: >> > >> > #!/usr/bin/env python >> > # -*- coding: utf-8 -*- >> > importcmake >> > >> cmake.init("Ninja","/media/dev/src/cmaketest","/media/dev/build/cmaketest") >> > myProject=cmake.Project("MyTestProject") >> > myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] >> > cmake.generate() >> >> I do not think we should have the build specification depend on processing >> code like this. It is not compatible with cmake-gui where the >> configuration >> and generation steps are triggered by the user. However, this does serve >> as a good POC that we can populate the generator structures with another >> language. >> >> In summary, I think work in this direction should first focus on designing >> a declarative (or functional) specification format where most of the >> project >> information can be specified. Then a cmake-language command can be >> written >> to load and evaluate a specification file (as a transition). Finally we >> could look at replacing the entry-point language with something else. At >> that point we could have closures passed as parameters to the evaluation >> of >> the pure spec in order to get custom generate-time logic. >> >> 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 >> > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jan 11 13:10:31 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Jan 2016 13:10:31 -0500 Subject: [cmake-developers] VS_GLOBAL_ properties in VS 2010+ (was: patch building and testing) In-Reply-To: References: <568FE445.5040503@kitware.com> Message-ID: <5693F017.5040202@kitware.com> On 01/08/2016 05:56 PM, Mike Fitzgerald wrote: > I've got the attached, which gives me the results I'd expect Great, thanks. I've applied this and merged to 'next' for testing: VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af39f115 > If I should be adding a test for this property The property has an existing smoke test in Tests/VSResource but that does not actually check that anything works. The above-linked change is acceptable on its own since the existing property was not tested for VS 2008 and below even though it was implemented. However, we'd appreciate it if you could look at adding tests. Take a look at Tests/RunCMake/XcodeProject Tests/RunCMake/SolutionGlobalSections These directories have test cases that check the actual content of the generated Xcode projects and VS .sln files. Something similar could be added to check for the results of this property in .vcxproj files. Thanks, -Brad From swel024 at gmail.com Mon Jan 11 13:18:08 2016 From: swel024 at gmail.com (Simon Wells) Date: Tue, 12 Jan 2016 07:18:08 +1300 Subject: [cmake-developers] Fwd: FindwxWidgets.cmake In-Reply-To: References: Message-ID: The following code is line 191-201, I have tested without this being set on OSX 10.11 using system clang and both self-built and brew installed wxwidgets with no problems, Whether its still an issue using gcc on osx or some other configuration i am unsure, but is it worth being more specific than just If APPLE for this bug-fix/workaround # Using SYSTEM with INCLUDE_DIRECTORIES in conjunction with wxWidgets on # the Mac produces compiler errors. Set wxWidgets_INCLUDE_DIRS_NO_SYSTEM # to prevent UsewxWidgets.cmake from using SYSTEM. # # See cmake mailing list discussions for more info: # https://cmake.org/pipermail/cmake/2008-April/021115.html # https://cmake.org/pipermail/cmake/2008-April/021146.html # if(APPLE OR CMAKE_CXX_PLATFORM_ID MATCHES "OpenBSD") set(wxWidgets_INCLUDE_DIRS_NO_SYSTEM 1) endif() thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Mon Jan 11 13:21:36 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 11 Jan 2016 19:21:36 +0100 Subject: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python) In-Reply-To: <568FE440.5090009@kitware.com> References: <568FE440.5090009@kitware.com> Message-ID: On Fri, Jan 8, 2016 at 5:30 PM, Brad King wrote: > See above. Lua has come up several times in the past in particular because > its implementation is meant to be small and embeddable. I've thought a few > times about how to make Lua scripting available from within the CMake > language > in a clean way, but that will not be as valuable as the above pure-spec > approach. > > Please, do not do that. The moment you make CMake scriptable in more than one language, you are forcing every CMake user to learn that additional language because sooner or later he will step into a third-party that is using that additional language. IMHO, if you want Lua, then Lua it is. But then please get rid of CMake scripting. BTW, I am sure you are aware of CMakeScript, CMake scripting in JavaScript: http://sourceforge.net/projects/cmakescript/ Also, declarative? Why? There are already a few declarative build systems (e. g. qbs, one of the reasons for its existence was CMake was not declarative). By moving CMake from the current procedural scripting to a declarative approach, you may alienate your current user base and be good for none anymore. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tholag at gmail.com Mon Jan 11 15:29:39 2016 From: tholag at gmail.com (Thomas) Date: Mon, 11 Jan 2016 20:29:39 +0000 Subject: [cmake-developers] Visual Studio 2015 FastLink Message-ID: Dear Cmake developers, as a follow up of this bug https://cmake.org/Bug/view.php?id=15894 I'm writing to request support for the /Debug:FastLink flag which was introduced in visual studio 2015 (update 1), and the option to generate full PDB informations. http://blogs.msdn.com/b/vcblog/archive/2015/10/16/debug-fastlink-for-vs2015-update-1.aspx Brad King already setup the correct framework in "next" branch to implement the /Debug:FastLink and with the proposed patch (last topic in the bug) it works good. About the "Generate Full PDB informations" , is a new option that can be used to re-use pdbs generated with the fastlink flag in a different computer from the one who did the compilation (it may be useful sometimes). That option seems to doesn't have a (public) command line switch, instead it relies on an XML property. When the user requests "Generate Full PDB informations", the generator should add true in the section. What's the best way to set a TARGET or global property which would enable the switchless XML property in the generator? Thanks! Qb -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jan 11 15:53:47 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Jan 2016 15:53:47 -0500 Subject: [cmake-developers] CMake alternative language In-Reply-To: <568FE440.5090009@kitware.com> References: <568FE440.5090009@kitware.com> Message-ID: <5694165B.5040803@kitware.com> Hi Folks, I'm replying directly to my previous post in this thread in order to consolidate responses to related discussion raised in others' responses to it: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389 General comments: * There is a lot of code out there in the current CMake language so I do not think it is realistic to drop it. I'm not proposing that this change. * CMake's procedural/imperative design is good as the main entry point to configuration of a project. It can do system introspection, file generation, etc. I'm not proposing that this change. * Many projects build elaborate macro/function systems in the CMake language in order to end up with a declarative specification listing the actual source files, dependencies, and usage requirements. I'd like to offer an alternative to this. * Integration with IDEs is currently based on one-way generation (VS IDE projects, Xcode projects, CodeBlocks, etc.). Editing the project build specification requires editing CMake code directly because IDEs cannot easily pierce CMake's procedural/imperative specification: https://cmake.org/pipermail/cmake-developers/2016-January/027386.html I'd like to improve this by *optionally* moving part of the specification to a (stateless) declarative format that IDEs can load/edit/save directly. Specific responses follow. -------------------------------------------------------------------------------- On 01/11/2016 12:24 PM, Charles Huet wrote: > I think these goals aim towards a faster configure, and the ability to > only partly reconfigure, right? Yes. > I know I am largely biased by the project I work on, but I do not see how > parallel evaluation woud be a huge benefit. [snip] > And how would that work with CMakeLists that affect their parent scope ? Evaluation of the imperative language is currently serial for reasons like this, which is why I said it would take semantic changes to enable parallel evaluation. This is not the main point of my proposal so I'd rather not get bogged down in the details of this part of the discussion. >> Ideally most of the specification (sources, libraries, executables, etc.) >> should be in a pure format that can be evaluated without side effects (e.g. >> declarative or functional). > > I'm not sure I understand how this could be done without losing a lot of > what CMake offers, such as copying or generating files. I'm not proposing dropping the current imperative capabilities. > I'm leaning towards a declarative approach as it is quite easy to learn > (since you declare objects, and every C++ programmer I know is familiar > with those) Yes. > It seems you are leaning towards pure functional, but I do not see how > this would work with the current way CMake handles variables and scope, > could you elaborate ? While declarative may get us most of the way, advanced users may wish to hook in to generation-time evaluation. A clean way to do that would be to specify a function within the declared values. It would not have to be in a functional language as long as it has no access to anything other than the inputs passed to it during evaluation. I mentioned "functional" mostly as an example of a specification whose evaluation is free of side effects. > To clarify, only the following lines should be considered when looking at the POC. >> myProject=cmake.Project("MyTestProject") >> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] Yes, this is the kind of stuff that can be in a declarative format. > It seems you have in mind to write a new CMake language. No, at most a new specification format that can be used for IDE integration. If some kind of user-coded function were included in the specification it should certainly be in an existing language. > Maybe I should take my POC further I think implementation even of a POC is premature at this point. We should explore the design space further. > CMake's own buildsystem seems like a good testing ground for this, but > it is a little too big for a first go, do you know of a small CMake-based > project that would be better suited ? Maybe you could find something in our test suite. > I don't have a clear view of what a pure functional CMake would look like, > but if you give me some mock code, I could give a try at bringing some pure > functional language up to the level of my POC and we could use it as a more > concrete discussion support. I have no prototype (nor substantial time to spend on design myself) but I've imagined a declarative format in a well-known syntax (e.g. JSON or one of the lightweight human-friendly choices). If generate-time functionality is needed then code snippets in e.g. Lua could be included. -------------------------------------------------------------------------------- Petr Kmoch wrote: > I'd like to voice my opinion as a somewhat advanced CMake user here. Thanks for joining the discussion with this point of view. > For me, one of the strongest points of CMake is the fact that its project > specification is procedural rather than declarative. Good. We will not be dropping imperative capabilities. > end result of our framework is that the CMakeLists consist mostly of > declarative commands from our framework Yes, many projects have such frameworks. Most of them result in a declarative spec inside calls to their macros/functions. I'd like to formalize such specs in a re-usable way. > If I understand Brad's suggestion correctly, it would amount to a > (possibly empty) procedural step being used to generate a declarative > description of the buildsystem. Not quite. Yes, the procedural/imperative part would still be the entry point as it is now. However, the declarative part would also be an input, not an output. The procedural part's role would be to compute *parameters* to be used for the evaluation of the declarative spec. For example, imagine the declarative spec somehow encodes that source file "foo.c" is optional based on some condition "FOO". The value of that condition could be computed by the procedural part of the process based on system introspection, command-line options, etc., and then provided to CMake for use in the final evaluation. -------------------------------------------------------------------------------- On 01/11/2016 01:21 PM, Pau Garcia i Quiles wrote: > The moment you make CMake scriptable in more than one language, you are forcing > every CMake user to learn that additional language because sooner or later he > will step into a third-party that is using that additional language. I don't think the main "entry point" language should be selectable. As discussed above if some kind of callback or user-coded function needs to be included for advanced usage of the declarative spec then we would need a language for it. The current CMake language is not well suited to that use case (e.g. no expressions or return values), so an existing alternative language should be chosen. CMake's current "generator expressions" fill this role somewhat now and are essentially a sub-language. As with the main language they grew out of something not intended to serve their current full role. They could be superseded by a common alternative generate-time language too. > Also, declarative? Why? See above. > There are already a few declarative build systems Yes, and perhaps we can learn from their formats for the proposed declarative part. > qbs, one of the reasons for its existence was CMake was not declarative IIUC that is exactly because of the fact that an imperative spec cannot be pierced easily for editing in IDEs. -------------------------------------------------------------------------------- Thanks all for the discussion so far! -Brad From brad.king at kitware.com Mon Jan 11 15:54:05 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Jan 2016 15:54:05 -0500 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: <5694166D.90409@kitware.com> On 01/11/2016 09:59 AM, Aleix Pol wrote: > I'm unsure of the feasibility of the project though. Getting any > changes in cmake takes forever (this initiative started almost 2 years > ago already and it hasn't had any impact yet) This particular change will establish a much wider contract between CMake and IDEs than we have now, and it has never been clear what the best approach should be. That is why this change is taking so long. It was unfortunate that your (Aleix's) first iteration I reviewed and guided last year got so far and took you so much of your time before others came forward with criticisms of the approach, but I think in the long run we can do something better. > and we still need to proof the approach and make sure it has mechanisms > to provide retro-compatibility. At least to some extent. > > At the very least, I'd like to see cmake maintainers committing to the > initiative, to make sure I don't waste more of my time. Stephen's cmState refactoring has been a fantastic cleanup and improvement of the organization of CMake's implementation. It is a major step toward separating the configuration and generation steps and will be useful for many future directions of CMake. However, after needing to make fixes between 3.4.0 and 3.4.1 like these: cmState: Avoid accumulating policy stack storage for short-lived scopes https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f21dc4a8 cmState: Avoid accumulating snapshot storage for short-lived scopes https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f860ebb I'm concerned that the memory usage of a daemon implementing the proposed capabilities may be too large to be practical (at least without a major redesign of certain structures that tend to duplicate substrings, or some kind of out-of-core approach). The proposed daemon could help IDEs integrate with the CMake language without re-implementing it, but we may not need such heavy infrastructure for IDEs just to list targets and sources and allow users to edit them. The current need for it is due to the fact that the build specification is in an imperative language instead of a declarative format. I think a better approach forward is that discussed in this thread: CMake alternative language http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15374 Over there I propose moving the majority of the specification into a stateless format that IDEs could more easily load, edit, and save. While the daemon proposed here may have value, I think we should first resolve discussion of the approach proposed in the other thread. -Brad From mantis at public.kitware.com Mon Jan 11 16:07:26 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 11 Jan 2016 16:07:26 -0500 Subject: [cmake-developers] [CMake 0015909]: FindDCMTK.cmake outdated Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15909 ====================================================================== Reported By: dkuegler Assigned To: ====================================================================== Project: CMake Issue ID: 15909 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-11 16:07 EST Last Modified: 2016-01-11 16:07 EST ====================================================================== Summary: FindDCMTK.cmake outdated Description: The FindDCMTK in CMake is very outdated. It produces errors and all the libraries and paths have to be set up manually. The script straight up, does not find DCMTK, even if specifically pointed to the right path with DCMTK_DIR. But there is a up-to-date buildscript, that works properly in the CTK toolkit: https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake So I would propose to use that file. Steps to Reproduce: install DCMTK build DCMTK create a CMakeLists.txt with set(DCMTK path/to/dcmtk/build/folder) find_package(DCMTK) Additional Information: tested with Windows 8.1, CMake 3.3, 3.4 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-11 16:07 dkuegler New Issue ====================================================================== From brad.king at kitware.com Mon Jan 11 16:36:25 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Jan 2016 16:36:25 -0500 Subject: [cmake-developers] FindwxWidgets.cmake In-Reply-To: References: Message-ID: <56942059.4040909@kitware.com> On 01/11/2016 01:18 PM, Simon Wells wrote: > The following code is line 191-201, I have tested without this being set > on OSX 10.11 using system clang and both self-built and brew installed > wxwidgets with no problems, Whether its still an issue using gcc on osx > or some other configuration i am unsure, but is it worth being more > specific than just If APPLE for this bug-fix/workaround Thanks. The only way to get more detail on the problems is to wait for someone to hit them again. Meanwhile we can just restore -isystem: FindwxWidgets: Drop suppression of -isystem https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d05f195 -Brad From taylor at braun-jones.org Mon Jan 11 16:47:03 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Mon, 11 Jan 2016 16:47:03 -0500 Subject: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties? In-Reply-To: <568FC3C1.50803@gmail.com> References: <568F9BB7.7090604@gmail.com> <568FB358.9060005@gmail.com> <568FC3C1.50803@gmail.com> Message-ID: On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz wrote: > > > On 01/08/2016 02:50 PM, Yves Frederix wrote: > >> You are explicitly mentioning 'setting' of a property. IMHO there is a >> big difference between setting and getting a property. If >> white/blacklisting is enforced during setting only, wouldn't this be >> sufficient? This would make it possible to simply access all >> properties that are automatically assigned to the target (which I >> assume implies that by definition they should make sense?). A >> non-acceptable property could not have been set and would hence not be >> found, making it possible to check for its existence in the "standard" >> way. >> > > The same argument might hold for getting of properties. > E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties > now but was implemented in the future. > > A user might e.g. think that a specific property should work because CMake >>> did not issue any diagnostics and open an issue. >>> The diagnostic implies that this behavior is by design. >>> >>> It also prevents users from using existing properties which currently >>> don't >>> have semantics for INTERFACE targets but might be implemented in the >>> future >>> (potentially with different semantics than expected by the user). >>> >> Ok, this somehow contradicts my above assumption and is somewhat >> surprising. Wouldn't it make sense to simply not set these properties >> in the first place if they have incorrect semantics? This way, >> get_property would not need to care about them and it would anyhow not >> stop their correct implementation in the future. >> > > I meant existing as in defined for regular build targets not as in > actually set for interface targets. > get_property() would return an empty string for those if they weren't > whitelisted and one might argue that this could suffice. > On the other hand users often assume that they get a valid value and don't > actually check. > > >>> I think allowing custom (non cmake defined) properties might be a valid >>> argument. >>> These could perhaps also be supported through e.g. user extension of the >>> whitelist. >>> >> I like this idea. With this in place, one would not need to wait for a >> new CMake release if a valid property were missing from the whitelist >> or if one wanted to use custom properties. >> >> I don't think anything should be changed however unless there are actual >>> use >>> cases that aren't supported by the current implementation. >>> >> Does this mean that you would have doubts about patches that: >> - provide a way for the user to extend the whitelist? >> - remove the need for whitelisting in get_property by making CMake >> only automatically assign sensible target properties? >> > > The issue is less that CMake assigns these properties (I don't know of any > such case but I haven't checked) and more that users might just expect them > to be set (which does not provide a diagnostic). > > Personally I would not object to either approach as long as there are > actual use cases. > Without use cases such changes would be by definition useless. I have another INTERFACE property use case that is not whitelisted, but should be: VERSION Consider library project Foo that uses a header-only project Bar. In FooConfig.cmake, it is a important to ensure any projects using Foo also use the exact same version of Bar that Foo was originally built with (Failure to do so can lead to subtle, hard-to-find bugs like violation of the one definition rule). Assuming project Bar creates an imported target "Bar" with a VERSION property set like: set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3) Then project Foo should be able to have something like: == CMakeLists.txt == ... get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION) configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY) == FooConfig.cmake.in == ... find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED) But, alas, this is not currently possible. I'm ambivalent about whether INTERFACE properties should be whitelisted vs blacklisted vs unrestricted, but at least this VERSION property seems valid to allow. Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Mon Jan 11 17:22:23 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 11 Jan 2016 23:22:23 +0100 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: <16894351.04HyfLIrgp@tuxedo.neundorf.net> On Monday, January 11, 2016 15:59:35 Aleix Pol wrote: ... > > Hi Stephen, everyone, > I've already discussed this in private with you. I think it's a good > idea and I'd like to make sure we can benefit from this. > > I'm unsure of the feasibility of the project though. you maybe remember that my main issue with your patch last year was that it's not a "generator", while it does what generators are for. After talking with Milian a bit several week ago, I understood that an important reason why the kdevelop team does not want a generator is that there is only one generator per build-tree, i.e. the user has to decide beforehand which IDE project files he wants. With the branch I created on github a few days ago, which I announced here too, I changed the way the extra generators are activated: they are not activated like the main generators anymore, but can be turned on and off using normal cmake cache options, so multiple generators (e.g. the generic json generator and let's say the Eclipse generator) can both be turned on, initially or later on. I think this should solve this problem. The work there (https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental ) is not ready for inclusing, but it shows how it can be done and can serve as a starting point/inspiration. Stephens big approach will need some time until it is ready, while such a (relatively) simple thing can probably be done within one release cycle (but I don't have the time to do it). I don't know what the others here think about adding your json-approach or not. Alex From tobias.hunger at gmail.com Tue Jan 12 05:15:07 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 12 Jan 2016 11:15:07 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: <56923C33.6030506@gmail.com> References: <56923C33.6030506@gmail.com> Message-ID: Hello Stephen, thanks again for your work and interest in IDE integration! I read Bard's reply as meaning that your cleanup work is a great benefit to cmake, but will probably not be available in the foreseeable future (if at all). Alexander goes back to the generator approach we discussed a year ago and explicitly says he won't work on that, so nothing will happen there. The current state -- as I see it -- is this: While I like cmake for command line use, it is the worst build system with regards to IDE integration that I have to support in Qt Creator. Even autotools support is less than half the code needed to support cmake -- and believe me, I never expected to give autotools as a positive example;-) So could we please get a *documented* way that an IDE can *rely on to be available* that provides basic information on a project/configuration: * Source directory, build directory * Files that belong to the project (sources, headers, custom cmake modules, CMakeLists.txts, resources, ...) * Files that belong to the build system (anything that needs watching to re-generate the IDE-integration information at the right times) * Targets that can be built * Files that belong to each target * Compiler flags * Defines in effect * Include paths used * The compilers used to build those files Ideally I would not need to write files to disk to get that information. I do not know enough about cmake internals to suggest the best approach to implement this, but something that can be extended would be great, as this is really just the very basic information needed and more information would be welcome at a later point. Interactive features like syntax highlighting of CMakeFiles or adding files to the build system in are of little interest to me at this point: I see little reason to implement anything along those lines while I can not reliably read the information needed for the code model. Best Regards, Tobias On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly wrote: > > Hello, > > I've been working on adding a daemon mode for cmake to provide > information to user tools - such as IDEs - about the buildsystem. > > Following the discussion about providing metadata for IDEs to consume > I proposed creating a long-running process which would provide a protocol > to access information about the buildsystem, and about the content of the > cmake files themselves: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 > > The original post in that thread lists design goals. > > This design is independent of any generator, and compared to the solution of > writing json to a file, this solution doesn't require generating > anything that is > not asked for. This also side-steps the problem of 'stale' files remaining > in the build directory, and the problem of needing to trigger re-generation > of the file, or watching it for changes. This solution also allows > parameters (eg the config) to be specified in requests, side-stepping a > difficulty we encountered before to represent things like that. This > solution also does not require actually generating the buildsystem > files. Only the configure and compute steps of cmake are executed. > > I am scheduled to give a talk at FOSDEM about the feature and how user > tools can interact with it: > > https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code > > with a preview in Berlin: > > http://www.meetup.com/berlincplusplus/events/227896427/ > > I have now also pushed a branch to my github clone with the start of the > server mode: > > https://github.com/steveire/CMake/commits/cmake-daemon > > Currently the branch only makes targets and backtraces etc available via > the protocol. I have also created a plan for extending the protocol to > make code completion and variable debugging possible, and analysed the > depedencies of the tasks: > > http://www.steveire.com/cmake-daemon-tasks.png > > However, I can't complete those tasks myself: I don't have > relevant experience building IDEs to know how best to design the > protocol, what IDE tools really need, how to design a fail-safe parser > etc. Additionally, I think a design which incorporates design ideas > and implementation from more than one person will be better in the end. > > So, this needs to be a collaborative effort if it is to go anywhere, with > more people writing commits in the cmake repo. > > The above (copied below) task list would be enough to get a read-only > browser of a cmake project quite quickly. > > Following that, an effort would be needed to handle the difference > between the dirty state of an editor and the on-disk file content. That's > a solvable problem and together with filesystem notifications provided > by libuv, it will lead to features like code completion. > > Also necessary eventually would be to make the cmake parser more > fail-safe, so that information is still available if the user > had not yet closed a command argument list for example, and make the > processing more fail-safe in the case where they have written > add_subdirectory(foo), but have not yet created foo/CMakeLists.txt. > > I would be looking to people who work on IDEs for guidance on how to do > things like that, as some of them are likely already for handling C++ > code in the IDEs. > > So, this needs to be a collaborative effort. I can provide guidance to > anyone who wishes to participate in changing the source code of CMake > to make it possible. > > Is anyone interested enough in this potential cmake feature to > join the development effort? > > Thanks, > > Steve. > > > * Provide basic daemon mode with event loop and communication protocol > -- Written, but not reviewed > * Provide protocol to query the buildsystem structure > -- Written, but not complete or reviewed > * Extend cmListFileParser to record location of start and end of commands > * Rewrite cmIfCommand to record which branches are executed > * Store the location of start and end of user-defined functions > * Provide protocol to query for unexecuted lines > * Define a new snapshot type to occur at an arbitrary point > * Create snapshots after branching to other files (after an include() or > find_package() or add_subdirectory etc) > * Create snapshots after points with external effects (file(WRITE), > configure_file(), execute_process etc) > * Find most recent snapshot occuring before a specified line > * Implement feature to start at a specific snapshot and execute commands > up to a particular line > * Make server find correct snapshot to start at and execute required > commands up to specified line > * Provide protocol to dump variable defintions at a particular line > * Extract implementation of IssueMessage from cmMakefile and > cmLocalGenerator into cmake > * Extract computed target properties from cmTarget::GetProperty into > cmComputedTargetProperties > * Implement cmGeneratorTarget::GetProperties in terms of > cmComputedTargetProperties > * Move implementation of cmTarget::{Get,Set,Append}Property to cmState > * Extract all IssueMessage parts of cmake into a cmMessenger > * Extract the cmSystemTools::Message part of cmMessenger into a virtual > method > * Publish messages through server protocol > * Implement snapshot-versioning of target properties > * Dump target property content > * Implement snapshot versioning of policies > * Implement snapshot-versioning of directory properties > * Implement snapshot-versioning of global properties > * Dump directory, global properties and policies > * Extend protocol to provide dirty buffers from editors, instead of only > executing on-disk commands > * Provide code completion protocol > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator From mantis at public.kitware.com Tue Jan 12 09:54:08 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Jan 2016 09:54:08 -0500 Subject: [cmake-developers] [CMake 0015910]: pkg_check_modules() should add PREFIX/share/pkgconfig to PKG_CONFIG_PATH Message-ID: <8c31af2ff97744855fe0482d16b2363c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15910 ====================================================================== Reported By: Sam Thursfield Assigned To: ====================================================================== Project: CMake Issue ID: 15910 Category: Modules Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-12 09:54 EST Last Modified: 2016-01-12 09:54 EST ====================================================================== Summary: pkg_check_modules() should add PREFIX/share/pkgconfig to PKG_CONFIG_PATH Description: Most packages install their .pc files into PREFIX/lib/pkgconfig, but some put them into PREFIX/share/pkgconfig. Either is valid, and pkg-config itself looks in both for the /usr and /usr/local prefixes. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-12 09:54 Sam Thursfield New Issue 2016-01-12 09:54 Sam Thursfield File Added: cmake-pkg-config-search-path.patch ====================================================================== From brad.king at kitware.com Tue Jan 12 10:05:08 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Jan 2016 10:05:08 -0500 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: <56951624.1040302@kitware.com> On 01/12/2016 05:15 AM, Tobias Hunger wrote: > I read Brad's reply as meaning that your cleanup work is a great > benefit to cmake, but will probably not be available in the > foreseeable future (if at all). Most of Stephen's work completed so far is already in CMake 3.4, and a bit more is in 'master' and will be in 3.5. It has no public-facing changes though so yes more work will be needed to get a solution IDEs can actually use. > Alexander goes back to the generator approach we discussed a year ago > and explicitly says he won't work on that, so nothing will happen > there. The generate-json-description approach remains a valid alternative. Aleix's work on it got pretty far before Stephen proposed the daemon alternative. See more below. IIRC Alexander Neundorf raised concerns only about how to activate the generation of the json description, and has now proposed an approach to resolve those concerns. > So could we please get a *documented* way that an IDE can *rely on to > be available* that provides basic information on a project/configuration: > > * Source directory, build directory > * Files that belong to the project (sources, headers, custom cmake > modules, CMakeLists.txts, resources, ...) > * Files that belong to the build system (anything that needs watching > to re-generate the IDE-integration information at the right times) > * Targets that can be built > * Files that belong to each target > * Compiler flags > * Defines in effect > * Include paths used > * The compilers used to build those files Thank you for summarizing the goal so succinctly. This is different than I had in mind when writing my previous response. Before I was thinking this was about IDEs helping users edit the CMake build system description itself (adding sources, etc.). The above is about IDEs helping users edit their C code with knowledge of how it will be built, thus providing for completion and such. These problems are orthogonal, and your requirements certainly need generation-time information regardless of how the build specification itself is represented. Therefore the discussion here should proceed independent of where the alternative language thread goes. With that cleared up design discussion can proceed. ----------------------------------------------------------------------------- IIUC two approaches have been proposed: 1. CMake generates a JSON description of the above-listed information about the entire build tree for IDEs to use as needed. It can be either one giant file or an index and a bunch of per-target files. The contract between CMake and IDEs is a JSON schema and file(s) on disk. Updating requires the IDE to do a full re-run of CMake. Aleix Pol has implemented a prototype of this approach. 2. CMake offers a daemon that IDEs can contact (e.g. via named pipes) to ask for the information. The contract between CMake and IDEs is a (to-be-designed) protocol (e.g. JSON snippets). Updating would likely be handled internally by the daemon in response to changes to the CMake input files between requests from the IDE. Stephen Kelly has done refactoring work on CMake internals that will be needed to implement such a daemon, but much more work is still needed. Stephen no longer has time to continue his work except to guide others. Aleix is still interested in working on a solution but that makes sense only after we all agree on an achievable one. Is anyone else interested in working on this? Stephen Kelly started this discussion thread with the following summary of the advantages of the daemon approach over the generated JSON files: On 01/10/2016 06:10 AM, Stephen Kelly wrote: > This design is independent of any generator, and compared to the > solution of writing json to a file, this solution doesn't require > generating anything that is not asked for. > This also side-steps the problem of 'stale' files remaining > in the build directory, and the problem of needing to trigger re-generation > of the file, or watching it for changes. This solution also allows > parameters (eg the config) to be specified in requests, side-stepping a > difficulty we encountered before to represent things like that. This > solution also does not require actually generating the buildsystem > files. Only the configure and compute steps of cmake are executed. Given the above summaries my reaction is that the daemon approach is more elegant and desirable in the long run. However, it will require much more time and resources to implement. It is not clear how much more, or if anyone has such time and resources to offer. An intermediate solution could be to offer the daemon and protocol to IDEs but to implement it internally on top of pre-generated JSON files. The schema of the JSON files would remain a private contract between "cmake" and "cmake-daemon". Then over time the implementation of the daemon could be improved by computing things internally on demand instead of updating and reading the JSON files, but the public- facing protocol would not change. We just need to make sure that the protocol is designed to allow such flexibility. OTOH this approach requires designing both the daemon protocol and the JSON format. ----------------------------------------------------------------------------- Note that the generated JSON approach is essentially what we've been doing with the VS IDE since CMake started, just with a different format. Many developers use the VS IDE to develop their CMake-built projects, and they get IntelliSense for completion. It has worked well for years. Perhaps the argument for the daemon approach puts too much focus on the updating case while most developer time is simply spent editing existing sources in their IDE. -Brad From mantis at public.kitware.com Tue Jan 12 10:05:13 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Jan 2016 10:05:13 -0500 Subject: [cmake-developers] [CMake 0015911]: FindPNG: Create an imported PNG::PNG target Message-ID: <07cb9c9fdc67450d93ce2776890ba5be@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15911 ====================================================================== Reported By: Sam Thursfield Assigned To: ====================================================================== Project: CMake Issue ID: 15911 Category: Modules Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-12 10:05 EST Last Modified: 2016-01-12 10:05 EST ====================================================================== Summary: FindPNG: Create an imported PNG::PNG target Description: Imported targets are now the recommended way of dealing with external library dependencies. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-12 10:05 Sam Thursfield New Issue 2016-01-12 10:05 Sam Thursfield File Added: cmake-findpng-imported-target.patch ====================================================================== From mantis at public.kitware.com Tue Jan 12 10:11:32 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Jan 2016 10:11:32 -0500 Subject: [cmake-developers] [CMake 0015912]: FindALSA: Create an imported ALSA:ASound target Message-ID: <2f792f013ed07455c0b9523fa23097d5@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15912 ====================================================================== Reported By: Sam Thursfield Assigned To: ====================================================================== Project: CMake Issue ID: 15912 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-12 10:11 EST Last Modified: 2016-01-12 10:11 EST ====================================================================== Summary: FindALSA: Create an imported ALSA:ASound target Description: Imported targets are now the recommended way of dealing with external library dependencies. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-12 10:11 Sam Thursfield New Issue 2016-01-12 10:11 Sam Thursfield File Added: cmake-findalsa-imported-target.patch. ====================================================================== From brad.king at kitware.com Tue Jan 12 10:37:05 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Jan 2016 10:37:05 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <568B05BB.6060606@gmail.com> References: <566833DF.8080407@kitware.com> <568B05BB.6060606@gmail.com> Message-ID: <56951DA1.2050207@kitware.com> On 01/04/2016 06:52 PM, Michael Scott wrote: > To round off the -W options functionality, I've implemented the -Werror > and -Wno-error set of options for the two current types of messages, dev > and deprecated. This includes updating the QT GUI to include new options > for controlling this functionality. Thanks. I'd first like to resolve the discussion below because it may affect the first patch. > The third patch is not for new functionality, but addresses two small > inconsistencies relating to dev and deprecated messages functionality, > it's not needed at the end of the day but I thought it would be good to > make the code consistent while I was in the area. Most of that change appears to be just the number of spaces after a period. I prefer two which is why the original message was that way. > Lastly I'm also looking at changing all the current usages of the > cmake::IssueMessage command, where the message type is dev warning. To > check if the warning got upgraded to an error (by checking if the error > state has been signalled with the cmSystemTools class), and change the > return value of the calling function for example. I think this was > discussed previously, however I think this might not be the right change > to make. There's quite a few instances of the above code and changing > them all is dangerous I imagine where I don't know exactly what all of > the callers are generally doing and should be doing. It also implies an > undocumented rule that future users of the above functionality should > also do this check, which doesn't sound like a good idea to me. What > are your thoughts on this last point? IIRC we previously concluded that the individual callers don't have to deal with the message type change so long as the overall process exits with an error. Is this currently achieved by the patch? Thanks, -Brad From michael.scott250 at gmail.com Tue Jan 12 13:18:34 2016 From: michael.scott250 at gmail.com (Michael Scott) Date: Tue, 12 Jan 2016 18:18:34 +0000 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <56951DA1.2050207@kitware.com> References: <56951DA1.2050207@kitware.com> Message-ID: <5695437A.1060703@gmail.com> > Most of that change appears to be just the number of spaces after a > period. I prefer two which is why the original message was that way. Ah fair enough, I assumed the two spaces was a typo and was meant to be just one space. Yes essentially the third patch just replaces the two spaces with one, so it can be just ignored in this case. > IIRC we previously concluded that the individual callers don't have to > deal with the message type change so long as the overall process exits > with an error. Is this currently achieved by the patch? Yes that will now happen with the patch, the cmake::displayMessage method will set the error occurred flag, though not the fatal flag, when a deprecation or author error message is displayed. In this case I think there are no issues I'm aware of with the proposed changes. If there are any problems with the proposed changes let me know. Cheers, Michael From brad.king at kitware.com Tue Jan 12 14:05:34 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Jan 2016 14:05:34 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5695437A.1060703@gmail.com> References: <56951DA1.2050207@kitware.com> <5695437A.1060703@gmail.com> Message-ID: <56954E7E.2060303@kitware.com> On 01/12/2016 01:18 PM, Michael Scott wrote: > In this case I think there are no issues I'm aware of with the proposed changes. Great, thanks. Applied and merged to 'next' for testing: Add -Werror and -Wno-error command-line options https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28f2d750 cmake-gui: Add options to control warning-as-error messages https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=82166701 -Brad From brad.king at kitware.com Tue Jan 12 14:30:18 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Jan 2016 14:30:18 -0500 Subject: [cmake-developers] Visual Studio 2015 FastLink In-Reply-To: References: Message-ID: <5695544A.7030106@kitware.com> On 01/11/2016 03:29 PM, Thomas wrote: > https://cmake.org/Bug/view.php?id=15894 > > I'm writing to request support for the /Debug:FastLink flag which was introduced in visual studio 2015 (update 1), and the option to generate full PDB informations. > http://blogs.msdn.com/b/vcblog/archive/2015/10/16/debug-fastlink-for-vs2015-update-1.aspx Thanks. I've applied that change: VS: Map link `/debug:fastlink` flag to VS 2015 IDE property https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc5d6592 > About the "Generate Full PDB informations" [snip] > That option seems to doesn't have a (public) command line switch, > instead it relies on an XML property. If there is no command line switch then how does the IDE behavior change when the FullProgramDatabaseFile property is enabled? > What's the best way to set a TARGET or global property which would > enable the switchless XML property in the generator? Existing target properties that influence VS project generation but nothing else mostly have names starting in "VS_". If the target property would have effects on other generators then we should use a more generic name. Either way, please include associated updates to the documentation. Thanks, -Brad From brad.king at kitware.com Tue Jan 12 14:41:12 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Jan 2016 14:41:12 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> Message-ID: <569556D8.80308@kitware.com> On 01/08/2016 06:15 PM, Eric Wing wrote: > simple 'swiftc' integration going for ADD_EXECUTABLE, as described in > the original post. Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake to get rid of the up-front error. See "Modules/CMakeAddNewLanguage.txt" (many of the steps are already done). Edit Modules/CMakeSwiftInformation.cmake and add settings for variables like CMAKE_Swift_COMPILE_OBJECT and CMAKE_Swift_LINK_EXECUTABLE. See the CMake{C,CXX,Fortran}Information.cmake modules for examples. The available placeholders are in cmLocalGenerator::ExpandRuleVariable. If all the compile/link steps used for C and C++ map well to switfc then it should be fairly straightforward. If other steps are needed or the steps have wildly different semantics then more in-depth changes to the actual generators may be needed. -Brad From steveire at gmail.com Tue Jan 12 15:02:20 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 12 Jan 2016 21:02:20 +0100 Subject: [cmake-developers] CMake daemon for user tools References: <56923C33.6030506@gmail.com> Message-ID: Tobias Hunger wrote: > So could we please get a *documented* way that an IDE can *rely on to > be available* that provides basic information on a > project/configuration: > > * Source directory, build directory > * Files that belong to the project (sources, headers, custom cmake > modules, CMakeLists.txts, resources, ...) > * Files that belong to the build system (anything that needs watching > to re-generate the IDE-integration information at the right times) > * Targets that can be built > * Files that belong to each target > * Compiler flags > * Defines in effect > * Include paths used > * The compilers used to build those files Yes, that's the kind of thing my branch on github provides. That's why I worked on those things first. Did you look at my github branch already by the way? Thanks, Steve. From steveire at gmail.com Tue Jan 12 15:24:24 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 12 Jan 2016 21:24:24 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <56951624.1040302@kitware.com> Message-ID: Brad King wrote: >> Alexander goes back to the generator approach we discussed a year ago >> and explicitly says he won't work on that, so nothing will happen >> there. > > The generate-json-description approach remains a valid alternative. > Aleix's work on it got pretty far before Stephen proposed the daemon > alternative. In between I also made a generic-generated-JSON-file-based approach. > These problems are orthogonal, and your requirements certainly need > generation-time information regardless of how the build specification > itself is represented. Yes, this is the stuff that the protocol I put on github provides. > Therefore the discussion here should proceed > independent of where the alternative language thread goes. Yes. I count 3 orthogonal ways an IDE and cmake could 'interface': 1) Provide information about translation of sources into objects so that the IDE can understand those sources - eg includes and defines for c++ sources. 2) Provide semantic information about the CMake code, for example to introspect what is defined at what point in the file for debugging purposes, and for code completion purposes. 3) Provide a way for IDEs to *edit* the buildsystem. For example, if an IDE has an 'add class' dialog, or a 'extract class' refactoring action, they need to add a file to a target. The first two are what we have mostly discussed in previous threads that I linked in the OP. A generated JSON file in the buildsystem can provide (1), but can not provide the other interfaces. A well-designed declarative spec could make it easy for an IDE to do (3) but can not provide the other interfaces. A daemon can provide the first two in a high quality way and allows for more extensions in the future. As (3) is orthogonal, a daemon and a declarative spec for the sources covers all three. Even without the declarative spec, the daemon can tell the IDE exactly where to put the target_sources() command as an intermediate step (before the declarative spec is available), though that's 'ugly' so I didn't list it as something 'high quality' that the daemon could provide. > 2. CMake offers a daemon that IDEs can contact (e.g. via named pipes) > to ask for the information. The contract between CMake and IDEs is > a (to-be-designed) protocol (e.g. JSON snippets). Updating would > likely be handled internally by the daemon in response to changes > to the CMake input files between requests from the IDE. Right. If only some/deep/nested/CMakeLists.txt changes, and cmake knows that definitions do not escape via PARENT_SCOPE, and cmake knows that the targets defined in that file are not additionally modified elsewhere, it only has to re-evaluate the cmake code for that file and not for the entire buildsystem. > Stephen no longer has time to continue his work except to guide others. I can do development, but it would have to be as part of a collaborative effort and collaborative future maintenance. The latter part is the main reason I want to encourage fresh developers (and particularly IDE developers) into the cmake code to work on this, and to have some ownership on the code and design. > Given the above summaries my reaction is that the daemon approach is > more elegant and desirable in the long run. However, it will require > much more time and resources to implement. It is not clear how much > more, or if anyone has such time and resources to offer. Yes. I'm trying to generate interest in people who are capable of joining the effort, and interested in doing so. It is difficult :). > An intermediate solution could be to offer the daemon and protocol > to IDEs but to implement it internally on top of pre-generated JSON > files. That's even more effort, no? > The schema of the JSON files would remain a private contract > between "cmake" and "cmake-daemon". Then over time the implementation > of the daemon could be improved by computing things internally on > demand instead of updating and reading the JSON files, but the public- > facing protocol would not change. We just need to make sure that the > protocol is designed to allow such flexibility. OTOH this approach > requires designing both the daemon protocol and the JSON format. Yes. I don't understand the proposal. Why implement the protocol in terms of files generated by cmake, instead of implementing the protocol in terms of state in cmake (one less step)? > Note that the generated JSON approach is essentially what we've been > doing with the VS IDE since CMake started, just with a different format. Yes, but also without providing an interface for (2) and (3) above. > Many developers use the VS IDE to develop their CMake-built projects, > and they get IntelliSense for completion. It has worked well for years. > Perhaps the argument for the daemon approach puts too much focus on the > updating case while most developer time is simply spent editing existing > sources in their IDE. I don't understand this bit. Can you rephrase? Thanks, Steve. From steveire at gmail.com Tue Jan 12 15:29:26 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 12 Jan 2016 21:29:26 +0100 Subject: [cmake-developers] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <5694166D.90409@kitware.com> Message-ID: Brad King wrote: > The proposed daemon could help IDEs integrate with the CMake language > without re-implementing it, but we may not need such heavy infrastructure > for IDEs just to list targets and sources and allow users to edit them. Do you agree that that's an orthogonal use-case (add file to target) to what is being proposed (help me debug my cmake files)? If you agree that the declarative spec is orthogonal, then do you still have some other objection 'in principle' to the daemon approach? > I'm concerned that the memory usage of a daemon implementing the proposed > capabilities may be too large to be practical (at least without a major > redesign of certain structures that tend to duplicate substrings, or > some kind of out-of-core approach). If we reach a point where the memory consumption issue is the only blocker I can try to trap Milian in a room one of these days to help fix it. Thanks, Steve. From mantis at public.kitware.com Tue Jan 12 16:29:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Jan 2016 16:29:15 -0500 Subject: [cmake-developers] [CMake 0015913]: CMAKE_SYSTEM_NAME is not being set on cmake 3.3.2 Cygwin Message-ID: <11fe39370d839f15369e01f166443274@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15913 ====================================================================== Reported By: Gregory M. Baumgardner Assigned To: ====================================================================== Project: CMake Issue ID: 15913 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-12 16:29 EST Last Modified: 2016-01-12 16:29 EST ====================================================================== Summary: CMAKE_SYSTEM_NAME is not being set on cmake 3.3.2 Cygwin Description: I installed cmake 3.3.2 directly from the Cygwin distribution, but for some reason I cannot get the if(CYGWIN) to work properly. It is probably related to the fact that the the CMAKE_SYSTEM_NAME is not being set. I have confirmed this with a quick test, but have no idea what is wrong or why I cannot detect Cygwin. The --system-information shows that the CMAKE_SYSTEM_NAME=CYGWIN, but it is not being set the same when I run cmake against my CMakeLists.txt file. It would be nice to have this feature worked as advertised. Steps to Reproduce: Run "cmake ." using supplied CMakeLists.txt file. Output is: -- Hello World -- Cygwin is and CMAKE_COMPILER_IS_CYGWIN = and CMAKE_SYSTEM_NAME = I expected that it should read: -- Hello World -- Cygwin is 1 and CMAKE_COMPILER_IS_CYGWIN = 1 and CMAKE_SYSTEM_NAME = CYGWIN Additional Information: Avoid ctest truncation of output: CTEST_FULL_OUTPUT ======================================================== === MAIN VARIABLES ======================================================== CMAKE_STATIC_LIBRARY_PREFIX == "lib" CMAKE_STATIC_LIBRARY_SUFFIX == ".a" CMAKE_SHARED_LIBRARY_PREFIX == "cyg" CMAKE_SHARED_LIBRARY_SUFFIX == ".dll" CMAKE_SHARED_MODULE_PREFIX == "cyg" CMAKE_SHARED_MODULE_SUFFIX == ".dll" CMAKE_DL_LIBS == "dl" CMAKE_LIBRARY_PATH_FLAG == "-L" CMAKE_LINK_LIBRARY_FLAG == "-l" CMAKE_SKIP_RPATH == "NO" CMAKE_SYSTEM_INFO_FILE == "Platform/CYGWIN" CMAKE_SYSTEM_NAME == "CYGWIN" CMAKE_SYSTEM == "CYGWIN-2.3.1(0.291/5/3)" CMAKE_CXX_COMPILER == "/usr/bin/c++.exe" CMAKE_C_COMPILER == "/usr/bin/cc" CMAKE_COMPILER_IS_GNUCC == "1" CMAKE_COMPILER_IS_GNUCXX == "1" .... CMAKE_COMPILER_IS_CYGWIN "1" CYGWIN "1" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-12 16:29 Gregory M. BaumgardnerNew Issue 2016-01-12 16:29 Gregory M. BaumgardnerFile Added: CMakeLists.txt ====================================================================== From mantis at public.kitware.com Tue Jan 12 16:29:24 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Jan 2016 16:29:24 -0500 Subject: [cmake-developers] [CMake 0015914]: Update and subsequent steps of ExternalProject_Add are executed even when there is no change in the downloaded source Message-ID: <1f74a261e3a9bc9e1fe720f9f79ba554@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15914 ====================================================================== Reported By: Kim Topley Assigned To: ====================================================================== Project: CMake Issue ID: 15914 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-12 16:29 EST Last Modified: 2016-01-12 16:29 EST ====================================================================== Summary: Update and subsequent steps of ExternalProject_Add are executed even when there is no change in the downloaded source Description: I have several CMake files that download and build source from a Git repo or a file on SourceForge, using ExternalProject_Add. Everything works, except that the software is rebuilt every time I run make, even if nothing new was pulled from Git or the downloaded source file did not change. This means that builds that should take a couple of seconds take many minutes. Steps to Reproduce: I use a file that imports the following snippet: include(ExternalProject) set(JEMALLOC_PREFIX_DIR ${CMAKE_BINARY_DIR}/Jemalloc) set(JEMALLOC_SRC_DIR ${JEMALLOC_PREFIX_DIR}/src/Jemalloc) set(JEMALLOC_INSTALL_DIR ${JEMALLOC_PREFIX_DIR}/install) ExternalProject_Add(Jemalloc GIT_REPOSITORY https://github.com/jemalloc/jemalloc.git GIT_TAG master PREFIX ${JEMALLOC_PREFIX_DIR} CONFIGURE_COMMAND echo Configuring jemalloc && cd ${JEMALLOC_SRC_DIR} && ./autogen.sh && ./configure --prefix=${JEMALLOC_INSTALL_DIR} --with-jemalloc-prefix=je_ --enable-prof BUILD_COMMAND echo Building jemalloc && cd ${JEMALLOC_SRC_DIR} && make install_lib_static install_include INSTALL_COMMAND "" ) # Create libjemalloc and libjemalloc-pic targets to be used as # dependencies add_library(libjemalloc STATIC IMPORTED GLOBAL) add_library(libjemalloc-pic STATIC IMPORTED GLOBAL) set_target_properties(libjemalloc PROPERTIES "IMPORTED_LOCATION" "${JEMALLOC_INSTALL_DIR}/lib/libjemalloc.a") set_target_properties(libjemalloc-pic PROPERTIES "IMPORTED_LOCATION" "${JEMALLOC_INSTALL_DIR}/lib/libjemalloc-pic.a") # Make the targets depend on the external project download. add_dependencies(libjemalloc Jemalloc) add_dependencies(libjemalloc-pic Jemalloc) # Export the include directory path. set(JEMALLOC_INCLUDE_DIR ${JEMALLOC_INSTALL_DIR}/include) Additional Information: The issue seems to be that the -update target in the generated Makefile is always seen to be out of date. It looks like that's because it doesn't do a touch at the end, unlike all of the other similar targets. I added a touch to the generated file and it stopped rebuilding the source: Jemalloc/src/Jemalloc-stamp/Jemalloc-update: Jemalloc/src/Jemalloc-stamp/Jemalloc-download @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir=/Users/kim/clionprojects/Hacking2/XYZZY/CMakeFiles --progress-num=$(CMAKE_PROGRESS_5) "Performing update step for 'Jemalloc'" cd /Users/kim/clionprojects/Hacking2/XYZZY/Jemalloc/src/Jemalloc && /Applications/CMake.app/Contents/bin/cmake -P /Users/kim/clionprojects/Hacking2/XYZZY/Jemalloc/tmp/Jemalloc-gitupdate.cmake echo I ADDED THE NEXT LINE..... cd /Users/kim/clionprojects/Hacking2/XYZZY/Jemalloc/src && /Applications/CMake.app/Contents/bin/cmake -E touch /Users/kim/clionprojects/Hacking2/XYZZY/Jemalloc/src/Jemalloc-stamp/Jemalloc-update ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-12 16:29 Kim Topley New Issue ====================================================================== From neundorf at kde.org Tue Jan 12 16:30:24 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 12 Jan 2016 22:30:24 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: <56951624.1040302@kitware.com> References: <56923C33.6030506@gmail.com> <56951624.1040302@kitware.com> Message-ID: <7942115.EJOkiPqv8N@tuxedo.neundorf.net> On Tuesday, January 12, 2016 10:05:08 Brad King wrote: > On 01/12/2016 05:15 AM, Tobias Hunger wrote: > > I read Brad's reply as meaning that your cleanup work is a great > > benefit to cmake, but will probably not be available in the > > foreseeable future (if at all). > > Most of Stephen's work completed so far is already in CMake 3.4, and > a bit more is in 'master' and will be in 3.5. It has no public-facing > changes though so yes more work will be needed to get a solution IDEs > can actually use. > > > Alexander goes back to the generator approach we discussed a year ago > > and explicitly says he won't work on that, so nothing will happen > > there. > > The generate-json-description approach remains a valid alternative. > Aleix's work on it got pretty far before Stephen proposed the daemon > alternative. See more below. IIRC Alexander Neundorf raised concerns > only about how to activate the generation of the json description, and > has now proposed an approach to resolve those concerns. Yes, exactly. But I really don't have the time to bring my branch up to merge quality: tests, documentation, compatibility (?, some generator names will fall away), corner cases. But these things are actually not complicated code, It's just work. Alex From yves.frederix+cmake at gmail.com Tue Jan 12 16:34:18 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 12 Jan 2016 22:34:18 +0100 Subject: [cmake-developers] Allowing generator expressions in install DIRECTORY Message-ID: Hi, I am attaching a patch that adds support for generator expressions in the DIRECTORY arguments of install(DIRECTORY ...). It is my first contribution, so I don't really have experience with quality requirements, but I based the changes largely on other commits implementing similar functionality for other commands, so hopefully it is not be too bad for a first try. If additional changes are necessary, let me know and I'll update the patch. Regards, Yves -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-install-Allow-generator-expressions-in-DIRECTORY.patch Type: text/x-patch Size: 9157 bytes Desc: not available URL: From neundorf at kde.org Tue Jan 12 17:27:08 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 12 Jan 2016 23:27:08 +0100 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: <2265154.hI33OhW5RQ@agathebauer> References: <56923C33.6030506@gmail.com> <16894351.04HyfLIrgp@tuxedo.neundorf.net> <2265154.hI33OhW5RQ@agathebauer> Message-ID: <15457815.Lz3iSFVHXe@tuxedo.neundorf.net> On Tuesday, January 12, 2016 23:20:14 Milian Wolff wrote: > On Montag, 11. Januar 2016 23:22:23 CET Alexander Neundorf wrote: ... > > Stephens big approach will need some time until it is ready, while such a > > (relatively) simple thing can probably be done within one release cycle > > (but I don't have the time to do it). > > > > I don't know what the others here think about adding your json-approach or > > not. > > I don't think I'll have the required time to help here either, but I agree > with your reasoning: Your patch is the potentially quickest to get something > done. But it only fixes the usability issue of generators, it does not come > with a useable generator which we'll still need to write. I thought Aleix's patch was already quite good ? Alex From swel024 at gmail.com Wed Jan 13 01:38:18 2016 From: swel024 at gmail.com (Simon Wells) Date: Wed, 13 Jan 2016 19:38:18 +1300 Subject: [cmake-developers] fixup_bundle with @loader_path Message-ID: I currently have boost installed through brew of which kicad uses libboost_context-mt.dylib this library then depends on libboost_chrono-mt.dylib the otool -L for libboost_context-mt.dylib for chrono is @loader_path/libboost_chrono-mt.dylib After having numerous issues with trying to get this working as it kept saying that @loader_path/libboost_chrono-mt.dylib was not found, I was doing some testing with the help of Lewoco and found a few things BundleUtilities.cmake requests a list of prerequisites using get_prerequisites and theoretically this should return the full path that was found in gp_resolve_items (from get_prerequisites) however due to how get_prerequisites functions the full path is not being added to the prerequisites_var which is "returned". I believe this has to do with gp_append_unique(${prerequisites_var} "${item}") as that would add the @loader_path version of the path rather than the resolved path. And when its recursive, and so the full path is then used in a recursive call to get_prerequisites the function doesn't allow it to add itself to the list. unfortunately i don't understand enough about how the function actually works to know the best way to patch this but i assume it would be better if only resolved items were added to the prerequisite_vars as otherwise its possible they would not have enough information to be resolved later If i am missing something or have made a mistake somewhere please let me know thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tholag at gmail.com Wed Jan 13 02:32:26 2016 From: tholag at gmail.com (Thomas (QbProg)) Date: Wed, 13 Jan 2016 07:32:26 +0000 Subject: [cmake-developers] Visual Studio 2015 FastLink In-Reply-To: <5695544A.7030106@kitware.com> References: <5695544A.7030106@kitware.com> Message-ID: Thanks for the commit! I digged through the msbuild targets of visual c++ 14 and it seems that for the moment, generating full PDBs simply switches back the "GenerateDebugInformation" value to "Debug". I propose to wait until there is a documented switch or the behavior is more clear. This is what I found in Microsoft.CppCommon.targets: Debug Il giorno mar 12 gen 2016 alle ore 20:30 Brad King ha scritto: > On 01/11/2016 03:29 PM, Thomas wrote: > > https://cmake.org/Bug/view.php?id=15894 > > > > I'm writing to request support for the /Debug:FastLink flag which was > introduced in visual studio 2015 (update 1), and the option to generate > full PDB informations. > > > http://blogs.msdn.com/b/vcblog/archive/2015/10/16/debug-fastlink-for-vs2015-update-1.aspx > > Thanks. I've applied that change: > > VS: Map link `/debug:fastlink` flag to VS 2015 IDE property > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc5d6592 > > > About the "Generate Full PDB informations" > [snip] > > That option seems to doesn't have a (public) command line switch, > > instead it relies on an XML property. > > If there is no command line switch then how does the IDE behavior > change when the FullProgramDatabaseFile property is enabled? > > > What's the best way to set a TARGET or global property which would > > enable the switchless XML property in the generator? > > Existing target properties that influence VS project generation but > nothing else mostly have names starting in "VS_". If the target > property would have effects on other generators then we should use > a more generic name. Either way, please include associated updates > to the documentation. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.huet at gmail.com Wed Jan 13 04:34:20 2016 From: charles.huet at gmail.com (Charles Huet) Date: Wed, 13 Jan 2016 09:34:20 +0000 Subject: [cmake-developers] CMake alternative language In-Reply-To: <5694165B.5040803@kitware.com> References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: Hi, > * There is a lot of code out there in the current CMake language so I do not think it is realistic to drop it. I'm not proposing that this change. I am. (more below) > * Many projects build elaborate macro/function systems in the CMake language in order to end up with a declarative specification listing the actual source files, dependencies, and usage requirements. I'd like to offer an alternative to this. In my experience, most of the elaborate macros/functions come either from a misunderstanding of some of CMake's internals (scope, link debug/release libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no return value for functions). > I'd like to improve this by *optionally* moving part of the specification to a (stateless) declarative format that IDEs can load/edit/save directly Split the buildsystem in two different languages ? Would the declarative part be in a different file ? Also, the declarative part in my opinion must take advantage of the language. For instance, add a source file only for WIN32 systems should be easy in said declarative format. Using a custom language (based on JSON for instance) would mean to add conditionals, which comes back to making a custom language again. To come back to my first point, I understand completely that this would be a tremendous change, and the transition would be difficult to say the least. But I think it would be more than worth it in the long term. > The moment you make CMake scriptable in more than one language, you are forcing > every CMake user to learn that additional language because sooner or later he > will step into a third-party that is using that additional language. What I have in mind is to deprecate the current CMake language and replace it with another language. So there would be a transition period, but in the end there would only be one language again, and a better one. If CMake transitioned to python (or Lua, or whatever) newcomers to CMake would not need learn a new language (or at least learn one that has many resources, and can be used for other purposes). Old-timers would have to learn a new language (or maybe not, most programmers I know have played a bit with python to automate simple tasks), but this would be easier than learning CMake was, since there are established rules and a more consistent design to it. Of course I'm not saying this should happen overnight, nor am I saying this *must* happen, but I think discussing it can only be beneficial. I've seen lots of people wonder how to make their CMake scripts more efficient, and currently this is a very difficult thing to do, since there is no profiling possible. And who can say they never spent way too much time trying to understand why a variable was not correctly initialized ? When the configure step takes about 30 seconds, and all you can do is use MESSAGE() to find what happens, this is no walk in the park. A real debugger would do a world of good to CMake. I have seen some hardly understandable CMake code, and only thanks to the git history was I able to understand that the person who wrote the script completely misunderstood the CMake language. >As discussed above if some kind of callback or user-coded function needs to be included for advanced usage of the declarative spec then we would need a language for it. The current CMake language is not well suited to that use case (e.g. no expressions or return values), so an existing alternative language should be chosen. >CMake's current "generator expressions" fill this role somewhat now and are essentially a sub-language. As with the main language they grew out of something not intended to serve their current full role. They could be superseded by a common alternative generate-time language too. These points are part of the reason I think a new language should be used, if it can cover all of these issues. I'd rather not see a new CMake declarative language that might itself grow out and become something difficult to grasp. Something like generator expressions could be expressed in a language such as python or lua, by using objects that get resolved at generate time (or functions, or whatever). Cheers Le lun. 11 janv. 2016 ? 21:53, Brad King a ?crit : > Hi Folks, > > I'm replying directly to my previous post in this thread in order to > consolidate > responses to related discussion raised in others' responses to it: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389 > > General comments: > > * There is a lot of code out there in the current CMake language so I do > not > think it is realistic to drop it. I'm not proposing that this change. > > * CMake's procedural/imperative design is good as the main entry point to > configuration of a project. It can do system introspection, file > generation, > etc. I'm not proposing that this change. > > * Many projects build elaborate macro/function systems in the CMake > language > in order to end up with a declarative specification listing the actual > source files, dependencies, and usage requirements. I'd like to offer > an alternative to this. > > * Integration with IDEs is currently based on one-way generation (VS IDE > projects, Xcode projects, CodeBlocks, etc.). Editing the project build > specification requires editing CMake code directly because IDEs cannot > easily pierce CMake's procedural/imperative specification: > > https://cmake.org/pipermail/cmake-developers/2016-January/027386.html > > I'd like to improve this by *optionally* moving part of the specification > to a (stateless) declarative format that IDEs can load/edit/save > directly. > > Specific responses follow. > > > -------------------------------------------------------------------------------- > > On 01/11/2016 12:24 PM, Charles Huet wrote: > > I think these goals aim towards a faster configure, and the ability to > > only partly reconfigure, right? > > Yes. > > > I know I am largely biased by the project I work on, but I do not see how > > parallel evaluation woud be a huge benefit. > [snip] > > And how would that work with CMakeLists that affect their parent scope ? > > Evaluation of the imperative language is currently serial for reasons like > this, which is why I said it would take semantic changes to enable parallel > evaluation. This is not the main point of my proposal so I'd rather not > get bogged down in the details of this part of the discussion. > > >> Ideally most of the specification (sources, libraries, executables, > etc.) > >> should be in a pure format that can be evaluated without side effects > (e.g. > >> declarative or functional). > > > > I'm not sure I understand how this could be done without losing a lot of > > what CMake offers, such as copying or generating files. > > I'm not proposing dropping the current imperative capabilities. > > > I'm leaning towards a declarative approach as it is quite easy to learn > > (since you declare objects, and every C++ programmer I know is familiar > > with those) > > Yes. > > > It seems you are leaning towards pure functional, but I do not see how > > this would work with the current way CMake handles variables and scope, > > could you elaborate ? > > While declarative may get us most of the way, advanced users may wish to > hook in to generation-time evaluation. A clean way to do that would be > to specify a function within the declared values. It would not have to > be in a functional language as long as it has no access to anything other > than the inputs passed to it during evaluation. > > I mentioned "functional" mostly as an example of a specification whose > evaluation is free of side effects. > > > To clarify, only the following lines should be considered when looking > at the POC. > >> myProject=cmake.Project("MyTestProject") > >> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] > > Yes, this is the kind of stuff that can be in a declarative format. > > > It seems you have in mind to write a new CMake language. > > No, at most a new specification format that can be used for IDE > integration. > If some kind of user-coded function were included in the specification it > should certainly be in an existing language. > > > Maybe I should take my POC further > > I think implementation even of a POC is premature at this point. We > should explore the design space further. > > > CMake's own buildsystem seems like a good testing ground for this, but > > it is a little too big for a first go, do you know of a small CMake-based > > project that would be better suited ? > > Maybe you could find something in our test suite. > > > I don't have a clear view of what a pure functional CMake would look > like, > > but if you give me some mock code, I could give a try at bringing some > pure > > functional language up to the level of my POC and we could use it as a > more > > concrete discussion support. > > I have no prototype (nor substantial time to spend on design myself) but > I've imagined a declarative format in a well-known syntax (e.g. JSON or one > of the lightweight human-friendly choices). If generate-time functionality > is needed then code snippets in e.g. Lua could be included. > > > -------------------------------------------------------------------------------- > > Petr Kmoch wrote: > > I'd like to voice my opinion as a somewhat advanced CMake user here. > > Thanks for joining the discussion with this point of view. > > > For me, one of the strongest points of CMake is the fact that its project > > specification is procedural rather than declarative. > > Good. We will not be dropping imperative capabilities. > > > end result of our framework is that the CMakeLists consist mostly of > > declarative commands from our framework > > Yes, many projects have such frameworks. Most of them result in a > declarative spec inside calls to their macros/functions. I'd like to > formalize such specs in a re-usable way. > > > If I understand Brad's suggestion correctly, it would amount to a > > (possibly empty) procedural step being used to generate a declarative > > description of the buildsystem. > > Not quite. Yes, the procedural/imperative part would still be the entry > point as it is now. However, the declarative part would also be an > input, not an output. The procedural part's role would be to compute > *parameters* to be used for the evaluation of the declarative spec. > > For example, imagine the declarative spec somehow encodes that source > file "foo.c" is optional based on some condition "FOO". The value of > that condition could be computed by the procedural part of the process > based on system introspection, command-line options, etc., and then > provided to CMake for use in the final evaluation. > > > -------------------------------------------------------------------------------- > > On 01/11/2016 01:21 PM, Pau Garcia i Quiles wrote: > > The moment you make CMake scriptable in more than one language, you are > forcing > > every CMake user to learn that additional language because sooner or > later he > > will step into a third-party that is using that additional language. > > I don't think the main "entry point" language should be selectable. > > As discussed above if some kind of callback or user-coded function needs to > be included for advanced usage of the declarative spec then we would need > a language for it. The current CMake language is not well suited to that > use case (e.g. no expressions or return values), so an existing alternative > language should be chosen. > > CMake's current "generator expressions" fill this role somewhat now and are > essentially a sub-language. As with the main language they grew out of > something not intended to serve their current full role. They could be > superseded by a common alternative generate-time language too. > > > Also, declarative? Why? > > See above. > > > There are already a few declarative build systems > > Yes, and perhaps we can learn from their formats for the proposed > declarative > part. > > > qbs, one of the reasons for its existence was CMake was not declarative > > IIUC that is exactly because of the fact that an imperative spec cannot > be pierced easily for editing in IDEs. > > > -------------------------------------------------------------------------------- > > Thanks all for the discussion so far! > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannsuisini at gmail.com Wed Jan 13 04:59:39 2016 From: yannsuisini at gmail.com (yann suisini) Date: Wed, 13 Jan 2016 10:59:39 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: Hi, I'm a new user of CMake, but I just want to express my newcomer point of view. Honestly , I can feel the power of CMAKE, but it's a real pain to learn ... I'm using CMAKE for an embedded platform with a non GNU compiler , ant at the end the CMAKE description is longer than the one I built directly in Ninja. I had to write a python script to parse my eclipse project xml to create a list of sources files usable by CMAKE. The first thing I thought was: why this is not a part of cmake ? And the second thing was : why not using the scripting power of an existing language like Python(or other one) and add CMAKE as a framework / library ? Probably a dumb question ! :) Yann 2016-01-13 10:34 GMT+01:00 Charles Huet : > Hi, > > > * There is a lot of code out there in the current CMake language so I do > not > think it is realistic to drop it. I'm not proposing that this change. > > I am. (more below) > > > * Many projects build elaborate macro/function systems in the CMake > language > in order to end up with a declarative specification listing the actual > source files, dependencies, and usage requirements. I'd like to offer > an alternative to this. > > In my experience, most of the elaborate macros/functions come either from > a misunderstanding of some of CMake's internals (scope, link debug/release > libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no > return value for functions). > > > I'd like to improve this by *optionally* moving part of the > specification > to a (stateless) declarative format that IDEs can load/edit/save directly > > Split the buildsystem in two different languages ? Would the declarative > part be in a different file ? > Also, the declarative part in my opinion must take advantage of the > language. > For instance, add a source file only for WIN32 systems should be easy in > said declarative format. > Using a custom language (based on JSON for instance) would mean to add > conditionals, which comes back to making a custom language again. > > > To come back to my first point, I understand completely that this would be > a tremendous change, and the transition would be difficult to say the > least. But I think it would be more than worth it in the long term. > > > The moment you make CMake scriptable in more than one language, you are > forcing > > every CMake user to learn that additional language because sooner or > later he > > will step into a third-party that is using that additional language. > > What I have in mind is to deprecate the current CMake language and replace > it with another language. So there would be a transition period, but in the > end there would only be one language again, and a better one. > > If CMake transitioned to python (or Lua, or whatever) newcomers to CMake > would not need learn a new language (or at least learn one that has many > resources, and can be used for other purposes). > Old-timers would have to learn a new language (or maybe not, most > programmers I know have played a bit with python to automate simple tasks), > but this would be easier than learning CMake was, since there are > established rules and a more consistent design to it. > > Of course I'm not saying this should happen overnight, nor am I saying > this *must* happen, but I think discussing it can only be beneficial. > > I've seen lots of people wonder how to make their CMake scripts more > efficient, and currently this is a very difficult thing to do, since there > is no profiling possible. > And who can say they never spent way too much time trying to understand > why a variable was not correctly initialized ? When the configure step > takes about 30 seconds, and all you can do is use MESSAGE() to find what > happens, this is no walk in the park. A real debugger would do a world of > good to CMake. > I have seen some hardly understandable CMake code, and only thanks to the > git history was I able to understand that the person who wrote the script > completely misunderstood the CMake language. > > >As discussed above if some kind of callback or user-coded function needs > to > be included for advanced usage of the declarative spec then we would need > a language for it. The current CMake language is not well suited to that > use case (e.g. no expressions or return values), so an existing alternative > language should be chosen. > > >CMake's current "generator expressions" fill this role somewhat now and > are > essentially a sub-language. As with the main language they grew out of > something not intended to serve their current full role. They could be > superseded by a common alternative generate-time language too. > > These points are part of the reason I think a new language should be used, > if it can cover all of these issues. I'd rather not see a new CMake > declarative language that might itself grow out and become something > difficult to grasp. > Something like generator expressions could be expressed in a language such > as python or lua, by using objects that get resolved at generate time (or > functions, or whatever). > > > Cheers > > Le lun. 11 janv. 2016 ? 21:53, Brad King a ?crit : > >> Hi Folks, >> >> I'm replying directly to my previous post in this thread in order to >> consolidate >> responses to related discussion raised in others' responses to it: >> >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383 >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386 >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389 >> >> General comments: >> >> * There is a lot of code out there in the current CMake language so I do >> not >> think it is realistic to drop it. I'm not proposing that this change. >> >> * CMake's procedural/imperative design is good as the main entry point to >> configuration of a project. It can do system introspection, file >> generation, >> etc. I'm not proposing that this change. >> >> * Many projects build elaborate macro/function systems in the CMake >> language >> in order to end up with a declarative specification listing the actual >> source files, dependencies, and usage requirements. I'd like to offer >> an alternative to this. >> >> * Integration with IDEs is currently based on one-way generation (VS IDE >> projects, Xcode projects, CodeBlocks, etc.). Editing the project build >> specification requires editing CMake code directly because IDEs cannot >> easily pierce CMake's procedural/imperative specification: >> >> https://cmake.org/pipermail/cmake-developers/2016-January/027386.html >> >> I'd like to improve this by *optionally* moving part of the >> specification >> to a (stateless) declarative format that IDEs can load/edit/save >> directly. >> >> Specific responses follow. >> >> >> -------------------------------------------------------------------------------- >> >> On 01/11/2016 12:24 PM, Charles Huet wrote: >> > I think these goals aim towards a faster configure, and the ability to >> > only partly reconfigure, right? >> >> Yes. >> >> > I know I am largely biased by the project I work on, but I do not see >> how >> > parallel evaluation woud be a huge benefit. >> [snip] >> > And how would that work with CMakeLists that affect their parent scope ? >> >> Evaluation of the imperative language is currently serial for reasons like >> this, which is why I said it would take semantic changes to enable >> parallel >> evaluation. This is not the main point of my proposal so I'd rather not >> get bogged down in the details of this part of the discussion. >> >> >> Ideally most of the specification (sources, libraries, executables, >> etc.) >> >> should be in a pure format that can be evaluated without side effects >> (e.g. >> >> declarative or functional). >> > >> > I'm not sure I understand how this could be done without losing a lot of >> > what CMake offers, such as copying or generating files. >> >> I'm not proposing dropping the current imperative capabilities. >> >> > I'm leaning towards a declarative approach as it is quite easy to learn >> > (since you declare objects, and every C++ programmer I know is familiar >> > with those) >> >> Yes. >> >> > It seems you are leaning towards pure functional, but I do not see how >> > this would work with the current way CMake handles variables and scope, >> > could you elaborate ? >> >> While declarative may get us most of the way, advanced users may wish to >> hook in to generation-time evaluation. A clean way to do that would be >> to specify a function within the declared values. It would not have to >> be in a functional language as long as it has no access to anything other >> than the inputs passed to it during evaluation. >> >> I mentioned "functional" mostly as an example of a specification whose >> evaluation is free of side effects. >> >> > To clarify, only the following lines should be considered when looking >> at the POC. >> >> myProject=cmake.Project("MyTestProject") >> >> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] >> >> Yes, this is the kind of stuff that can be in a declarative format. >> >> > It seems you have in mind to write a new CMake language. >> >> No, at most a new specification format that can be used for IDE >> integration. >> If some kind of user-coded function were included in the specification it >> should certainly be in an existing language. >> >> > Maybe I should take my POC further >> >> I think implementation even of a POC is premature at this point. We >> should explore the design space further. >> >> > CMake's own buildsystem seems like a good testing ground for this, but >> > it is a little too big for a first go, do you know of a small >> CMake-based >> > project that would be better suited ? >> >> Maybe you could find something in our test suite. >> >> > I don't have a clear view of what a pure functional CMake would look >> like, >> > but if you give me some mock code, I could give a try at bringing some >> pure >> > functional language up to the level of my POC and we could use it as a >> more >> > concrete discussion support. >> >> I have no prototype (nor substantial time to spend on design myself) but >> I've imagined a declarative format in a well-known syntax (e.g. JSON or >> one >> of the lightweight human-friendly choices). If generate-time >> functionality >> is needed then code snippets in e.g. Lua could be included. >> >> >> -------------------------------------------------------------------------------- >> >> Petr Kmoch wrote: >> > I'd like to voice my opinion as a somewhat advanced CMake user here. >> >> Thanks for joining the discussion with this point of view. >> >> > For me, one of the strongest points of CMake is the fact that its >> project >> > specification is procedural rather than declarative. >> >> Good. We will not be dropping imperative capabilities. >> >> > end result of our framework is that the CMakeLists consist mostly of >> > declarative commands from our framework >> >> Yes, many projects have such frameworks. Most of them result in a >> declarative spec inside calls to their macros/functions. I'd like to >> formalize such specs in a re-usable way. >> >> > If I understand Brad's suggestion correctly, it would amount to a >> > (possibly empty) procedural step being used to generate a declarative >> > description of the buildsystem. >> >> Not quite. Yes, the procedural/imperative part would still be the entry >> point as it is now. However, the declarative part would also be an >> input, not an output. The procedural part's role would be to compute >> *parameters* to be used for the evaluation of the declarative spec. >> >> For example, imagine the declarative spec somehow encodes that source >> file "foo.c" is optional based on some condition "FOO". The value of >> that condition could be computed by the procedural part of the process >> based on system introspection, command-line options, etc., and then >> provided to CMake for use in the final evaluation. >> >> >> -------------------------------------------------------------------------------- >> >> On 01/11/2016 01:21 PM, Pau Garcia i Quiles wrote: >> > The moment you make CMake scriptable in more than one language, you are >> forcing >> > every CMake user to learn that additional language because sooner or >> later he >> > will step into a third-party that is using that additional language. >> >> I don't think the main "entry point" language should be selectable. >> >> As discussed above if some kind of callback or user-coded function needs >> to >> be included for advanced usage of the declarative spec then we would need >> a language for it. The current CMake language is not well suited to that >> use case (e.g. no expressions or return values), so an existing >> alternative >> language should be chosen. >> >> CMake's current "generator expressions" fill this role somewhat now and >> are >> essentially a sub-language. As with the main language they grew out of >> something not intended to serve their current full role. They could be >> superseded by a common alternative generate-time language too. >> >> > Also, declarative? Why? >> >> See above. >> >> > There are already a few declarative build systems >> >> Yes, and perhaps we can learn from their formats for the proposed >> declarative >> part. >> >> > qbs, one of the reasons for its existence was CMake was not declarative >> >> IIUC that is exactly because of the fact that an imperative spec cannot >> be pierced easily for editing in IDEs. >> >> >> -------------------------------------------------------------------------------- >> >> Thanks all for the discussion so far! >> >> -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 >> > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Wed Jan 13 05:18:29 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 13 Jan 2016 11:18:29 +0100 Subject: [cmake-developers] cmake daemon mode protocol Message-ID: Hi Stephen, I have successfully build and run your cmake server mode changes and the python client script does work as advertised. I do have a couple of remarks about it. This is more intended as a starting point for discussion as a real proposal. Would something along these lines be possible: * Start daemon-mode without any additional parameters * Daemon responds with " { "type": "handShake", "version": "3.5.x", "supportedProtocols": "3.5" } * Client Handshake: { "type": "handshake", "requestProtocolVersion": "3.5" } * Daemon: { "type:"handshake", "protocolVersion": "3.5" } At this point the normal operation should be possible. * Client: { "type": "setProjectInformation", "sourceDirectory": "/some/path", "cookie": "1" } Being able to set the source directory is important so that a fresh checkout can be configured. There is no build directory available at that time... * Daemon should do progress handling while reading the CMakeLists.txt or whatever it does: { "type": "progress", "state": "busy", "task": "someId", "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" } * Daemon sends occasional: { "type": "progress", "task": "someId", progressTotal: 25, progressCurrent: 12, "cookie": "1" } * Daemon sends (probably optional...): { "type": "progress", "task": "someId", "state": "done", "cookie": "1" } * Finally Daemon responds sends data as that is available now. { "type": "projectInformation", "sourceDirectory": "/some/path", "buildDirectory": "", "projectName": "SomeProject", "cookie": "1" } * Client: { "type": "setProjectInformation", "buildDirectory": "/some/other/path", "cookie": "2" } * Daemon does progress indication as above... * Daemon responds with project info: { "type": "progressInformation", "sourceDirectory": "/some/path", "buildDirectory": "/some/other/path", "projectName": "SomeProject", "cookie": "2" } We might also want a "ping"/"pong" to detect if the daemon is still responding. That would require the daemon to be able to handle multiple requests to be in flight... not sure that this is worth it. But if we can not do that, then we need to provide constant progress information, which is also not great:-) Not sure about the need for cookies (text set by the client and repeated by the server in all its replies to that request). I do think having them makes sense, even when only one request can be active at any time: They make it so much easier to sanity-check communication. Consistently having a "type" in all messages going back and forth is probably a good idea for the same reason as having cookies. A final, remark unrelated to the protocol: Ideally the daemon should delay writing into (and even creating!) the build directory for as long as possible (or till instructed to actually persist the configuration). We do have many users that use Qt Creator to browse foreign code and those tend to get upset when we write stuff to disk. Best Regards, Tobias From mkylmamaa at reforgedstudios.com Wed Jan 13 06:13:40 2016 From: mkylmamaa at reforgedstudios.com (=?UTF-8?Q?Marko_Kylm=C3=A4maa?=) Date: Wed, 13 Jan 2016 03:13:40 -0800 Subject: [cmake-developers] [PATCH] Proposed fix for bug 15183 Message-ID: Hello, I would like to propose the following fix for bug 15183 ( https://cmake.org/Bug/view.php?id=15183) For some reason the XcodeGenerator seemed to be setting the INSTALL_PATH variable regardless of if it was initialized or not (which is done only for shared libraries). This seems almost certainly undesirable so I've moved the code inside the shared library check. The fix is based on v3.4.1 tag. --- Source/cmGlobalXCodeGenerator.cxx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx index 33babec..089bb47 100644 --- a/Source/cmGlobalXCodeGenerator.cxx +++ b/Source/cmGlobalXCodeGenerator.cxx @@ -2329,10 +2329,10 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target, this->CreateString(format)); } - // Create the INSTALL_PATH attribute. - std::string install_name_dir; if(target.GetType() == cmTarget::SHARED_LIBRARY) { + // Create the INSTALL_PATH attribute. + std::string install_name_dir; // Get the install_name directory for the build tree. install_name_dir = gtgt->GetInstallNameDirForBuildTree(configName); // Xcode doesn't create the correct install_name in some cases. @@ -2356,9 +2356,9 @@ void cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target, extraLinkOptions += " -install_name "; extraLinkOptions += XCodeEscapePath(install_name.c_str()); } + buildSettings->AddAttribute("INSTALL_PATH", + this->CreateString(install_name_dir.c_str())); } - buildSettings->AddAttribute("INSTALL_PATH", - this->CreateString(install_name_dir.c_str())); // Create the LD_RUNPATH_SEARCH_PATHS cmComputeLinkInformation* pcli = gtgt->GetLinkInformation(configName); -- 2.5.4 (Apple Git-61) *Marko KylmamaaCTO* *Reforged Studios* *Cell:* +1-949-872-9650 *Skype:* mkylmamaa -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Wed Jan 13 07:00:39 2016 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 13 Jan 2016 04:00:39 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <569556D8.80308@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> Message-ID: On 1/12/16, Brad King wrote: > On 01/08/2016 06:15 PM, Eric Wing wrote: >> simple 'swiftc' integration going for ADD_EXECUTABLE, as described in >> the original post. > > Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake > to get rid of the up-front error. See "Modules/CMakeAddNewLanguage.txt" > (many of the steps are already done). > > Edit Modules/CMakeSwiftInformation.cmake and add settings for variables > like CMAKE_Swift_COMPILE_OBJECT and CMAKE_Swift_LINK_EXECUTABLE. See > the CMake{C,CXX,Fortran}Information.cmake modules for examples. The > available placeholders are in cmLocalGenerator::ExpandRuleVariable. > > If all the compile/link steps used for C and C++ map well to switfc > then it should be fairly straightforward. If other steps are needed > or the steps have wildly different semantics then more in-depth changes > to the actual generators may be needed. > > -Brad > So I got the trivial base case working with swiftc (no library dependencies, Mac for now but will shift to Linux eventually): add_exectuable(MyTarget main.swift) Yay. So next I wanted to add more files to the mix. And now I have some problems. Problem 1: Intermixing C and Swift add_exectuable(MyTarget main.swift some_c.c) Note: I presume C++ (and Obj-C) could also be in the mix: add_exectuable(MyTarget main.swift some_c.c some_cpp.cpp some_objc.m) It looks like the link phase is invoking cc on my system (the C linker rules?) instead of the Swift linker commands. If my hunch is correct, how do I tell CMake to ?promote? Swift as the correct tool? (Perhaps there is a similar existing mechanism already is handling intermixing C/C++ or C/Obj-C?) Additional note: I am a little surprised to see cc instead of ld (or swiftc). Now I may be able to use cc or ld, but I need to figure out how to adapt and add some additional flags. So it could be that I could work around this problem. (Kind of working solution at the bottom.) Problem 2: Multiple Swift files in the target add_exectuable(MyTarget main.swift OtherSwift.swift) With two or more files, I was hoping to do a single one-shot call: swiftc -c OtherSwift.swift main.swift -module-name MyTarget But it looks like CMake invokes each file separately. The problem that creates in the above case is that if main.swift uses stuff from the other file, it can no longer compile because it is unable to find the code in OtherSwift because they are treated as separate unconnected modules. I haven?t figured a way yet around this using swiftc. However, I can switch to the tool ?swift?, but it looks like Swift has a similar constraint which I will discuss shortly. But before I move on to that, is there a way to get CMake to invoke all the Swift files in the target together? (It would need to exclude any non-Swift files in the list.) I think there may be trade-offs here. On one hand, file-by-file might get us incremental compilation. But there is a flag called -whole-module-optimization which suggests treating them as a batch could allow better code generation. Now for the 'swift' tool: So the swift tool can go file-by-file, but the additional constraint is that all the other Swift files in the target must be listed too. To distinguish which file is actually being processed, you must use the -primary-file . I think this is so Swift can figure out all the cross-file dependencies since there are no header files in Swift. Here is an example of compiling my two files: # Compile main.swift to main.o swift -frontend -c -primary-file /Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift /Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift -emit-module -module-name MyTarget -o CMakeFiles/MyApp.dir/main.o -emit-module-path CMakeFiles/MyApp.dir/main~partial.swiftmodule # Compile OtherSwift.swift to OtherSwift.o swift -frontend -c -primary-file /Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift /Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift -emit-module -module-name MyTarget -o CMakeFiles/MyApp.dir/OtherSwift.o -emit-module-path CMakeFiles/MyApp.dir/OtherSwift~partial.swiftmodule Other things to notice: - I am using the CMake Target Name for the -module-name - There is a basename~partial.swiftmodule being generated. I'm not completely sure why this is needed, but I see it in the Xcode build lines and other examples on the web. Finally, the link line can look like this: (Xcode invokes clang instead of cc, but they map to the same thing on Mac) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift_static/macosx -Xlinker -force_load_swift_libs -lswiftRuntime -lc++ -framework Foundation CMakeFiles/MyApp.dir/OtherSwift.o CMakeFiles/MyApp.dir/main.o -o MyApp So in the CMake rules, for CMAKE_Swift_COMPILE_OBJECT, I think I need something kind of like: set(CMAKE_Swift_COMPILE_OBJECT " -frontend -c -primary-file -emit-module -module-name -o -emit-module-path -c ~partial.swiftmodule" ) Additional notes: - SOURCES doesn't actually exist in CMake, but I saw something called OBJECTS which makes me think they are a similar concept. - Also, for the second , I need to remove the one I'm using from my -primary-file. And there shouldn't be any non-Swift files in the list (no C/C++/Obj-C). - I actually need the basename of for the ~partial.swiftmodule stuff. - I'm not sure if I'm responsible for the intermediate products directories. Do I need to explicitly concat the paths to any of these things. - I haven't added the bridging header flag/value yet. I need some expected variable that holds it. Can you give me some suggestions on what to look at next? Thanks, Eric From charles.huet at gmail.com Wed Jan 13 08:14:22 2016 From: charles.huet at gmail.com (Charles Huet) Date: Wed, 13 Jan 2016 13:14:22 +0000 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: I don't think this is a dumb question, actually this is part of the problem I think would be resolved whit a new language. The barrier of entry to using CMake is too high in my opinion, and I think using an existing language would lower it *a lot*. Thanks for sharing :) Le mer. 13 janv. 2016 ? 10:59, yann suisini a ?crit : > Hi, > > I'm a new user of CMake, but I just want to express my newcomer point of > view. > Honestly , I can feel the power of CMAKE, but it's a real pain to learn ... > I'm using CMAKE for an embedded platform with a non GNU compiler , ant at > the end the CMAKE description is longer than the one I built directly in > Ninja. > I had to write a python script to parse my eclipse project xml to create a > list of sources files usable by CMAKE. > The first thing I thought was: why this is not a part of cmake ? And the > second thing was : why not using the scripting power of an existing > language like Python(or other one) > and add CMAKE as a framework / library ? > Probably a dumb question ! :) > > Yann > > 2016-01-13 10:34 GMT+01:00 Charles Huet : > >> Hi, >> >> > * There is a lot of code out there in the current CMake language so I >> do not >> think it is realistic to drop it. I'm not proposing that this change. >> >> I am. (more below) >> >> > * Many projects build elaborate macro/function systems in the CMake >> language >> in order to end up with a declarative specification listing the actual >> source files, dependencies, and usage requirements. I'd like to offer >> an alternative to this. >> >> In my experience, most of the elaborate macros/functions come either from >> a misunderstanding of some of CMake's internals (scope, link debug/release >> libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no >> return value for functions). >> >> > I'd like to improve this by *optionally* moving part of the >> specification >> to a (stateless) declarative format that IDEs can load/edit/save >> directly >> >> Split the buildsystem in two different languages ? Would the declarative >> part be in a different file ? >> Also, the declarative part in my opinion must take advantage of the >> language. >> For instance, add a source file only for WIN32 systems should be easy in >> said declarative format. >> Using a custom language (based on JSON for instance) would mean to add >> conditionals, which comes back to making a custom language again. >> >> >> To come back to my first point, I understand completely that this would >> be a tremendous change, and the transition would be difficult to say the >> least. But I think it would be more than worth it in the long term. >> >> > The moment you make CMake scriptable in more than one language, you are >> forcing >> > every CMake user to learn that additional language because sooner or >> later he >> > will step into a third-party that is using that additional language. >> >> What I have in mind is to deprecate the current CMake language and >> replace it with another language. So there would be a transition period, >> but in the end there would only be one language again, and a better one. >> >> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake >> would not need learn a new language (or at least learn one that has many >> resources, and can be used for other purposes). >> Old-timers would have to learn a new language (or maybe not, most >> programmers I know have played a bit with python to automate simple tasks), >> but this would be easier than learning CMake was, since there are >> established rules and a more consistent design to it. >> >> Of course I'm not saying this should happen overnight, nor am I saying >> this *must* happen, but I think discussing it can only be beneficial. >> >> I've seen lots of people wonder how to make their CMake scripts more >> efficient, and currently this is a very difficult thing to do, since there >> is no profiling possible. >> And who can say they never spent way too much time trying to understand >> why a variable was not correctly initialized ? When the configure step >> takes about 30 seconds, and all you can do is use MESSAGE() to find what >> happens, this is no walk in the park. A real debugger would do a world of >> good to CMake. >> I have seen some hardly understandable CMake code, and only thanks to the >> git history was I able to understand that the person who wrote the script >> completely misunderstood the CMake language. >> >> >As discussed above if some kind of callback or user-coded function needs >> to >> be included for advanced usage of the declarative spec then we would need >> a language for it. The current CMake language is not well suited to that >> use case (e.g. no expressions or return values), so an existing >> alternative >> language should be chosen. >> >> >CMake's current "generator expressions" fill this role somewhat now and >> are >> essentially a sub-language. As with the main language they grew out of >> something not intended to serve their current full role. They could be >> superseded by a common alternative generate-time language too. >> >> These points are part of the reason I think a new language should be >> used, if it can cover all of these issues. I'd rather not see a new CMake >> declarative language that might itself grow out and become something >> difficult to grasp. >> Something like generator expressions could be expressed in a language >> such as python or lua, by using objects that get resolved at generate time >> (or functions, or whatever). >> >> >> Cheers >> >> Le lun. 11 janv. 2016 ? 21:53, Brad King a >> ?crit : >> >>> Hi Folks, >>> >>> I'm replying directly to my previous post in this thread in order to >>> consolidate >>> responses to related discussion raised in others' responses to it: >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383 >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386 >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389 >>> >>> General comments: >>> >>> * There is a lot of code out there in the current CMake language so I do >>> not >>> think it is realistic to drop it. I'm not proposing that this change. >>> >>> * CMake's procedural/imperative design is good as the main entry point to >>> configuration of a project. It can do system introspection, file >>> generation, >>> etc. I'm not proposing that this change. >>> >>> * Many projects build elaborate macro/function systems in the CMake >>> language >>> in order to end up with a declarative specification listing the actual >>> source files, dependencies, and usage requirements. I'd like to offer >>> an alternative to this. >>> >>> * Integration with IDEs is currently based on one-way generation (VS IDE >>> projects, Xcode projects, CodeBlocks, etc.). Editing the project build >>> specification requires editing CMake code directly because IDEs cannot >>> easily pierce CMake's procedural/imperative specification: >>> >>> >>> https://cmake.org/pipermail/cmake-developers/2016-January/027386.html >>> >>> I'd like to improve this by *optionally* moving part of the >>> specification >>> to a (stateless) declarative format that IDEs can load/edit/save >>> directly. >>> >>> Specific responses follow. >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> On 01/11/2016 12:24 PM, Charles Huet wrote: >>> > I think these goals aim towards a faster configure, and the ability to >>> > only partly reconfigure, right? >>> >>> Yes. >>> >>> > I know I am largely biased by the project I work on, but I do not see >>> how >>> > parallel evaluation woud be a huge benefit. >>> [snip] >>> > And how would that work with CMakeLists that affect their parent scope >>> ? >>> >>> Evaluation of the imperative language is currently serial for reasons >>> like >>> this, which is why I said it would take semantic changes to enable >>> parallel >>> evaluation. This is not the main point of my proposal so I'd rather not >>> get bogged down in the details of this part of the discussion. >>> >>> >> Ideally most of the specification (sources, libraries, executables, >>> etc.) >>> >> should be in a pure format that can be evaluated without side effects >>> (e.g. >>> >> declarative or functional). >>> > >>> > I'm not sure I understand how this could be done without losing a lot >>> of >>> > what CMake offers, such as copying or generating files. >>> >>> I'm not proposing dropping the current imperative capabilities. >>> >>> > I'm leaning towards a declarative approach as it is quite easy to learn >>> > (since you declare objects, and every C++ programmer I know is familiar >>> > with those) >>> >>> Yes. >>> >>> > It seems you are leaning towards pure functional, but I do not see how >>> > this would work with the current way CMake handles variables and scope, >>> > could you elaborate ? >>> >>> While declarative may get us most of the way, advanced users may wish to >>> hook in to generation-time evaluation. A clean way to do that would be >>> to specify a function within the declared values. It would not have to >>> be in a functional language as long as it has no access to anything other >>> than the inputs passed to it during evaluation. >>> >>> I mentioned "functional" mostly as an example of a specification whose >>> evaluation is free of side effects. >>> >>> > To clarify, only the following lines should be considered when looking >>> at the POC. >>> >> myProject=cmake.Project("MyTestProject") >>> >> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] >>> >>> Yes, this is the kind of stuff that can be in a declarative format. >>> >>> > It seems you have in mind to write a new CMake language. >>> >>> No, at most a new specification format that can be used for IDE >>> integration. >>> If some kind of user-coded function were included in the specification it >>> should certainly be in an existing language. >>> >>> > Maybe I should take my POC further >>> >>> I think implementation even of a POC is premature at this point. We >>> should explore the design space further. >>> >>> > CMake's own buildsystem seems like a good testing ground for this, but >>> > it is a little too big for a first go, do you know of a small >>> CMake-based >>> > project that would be better suited ? >>> >>> Maybe you could find something in our test suite. >>> >>> > I don't have a clear view of what a pure functional CMake would look >>> like, >>> > but if you give me some mock code, I could give a try at bringing some >>> pure >>> > functional language up to the level of my POC and we could use it as a >>> more >>> > concrete discussion support. >>> >>> I have no prototype (nor substantial time to spend on design myself) but >>> I've imagined a declarative format in a well-known syntax (e.g. JSON or >>> one >>> of the lightweight human-friendly choices). If generate-time >>> functionality >>> is needed then code snippets in e.g. Lua could be included. >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> Petr Kmoch wrote: >>> > I'd like to voice my opinion as a somewhat advanced CMake user here. >>> >>> Thanks for joining the discussion with this point of view. >>> >>> > For me, one of the strongest points of CMake is the fact that its >>> project >>> > specification is procedural rather than declarative. >>> >>> Good. We will not be dropping imperative capabilities. >>> >>> > end result of our framework is that the CMakeLists consist mostly of >>> > declarative commands from our framework >>> >>> Yes, many projects have such frameworks. Most of them result in a >>> declarative spec inside calls to their macros/functions. I'd like to >>> formalize such specs in a re-usable way. >>> >>> > If I understand Brad's suggestion correctly, it would amount to a >>> > (possibly empty) procedural step being used to generate a declarative >>> > description of the buildsystem. >>> >>> Not quite. Yes, the procedural/imperative part would still be the entry >>> point as it is now. However, the declarative part would also be an >>> input, not an output. The procedural part's role would be to compute >>> *parameters* to be used for the evaluation of the declarative spec. >>> >>> For example, imagine the declarative spec somehow encodes that source >>> file "foo.c" is optional based on some condition "FOO". The value of >>> that condition could be computed by the procedural part of the process >>> based on system introspection, command-line options, etc., and then >>> provided to CMake for use in the final evaluation. >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> On 01/11/2016 01:21 PM, Pau Garcia i Quiles wrote: >>> > The moment you make CMake scriptable in more than one language, you >>> are forcing >>> > every CMake user to learn that additional language because sooner or >>> later he >>> > will step into a third-party that is using that additional language. >>> >>> I don't think the main "entry point" language should be selectable. >>> >>> As discussed above if some kind of callback or user-coded function needs >>> to >>> be included for advanced usage of the declarative spec then we would need >>> a language for it. The current CMake language is not well suited to that >>> use case (e.g. no expressions or return values), so an existing >>> alternative >>> language should be chosen. >>> >>> CMake's current "generator expressions" fill this role somewhat now and >>> are >>> essentially a sub-language. As with the main language they grew out of >>> something not intended to serve their current full role. They could be >>> superseded by a common alternative generate-time language too. >>> >>> > Also, declarative? Why? >>> >>> See above. >>> >>> > There are already a few declarative build systems >>> >>> Yes, and perhaps we can learn from their formats for the proposed >>> declarative >>> part. >>> >>> > qbs, one of the reasons for its existence was CMake was not declarative >>> >>> IIUC that is exactly because of the fact that an imperative spec cannot >>> be pierced easily for editing in IDEs. >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> Thanks all for the discussion so far! >>> >>> -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 >>> >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gour at atmarama.com Wed Jan 13 08:27:34 2016 From: gour at atmarama.com (=?UTF-8?Q?Sa=C5=A1a_Jani=C5=A1ka?=) Date: Wed, 13 Jan 2016 14:27:34 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: <1452691654.2609.47.camel@atmarama.com> On Sri, 2016-01-13 at 13:14 +0000, Charles Huet wrote: > I don't think this is a dumb question, actually this is part of the > problem I think would be resolved whit a new language. > > The barrier of entry to using CMake is too high in my opinion, and I > think using an existing language would lower it *a lot*. Personally I'm determinant to use CMake, mostly due to its maturity and? CPack's features, but recently stumbled upon Meson http://mesonbuild.com/)? build system whose goal is "to be both extremely fast, and, even more? importantly, as user friendly as possible."...it also uses Ninja instead? of Make as backend. Otoh, I believe that main problem with CMake is lack of quality docs - even? Mastering CMake book has constantly very bad reviews. Sincerely, Gour -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. From brad.king at kitware.com Wed Jan 13 08:41:07 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 13 Jan 2016 08:41:07 -0500 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> <56951624.1040302@kitware.com> Message-ID: <569653F3.1010100@kitware.com> On 01/12/2016 05:36 PM, Milian Wolff wrote: > Also, while above you say there are two orthogonal features (which is > correct), there is an important fact that has not yet been stressed enough: > > The daemon approach of Stephen allows for the implementation of both. And both > of these features are crucial and important to have. [snip] On 01/12/2016 03:24 PM, Stephen Kelly wrote: > Yes. I count 3 orthogonal ways an IDE and cmake could 'interface': [snip] > a daemon and a declarative spec for the sources covers all three. [snip] > I can do development, but it would have to be as part of a collaborative > effort and collaborative future maintenance. [snip] > Yes. I'm trying to generate interest in people who are capable of joining > the effort, and interested in doing so. It is difficult :). I think the responses in this thread have indicated there is interest in working toward the full daemon approach. Perhaps discussion should now proceed on the daemon protocol design over in the thread Tobias started on cmake-developers: cmake daemon mode protocol http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15424 Meanwhile some discussion of a possible declarative spec has started here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15374 -Brad From brad.king at kitware.com Wed Jan 13 09:12:31 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 13 Jan 2016 09:12:31 -0500 Subject: [cmake-developers] Allowing generator expressions in install DIRECTORY In-Reply-To: References: Message-ID: <56965B4F.7010709@kitware.com> On 01/12/2016 04:34 PM, Yves Frederix wrote: > I am attaching a patch that adds support for generator expressions in > the DIRECTORY arguments of install(DIRECTORY ...). It is my first > contribution Very nice! The impl, docs, and tests all look good. Applied with minor whitespace tweak and a release note update: install: Allow generator expressions in DIRECTORY https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=630c8aa8 Thanks, -Brad From brad.king at kitware.com Wed Jan 13 10:07:39 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 13 Jan 2016 10:07:39 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> Message-ID: <5696683B.2050703@kitware.com> On 01/13/2016 07:00 AM, Eric Wing wrote: > So I got the trivial base case working with swiftc (no library > dependencies, Mac for now but will shift to Linux eventually): > add_exectuable(MyTarget main.swift) Great! > Problem 1: Intermixing C and Swift > add_exectuable(MyTarget main.swift some_c.c) > Note: I presume C++ (and Obj-C) could also be in the mix: > add_exectuable(MyTarget main.swift some_c.c some_cpp.cpp some_objc.m) > > It looks like the link phase is invoking cc on my system (the C linker > rules?) instead of the Swift linker commands. > > If my hunch is correct, how do I tell CMake to ?promote? Swift as the > correct tool? See the CMAKE__LINKER_PREFERENCE platform information variable. There is also the LINKER_LANGUAGE target property. For C, C++, and Fortran one generally chooses between C++ and Fortran to drive the linker based on which language has the entry point (main) in its sources. If we see a "main.swift" then we know Swift should be used. If not then I don't know enough about Swift linking requirements to say. > Problem 2: Multiple Swift files in the target > add_exectuable(MyTarget main.swift OtherSwift.swift) > > With two or more files, I was hoping to do a single one-shot call: > swiftc -c OtherSwift.swift main.swift -module-name MyTarget [snip] > But before I move on to that, is there a way to get CMake to invoke > all the Swift files in the target together? (It would need to exclude > any non-Swift files in the list.) > > I think there may be trade-offs here. On one hand, file-by-file might > get us incremental compilation. But there is a flag called > -whole-module-optimization which suggests treating them as a batch > could allow better code generation. This looks like a semantic difference between how the switfc and cc compilers work that as I feared in my previous response may require C++ changes to CMake to make work. Before diving into that we need to understand the preferred way to compile multiple Swift sources. Last time I looked at this the only reference was "what Xcode does". Hopefully there is more information out there now. > Now for the 'swift' tool: > > So the swift tool can go file-by-file, but the additional constraint > is that all the other Swift files in the target must be listed too. To > distinguish which file is actually being processed, you must use the > -primary-file . I think this is so > Swift can figure out all the cross-file dependencies since there are > no header files in Swift. Interesting. My previous comment above applies here too. It may be that we're supposed to invoke Swift with all sources at once and let it take responsibility for generating the results and doing any kind of incremental stuff internally. > - SOURCES doesn't actually exist in CMake, but I saw something called > OBJECTS which makes me think they are a similar concept. It shouldn't be too hard to add a placeholder if needed. We may need it either way because we either list all the sources on one call to swift or on every call to swift. > - Also, for the second , I need to remove the one I'm using > from my -primary-file. And there shouldn't be any non-Swift files in > the list (no C/C++/Obj-C). That kind of filtering may be harder to define and require custom logic in CMake's generators for Swift instead of trying to do it with generic placeholders. > - I'm not sure if I'm responsible for the intermediate products > directories. Do I need to explicitly concat the paths to any of these > things. The placeholder will contain the intermediate directories when replaced. We may need new placeholders for other things that go in these directories for Swift though. > - I haven't added the bridging header flag/value yet. I need some > expected variable that holds it. A target property will likely have to be introduced to hold this. > Can you give me some suggestions on what to look at next? Before proceeding with CMake changes I think we need a better understanding of the tools involved in Swift development. What does individual compilation achieve over monolithic compilation? How does Swift linking interact with other languages? Etc. Side note: When we first added Java support to CMake we tried to make it a builtin language just like C and C++, and even have rules to tell the generators how to compile each .java -> .class source separately. Later we learned that due to nested classes there can be circular dependencies among .java sources and the only safe way to compile it is to list all sources at once and let the compiler handle them internally. Now Java is used in CMake through the FindJava and UseJava modules that use custom commands to do the monolithic compilation. All the builtin Java support is pretty much unused because it has never been ported to the monolithic compilation approach. I'd prefer not to repeat such mistakes with Swift. Given Swift's relationship to ObjC/C++ this may also be time to revive earlier work posted here (but never finished) on making OBJC and OBJCXX languages separate from C and CXX in CMake. This would be useful if we need to distinguish the languages in order to properly mix with Swift. -Brad From ben.boeckel at kitware.com Wed Jan 13 10:54:11 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 13 Jan 2016 10:54:11 -0500 Subject: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties? In-Reply-To: References: <568F9BB7.7090604@gmail.com> <568FB358.9060005@gmail.com> <568FC3C1.50803@gmail.com> Message-ID: <20160113155411.GA30728@megas.kitware.com> On Mon, Jan 11, 2016 at 16:47:03 -0500, Taylor Braun-Jones wrote: > I have another INTERFACE property use case that is not whitelisted, but > should be: VERSION VERSION is a special property for libraries. Particularly the name for the file with the actual content of the library (the SOVERSION and name of the library being symlinks to it): https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html INTERFACE targets have no need for this property. > Consider library project Foo that uses a header-only project Bar. In > FooConfig.cmake, it is a important to ensure any projects using Foo also > use the exact same version of Bar that Foo was originally built with > (Failure to do so can lead to subtle, hard-to-find bugs like violation of > the one definition rule). Assuming project Bar creates an imported target > "Bar" with a VERSION property set like: > > set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3) Also, this property is not a list (probably?), so APPEND isn't really correct. It indicates that the value here should be (list-)appended to the existing value. > Then project Foo should be able to have something like: > > == CMakeLists.txt == > ... > get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION) > configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY) > > == FooConfig.cmake.in == > ... > find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED) find_package(Foo) should set a Foo_VERSION variable (if known): https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-version-file > But, alas, this is not currently possible. I'm ambivalent about whether > INTERFACE properties should be whitelisted vs blacklisted vs unrestricted, > but at least this VERSION property seems valid to allow. Currently, they are whitelisted, but I think any property not understood by CMake directly (i.e., user-set properties) would probably be fine. --Ben From rcdailey.lists at gmail.com Wed Jan 13 11:16:23 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 13 Jan 2016 10:16:23 -0600 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu Message-ID: Running version 3.2.2 on Ubuntu 15. I run the following command: $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake" My toolchain file is specified as follows: set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_VERSION 1) set(CMAKE_SYSTEM_PROCESSOR "i686") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags") I get the following output when I generate for KDevelop. Why is CMake not properly generating my projects? Based on what the assertion says, I do actually define some interface libraries, mostly to create "dummy" targets for my third party libraries. If I have a library with only headers and no binaries or libs, I will make them as interface libraries. I will post a sample of this below the output below. -- The C compiler identification is GNU 4.9.3 -- The CXX compiler identification is GNU 4.9.3 -- Check for working C compiler: /usr/bin/gcc-4.9 -- Check for working C compiler: /usr/bin/gcc-4.9 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/g++-4.9 -- Check for working CXX compiler: /usr/bin/g++-4.9 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Generating copy_dlls for configurations: Debug -- + UI > Core/UI/CMakeLists.txt -- + WebServices > Core/WebServices/CMakeLists.txt -- + Barcode > Core/Barcode/CMakeLists.txt -- + TestUtils > Core/UI/TestUtils/CMakeLists.txt -- + DynamicUI > Applications/DynamicUI/CMakeLists.txt -- + OrderEntry > Applications/OrderEntry/CMakeLists.txt -- + PATT > Applications/PATT/CMakeLists.txt -- + EmailClub > Applications/EmailClub/CMakeLists.txt -- + Survey > Applications/Survey/CMakeLists.txt -- + SettingsManager > Applications/SettingsManager/CMakeLists.txt -- + zFacebook > Applications/zFacebook/CMakeLists.txt -- + Loyalty > Applications/Loyalty/CMakeLists.txt -- + MessagingModule > Applications/MessagingModule/CMakeLists.txt -- + zApp > Applications/zApp/CMakeLists.txt -- + zApp_Library > Applications/zApp/CMakeLists.txt -- Configuring done cmake: ../../Source/cmTarget.cxx:722: void cmTarget::GetSourceFiles(std::vector >&, const string&) const: Assertion `this->GetType() != INTERFACE_LIBRARY' failed. ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13: 21545 Aborted (core dumped) cmake "$DIR/../../.." -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config -DCMAKE_TOOLCHAIN_FILE="$DIR/../toolchains/linux_i686.toolchain.cmake" Sample of how I define interface libraries (contents of one of my CMakeLists.txt): set( project_name Catch ) add_library( ${project_name} INTERFACE ) target_include_directories( ${project_name} INTERFACE include ) From mantis at public.kitware.com Wed Jan 13 11:25:57 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 13 Jan 2016 11:25:57 -0500 Subject: [cmake-developers] [CMake 0015915]: add_subdirectory(directory EXPORT_VARIABLES VAR_1 VAR_2) gives "add_subdirectory called with incorrect number of arguments" Message-ID: <52dfce84a139b6276113239a232b6ac1@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15915 ====================================================================== Reported By: Bryan Koch Assigned To: ====================================================================== Project: CMake Issue ID: 15915 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2016-01-13 11:25 EST Last Modified: 2016-01-13 11:25 EST ====================================================================== Summary: add_subdirectory(directory EXPORT_VARIABLES VAR_1 VAR_2) gives "add_subdirectory called with incorrect number of arguments" Description: As per, https://cmake.org/pipermail/cmake/2005-September/007204.html ADD_SUBDIRECTORY(directory EXPORT VARIABLES VAR_FOO1 VAR_FOO2) should export variables from the child scope into the parent scope. It was implemented by Ken Martin as per below https://cmake.org/Bug/bug_relationship_graph.php?bug_id=2221&graph=relation ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-13 11:25 Bryan Koch New Issue ====================================================================== From brad.king at kitware.com Wed Jan 13 13:36:40 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 13 Jan 2016 13:36:40 -0500 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: References: Message-ID: <56969938.2020104@kitware.com> On 01/13/2016 11:16 AM, Robert Dailey wrote: > Running version 3.2.2 on Ubuntu 15. I run the following command: [snip] > cmake: ../../Source/cmTarget.cxx:722: void > cmTarget::GetSourceFiles(std::vector >> &, const string&) const: Assertion `this->GetType() != > INTERFACE_LIBRARY' failed. > ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13: > 21545 Aborted (core dumped) cmake "$DIR/../../.." Please try running with CMake 3.4 or 'master' to see if it still happens. There has been substantial refactoring of this code since 3.2. Thanks, -Brad From rcdailey.lists at gmail.com Wed Jan 13 13:44:59 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 13 Jan 2016 12:44:59 -0600 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: <56969938.2020104@kitware.com> References: <56969938.2020104@kitware.com> Message-ID: On Wed, Jan 13, 2016 at 12:36 PM, Brad King wrote: > On 01/13/2016 11:16 AM, Robert Dailey wrote: >> Running version 3.2.2 on Ubuntu 15. I run the following command: > [snip] >> cmake: ../../Source/cmTarget.cxx:722: void >> cmTarget::GetSourceFiles(std::vector >>> &, const string&) const: Assertion `this->GetType() != >> INTERFACE_LIBRARY' failed. >> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13: >> 21545 Aborted (core dumped) cmake "$DIR/../../.." > > Please try running with CMake 3.4 or 'master' to see if it still > happens. There has been substantial refactoring of this code > since 3.2. > > Thanks, > -Brad > 3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can add to grab the latest CMake debian package? From eike at sf-mail.de Wed Jan 13 14:09:40 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 13 Jan 2016 20:09:40 +0100 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: References: <56969938.2020104@kitware.com> Message-ID: <2282628.19M1reMNyk@caliban.sf-tec.de> Am Mittwoch, 13. Januar 2016, 12:44:59 schrieb Robert Dailey: > On Wed, Jan 13, 2016 at 12:36 PM, Brad King wrote: > > On 01/13/2016 11:16 AM, Robert Dailey wrote: > >> Running version 3.2.2 on Ubuntu 15. I run the following command: > > [snip] > > > >> cmake: ../../Source/cmTarget.cxx:722: void > >> cmTarget::GetSourceFiles(std::vector > >> > >>> &, const string&) const: Assertion `this->GetType() != > >> > >> INTERFACE_LIBRARY' failed. > >> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13: > >> 21545 Aborted (core dumped) cmake "$DIR/../../.." > > > > Please try running with CMake 3.4 or 'master' to see if it still > > happens. There has been substantial refactoring of this code > > since 3.2. > 3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can > add to grab the latest CMake debian package? https://cmake.org/files/v3.4/cmake-3.4.1-Linux-i386.tar.gz Extract it whereever you like, then point the PATH variable to it. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Wed Jan 13 14:17:34 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 13 Jan 2016 14:17:34 -0500 Subject: [cmake-developers] [CMake 0015916]: [Buildroot] [PATCH] cmake: use system libzma when the xz package is enabled Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15916 ====================================================================== Reported By: R Jones Assigned To: ====================================================================== Project: CMake Issue ID: 15916 Category: CMake Reproducibility: always Severity: tweak Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-13 14:17 EST Last Modified: 2016-01-13 14:17 EST ====================================================================== Summary: [Buildroot] [PATCH] cmake: use system libzma when the xz package is enabled Description: I have XZ installed already. I was trying to compile cmake using gmake and GCC4. The error is: Fix build failure: .../output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/block_buffer_decoder.c:17:1: error: conflicting types for ?lzma_block_buffer_decode? lzma_block_buffer_decode(lzma_block *block, lzma_allocator *allocator, ^ In file included from /home/tetsuya/buildroot/br2/output/host/usr/include/lzma.h:296:0, from /home/tetsuya/buildroot/br2/output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/common.h:34, from /home/tetsuya/buildroot/br2/output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/block_decoder.h:16, from /home/tetsuya/buildroot/br2/output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/block_buffer_decoder.c:13: /home/tetsuya/buildroot/br2/output/host/usr/include/lzma/block.h:577:27: note: previous declaration of ?lzma_block_buffer_decode? was here extern LZMA_API(lzma_ret) lzma_block_buffer_decode( ^ Utilities/cmliblzma/CMakeFiles/cmliblzma.dir/build.make:261: recipe for target 'Utilities/cmliblzma/CMakeFiles/cmliblzma.dir/liblzma/common/block_buffer_decoder.c.o' failed make[3]: *** [Utilities/cmliblzma/CMakeFiles/cmliblzma.dir/liblzma/common/block_buffer_decoder.c.o] Error 1 Steps to Reproduce: On a Solaris system with with GCC4, GMAKE, ZLIB, EXPAT, BZIP2, CURL, XZ and without cmake installed: CFLAGS=-I{INSTARGET}/include bash ./configure \ --prefix=${INSTARGET} \ --system-zlib \ --system-expat \ --system-bzip2 \ --system-curl Causes the problem in the description. After patching bootstrap (see below), I was able to clear the problem with: bash ./configure \ --prefix=${INSTARGET} \ --system-zlib \ --system-expat \ --system-bzip2 \ --system-liblzma \ --system-curl Additional Information: I found this thread when looking into how to disable cmake build from trying to include it's own liblzma instead of the system liblzma. It seems that the engine is prepared for it, but bootstrap does not allow --system-liblzma as an option. All I needed to do to disable the internal copy was to add this to bootstrap and re-run configure: $ diff bootstrap bootstrap.orig 652c652 < --system-bzip2|--system-curl|--system-expat|--system-jsoncpp|--system-libarchive|--system-zlib|--system-liblzma) --- > --system-bzip2|--system-curl|--system-expat|--system-jsoncpp|--system-libarchive|--system-zlib) Also would need to update the "help" Is there some reason this option could not be added to the package? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-13 14:17 R Jones New Issue ====================================================================== From kfunk at kde.org Wed Jan 13 14:13:44 2016 From: kfunk at kde.org (Kevin Funk) Date: Wed, 13 Jan 2016 20:13:44 +0100 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: References: <56969938.2020104@kitware.com> Message-ID: <1749795.hMKRzHx546@kerberos> On Wednesday, January 13, 2016 12:44:59 PM Robert Dailey wrote: > On Wed, Jan 13, 2016 at 12:36 PM, Brad King wrote: > > On 01/13/2016 11:16 AM, Robert Dailey wrote: > >> Running version 3.2.2 on Ubuntu 15. I run the following command: > > [snip] > > > >> cmake: ../../Source/cmTarget.cxx:722: void > >> cmTarget::GetSourceFiles(std::vector > >> > >>> &, const string&) const: Assertion `this->GetType() != > >> > >> INTERFACE_LIBRARY' failed. > >> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13: > >> 21545 Aborted (core dumped) cmake "$DIR/../../.." > > > > Please try running with CMake 3.4 or 'master' to see if it still > > happens. There has been substantial refactoring of this code > > since 3.2. > > > > Thanks, > > -Brad > > 3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can > add to grab the latest CMake debian package? There are pre-built binaries here: https://cmake.org/download/ I also use them on Ubuntu, no issues. Cheers, Kevin -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From neundorf at kde.org Wed Jan 13 16:16:44 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 13 Jan 2016 22:16:44 +0100 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: References: Message-ID: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > Running version 3.2.2 on Ubuntu 15. I run the following command: > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake" are you sure you actually want to use the KDevelop3 generator ? This is for the KDE3 version, and you are probably using the KDE4 version of KDevelop ? For that you don't need these generated project files. Actually I was thinking about removing this generator, because KDevelop3 is really really old, not sure whether it is still available in current Linux distributions. Alex From neundorf at kde.org Wed Jan 13 16:21:23 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 13 Jan 2016 22:21:23 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: Message-ID: <1509633.2oM98exVdc@tuxedo.neundorf.net> On Wednesday, January 13, 2016 10:59:39 yann suisini wrote: > Hi, > > I'm a new user of CMake, but I just want to express my newcomer point of > view. > Honestly , I can feel the power of CMAKE, but it's a real pain to learn ... > I'm using CMAKE for an embedded platform with a non GNU compiler , ant at > the end the CMAKE description is longer than the one I built directly in > Ninja. > I had to write a python script to parse my eclipse project xml to create a > list of sources files usable by CMAKE. > The first thing I thought was: why this is not a part of cmake ? And the > second thing was : why not using the scripting power of an existing > language like Python(or other one) and add CMAKE as a framework / library ? My personal opinion: if the full power of python would be available, the build scripts would quickly turn into real programs, because programmers would be tempted to do so if all of python would be available. Then developers would have to understand two programs: the program itself, and the "build program". I'm not saying that the cmake language is beautiful, but it helps to keep cmake scripts somewhat simple, and not evolve into a second program additionally to the actual program which is being built. Alex From mantis at public.kitware.com Wed Jan 13 18:16:06 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 13 Jan 2016 18:16:06 -0500 Subject: [cmake-developers] [CMake 0015917]: Visual Studio project files generated incorrectly Message-ID: <5fab4955104ecb9a4089ece1b9ec8847@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15917 ====================================================================== Reported By: Daniel Williams Assigned To: ====================================================================== Project: CMake Issue ID: 15917 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-13 18:16 EST Last Modified: 2016-01-13 18:16 EST ====================================================================== Summary: Visual Studio project files generated incorrectly Description: Executables are incorrectly flagged as Application executables (i.e. to use winMain) instead of utility / console executables (and use the normal main) when cmake is generating solution (.sln) and project (.vcxproj) files for Visual Studio, it cannot set the flags correctly. The generator creates: Application Instead of: Utility This in turn causes compile-time Link Errors As it should. This is controlled by a flag on the executable. (or so says the documentation): [1]https://cmake.org/cmake/help/v3.4/command/add_executable.html [2]https://cmake.org/cmake/help/v3.4/prop_tgt/WIN32_EXECUTABLE.html Steps to Reproduce: 1) create empty project with supplied CMakeLists.txt 2) create a minimal 'main.cpp' (contents don't matter, empty should be fine) 3) run configure ; run generate 4) inspect $BUILD_DIR/test.exe.vcxproj DOM: Project/PropertyGroup/ConfigurationType values will all still be set to "Application" which requires the winmain symbol be defined. This Application tag is generated both with and without the WIN32 flag. It is only supposed to be generated *with*. (Without the flag, the 'ConfigurationType' tag should be set to 'Utility', the console exe version.) Additional Information: 1) Originally Reproduced as far back as CMake 3.1.2 2) the 'set_executable(...)' function correctly sets the flag, as checked by 'get_target_property(...)', but this property does not carry through to the file generation stage. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-13 18:16 Daniel WilliamsNew Issue 2016-01-13 18:16 Daniel WilliamsFile Added: CMakeLists.txt ====================================================================== From ewmailing at gmail.com Wed Jan 13 18:17:45 2016 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 13 Jan 2016 15:17:45 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <5696683B.2050703@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> Message-ID: >> If my hunch is correct, how do I tell CMake to ?promote? Swift as the >> correct tool? > > See the CMAKE__LINKER_PREFERENCE platform information variable. > There is also the LINKER_LANGUAGE target property. For C, C++, and > Fortran one generally chooses between C++ and Fortran to drive the > linker based on which language has the entry point (main) in its > sources. If we see a "main.swift" then we know Swift should be used. > If not then I don't know enough about Swift linking requirements to say. I suspect it is like C++ and C. If there is both, you promote up to C++ linking. So if there is any .swift file or library in the mix, you need to promote up to use Swift. Under the hood, I think the LLVM linker can handle all of these through ld. But I think the thing that is tripping me up is that Swift seems to need to link against some additional libraries which are not needed in the pure C case. The swiftc command seems to know how to automatically link in those extra dependencies (and I don't need to add all the search paths to where the Swift core libraries are located). Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same as Java). But it didn't seem to do anything for me. I then added to my test CMakeLists.txt: set_property(TARGET MyApp PROPERTY LINKER_LANGUAGE Swift) That then worked, but I'm confused how to get CMake to automatically do this for me because I expected CMAKE_Swift_LINKER_PREFERENCE to do this. > > This looks like a semantic difference between how the switfc and cc > compilers work that as I feared in my previous response may require > C++ changes to CMake to make work. Before diving into that we need > to understand the preferred way to compile multiple Swift sources. > Last time I looked at this the only reference was "what Xcode does". > Hopefully there is more information out there now. Unfortunately, there isn't a whole lot more information. The majority of the examples are hello world programs with one file. The best write up I've seen is this series: http://owensd.io/blog/compiling-swift-without-xcode/ http://owensd.io/blog/compiling-individual-files/ http://owensd.io/blog/swift-vs-swiftc/ http://owensd.io/blog/swift-makefiles---take-2/ One interesting note, swiftc is just an alias for swift. The exception is the Swift Package manager. But this is a convention based system. Right now it is far from finished and its conventions are actually incompatible with Xcode. It has its own file format and also requires all dependency packages be in a Git repo and follow a certain tagging convention. I also haven't seen any way to directly mix C+Swift code in a module and they expect you to create a separate module for C stuff which you then import in. I'm under the impression they plan to relax a lot of these things, but I find it currently too incomplete and with too much impedance to be useful right now. (By the way, I think I'm a little incorrect about main.swift being special. I'm seeing examples where they name the file anything.swift. It looks like Swift will automatically create a main entry point for you when building an executable, especially in the one-shot case. With swiftc it must be a one-shot otherwise you get duplicate symbols. With swift -frontend, it some how manages to create one. But with the Swift Package system, I think main.swift is a convention-requirement.) > It may be that we're supposed to invoke Swift with all sources at once > and let it take responsibility for generating the results and doing any > kind of incremental stuff internally. So Xcode is using the swift -frontend technique and it looks like it doing it incrementally. I think the requirement for the list of other files is so it can resolve the dependencies. > It shouldn't be too hard to add a placeholder if needed. We > may need it either way because we either list all the sources on one > call to swift or on every call to swift. Right. >> - Also, for the second , I need to remove the one I'm using >> from my -primary-file. And there shouldn't be any non-Swift files in >> the list (no C/C++/Obj-C). > > That kind of filtering may be harder to define and require custom logic > in CMake's generators for Swift instead of trying to do it with generic > placeholders. I just tried not filtering the current primary file from the list. It still worked. So maybe we can get away with not filtering that. However, we do need to filter any C files. That didn't work. (It tried to compile those .c files as Swift which obviously won't work.) >> Can you give me some suggestions on what to look at next? > > Before proceeding with CMake changes I think we need a better > understanding of the tools involved in Swift development. What > does individual compilation achieve over monolithic compilation? I'm actually not sure. The monolithic one-shot should avoid any potential incorrectness problems if a dependent file was changed but a calling file wasn't recompiled. I don't know if Swift has these types of problems like C or if it is immune. It feels like Xcode is doing some incremental building or caching for me by doing individual compilation. However, it seems to recompile both files in the log. But Xcode is using a bunch of other switches and temporary files that may be assisting this. > How does Swift linking interact with other languages? Etc. So as I mentioned, ld seems to be able to handle all the .o files regardless of language and link them. The constraint seems to be that Swift adds some additional dependencies. I think I read a claim that somebody linked to .o files created by gcc instead of clang. I probably wouldn't recommend this, but it suggests there isn't anything that special by the time we reach this stage. > Side note: When we first added Java support to CMake we tried to > make it a builtin language just like C and C++, and even have > rules to tell the generators how to compile each .java -> .class > source separately. Later we learned that due to nested classes > there can be circular dependencies among .java sources and the > only safe way to compile it is to list all sources at once and > let the compiler handle them internally. Now Java is used in > CMake through the FindJava and UseJava modules that use custom > commands to do the monolithic compilation. All the builtin > Java support is pretty much unused because it has never been > ported to the monolithic compilation approach. I'd prefer not > to repeat such mistakes with Swift. So I think we will need that list of all sources for Swift because like Java, there are no header files so the compiler needs to resolve dependencies. For the moment, I like swiftc over swift because it seems a lot simpler. I hope this means the least changes for CMake right now. I won't lie to you. In maybe two years, the Swift Package Manager will probably be closer to finished/stable and we may need to re-evaluate things. I suspect there will be a temptation to invoke it because it will have the ability to download dependencies from the internet on the fly. However, it's still too early for me to guess how this is going to interoperate with C code, local libraries, bundling resources, packaging and codesigning for distribution. One story is that this will completely sub-plant the need for something like CMake. Another story is that the Linux/Swift effort initially seems to be focused on server/headless backends which doesn't need a lot of the same things as front-end applications. So Xcode and CMake still may be needed and people may find the Package Manager isn't useful outside server apps. (It currently reminds me a little of Go's system which is also heavily server focused.) > Given Swift's relationship to ObjC/C++ this may also be time to > revive earlier work posted here (but never finished) on making > OBJC and OBJCXX languages separate from C and CXX in CMake. This > would be useful if we need to distinguish the languages in order > to properly mix with Swift. > Maybe, but I think we can punt on that for two reasons. 1) As I said, the LLVM linker seems to handle all these already more or less transparently. For Swift, we just need to separate Swift files from everything else. 2) The open source Swift release does not include Obj-C. They are pushing a pure Swift solution for everybody else. Since the Xcode generator for Swift more or less works*, I think that is the proper way using Swift on Mac/iOS. That already handles a lot of esoteric platform stuff better and also handles the Obj-C/Obj-C++ more correctly. *By the way, I found two minor issues... (1) Swift has additional separate flags for some things like optimization settings: we need to duplicate the CMake Debug/Release/MinSizeRel/RelWithDebug flags for the Swift section, (2) Everytime I create a new Xcode/Swift project, a prompt comes up telling me my Swift version is 1.x and the wizard will help me migrate my code to the latest. I suspect there is some version flag in the generated Xcode project that needs to be bumped up. Anyway, it seems like adding SOURCES is the next step. Any hints on how to do that? Thanks, Eric From ewmailing at gmail.com Wed Jan 13 18:39:07 2016 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 13 Jan 2016 15:39:07 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> Message-ID: > For the moment, I like swiftc over swift because it seems a lot > simpler. I hope this means the least changes for CMake right now. I need to correct myself on this. While I like swiftc for looking simpler, I'm actually thinking swift might be fewer changes since the file-by-file thing is what CMake does today. It may turn out swift is easier to figure out in the end too when we eventually look at add_library and linking them (since we can reverse engineer from the Xcode logs). But either way, both of them seem to need SOURCES. Thanks, Eric From mantis at public.kitware.com Wed Jan 13 23:08:00 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 13 Jan 2016 23:08:00 -0500 Subject: [cmake-developers] [CMake 0015918]: fixup_bundle issues with dependency @loader_path Message-ID: <797d66f9100d07ccad094bac587ba2f2@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15918 ====================================================================== Reported By: xzcvczx Assigned To: ====================================================================== Project: CMake Issue ID: 15918 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-13 23:08 EST Last Modified: 2016-01-13 23:08 EST ====================================================================== Summary: fixup_bundle issues with dependency @loader_path Description: If a cmake project target (1) depends on a library (2) which depends on another library(3) using @loader_path then fixup_bundle won't be able to copy (3) as it will not understand the path @loader_path, nor does it have enough information to resolve the path. Steps to Reproduce: I currently have an application which depends on /usr/local/lib/libboost_context-mt.dylib this in turn depends on @loader_path/libboost_chrono-mt.dylib libboost was installed using homebrew. I was having issues as @loader_path was not being copied into the binaries directory as part of the fixup_bundle process and so it would fail. After a fair amount of work i found it was use get_prerequisites which would give a list of files, but it never provides the resolved paths, I hacked this to provide the resolved paths, and then when verify_app was occuring it would die there as well due to everything having a resolved path Attached is a patch that allows it to work but is just a hack which works by adding a argument to add_reprequisites thats currently being used to say whether a resolved path or a relative path is wanted. Additional Information: otool -L for the cmake target (1) build/eeschema/eeschema.app/Contents/MacOS/eeschema: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /Users/simon/Documents/stuff/kicad-mac-packaging/wx/wx-build/../wx-bin/lib/libwx_osx_cocoau_gl-3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0) /Users/simon/Documents/stuff/kicad-mac-packaging/wx/wx-build/../wx-bin/lib/libwx_osx_cocoau-3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/opt/boost/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/opt/boost/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0) otool -L for brew installed libboost_context-mt.dylib (2) /usr/local/opt/boost/lib/libboost_context-mt.dylib: /usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) otool -L for brew installed libboost_chrono-mt.dylib /usr/local/opt/boost/lib/libboost_chrono-mt.dylib: /usr/local/opt/boost/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-13 23:08 xzcvczx New Issue 2016-01-13 23:08 xzcvczx File Added: Bundle.patch ====================================================================== From marc.chevrier at sap.com Thu Jan 14 03:03:24 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 14 Jan 2016 08:03:24 +0000 Subject: [cmake-developers] CMake alternative language In-Reply-To: <1509633.2oM98exVdc@tuxedo.neundorf.net> References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: I fully agree with Alexander. It seems a very bad idea to use a general purpose script language to manage CMake stuff. For sure, CMake language is a bit ?curious? :) and changing for a more user friendly one is a good idea but, in my opinion, only dedicated languages (I.e. Specialised for the problem to solve) must be considered. May be a good approach is to enhance current language for more flexibility (for example adding capability for functions to return value, etc?) Marc On 13/01/16 22:21, "cmake-developers on behalf of Alexander Neundorf" wrote: >On Wednesday, January 13, 2016 10:59:39 yann suisini wrote: >> Hi, >> >> I'm a new user of CMake, but I just want to express my newcomer point of >> view. >> Honestly , I can feel the power of CMAKE, but it's a real pain to learn ... >> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at >> the end the CMAKE description is longer than the one I built directly in >> Ninja. >> I had to write a python script to parse my eclipse project xml to create a >> list of sources files usable by CMAKE. >> The first thing I thought was: why this is not a part of cmake ? And the >> second thing was : why not using the scripting power of an existing >> language like Python(or other one) and add CMAKE as a framework / library ? > >My personal opinion: if the full power of python would be available, the build >scripts would quickly turn into real programs, because programmers would be >tempted to do so if all of python would be available. Then developers would >have to understand two programs: the program itself, and the "build program". > >I'm not saying that the cmake language is beautiful, but it helps to keep >cmake scripts somewhat simple, and not evolve into a second program >additionally to the actual program which is being built. > >Alex > >-- > >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 From charles.huet at gmail.com Thu Jan 14 03:09:18 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 14 Jan 2016 08:09:18 +0000 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: I think this problem already exists. When "projects build elaborate macro/function systems in the CMake language", you have to understand the build system program. And in my experience, those systems are widely different from one another. I have seen a system where you defined lots of variables, then just imported a file which used those to perform the add_library and such in the X-Macro pattern ( https://en.wikibooks.org/wiki/C_Programming/Preprocessor#X-Macros). I think having a language that allows for more terse expressions would be a net gain. Also, I find ironic to preach for a simple language when CMake is mainly targetted at C++. C++ programmers are used to having *lots* of very powerful tools at their disposal (template meta-programming, operator overloading, macros, etc) and having to choose which one to use for the job. If you do not trust your team mates to keep the buildsystem simple and to the point even if they had lots of stuff at their disposal, how can you trust them with the C++ program ? Le jeu. 14 janv. 2016 ? 09:04, CHEVRIER, Marc a ?crit : > I fully agree with Alexander. > It seems a very bad idea to use a general purpose script language to > manage CMake stuff. > > For sure, CMake language is a bit ?curious? :) and changing for a more > user friendly one is a good idea but, in my opinion, only dedicated > languages (I.e. Specialised for the problem to solve) must be considered. > > May be a good approach is to enhance current language for more flexibility > (for example adding capability for functions to return value, etc?) > > Marc > > > > > > On 13/01/16 22:21, "cmake-developers on behalf of Alexander Neundorf" < > cmake-developers-bounces at cmake.org on behalf of neundorf at kde.org> wrote: > > >On Wednesday, January 13, 2016 10:59:39 yann suisini wrote: > >> Hi, > >> > >> I'm a new user of CMake, but I just want to express my newcomer point of > >> view. > >> Honestly , I can feel the power of CMAKE, but it's a real pain to learn > ... > >> I'm using CMAKE for an embedded platform with a non GNU compiler , ant > at > >> the end the CMAKE description is longer than the one I built directly in > >> Ninja. > >> I had to write a python script to parse my eclipse project xml to > create a > >> list of sources files usable by CMAKE. > >> The first thing I thought was: why this is not a part of cmake ? And the > >> second thing was : why not using the scripting power of an existing > >> language like Python(or other one) and add CMAKE as a framework / > library ? > > > >My personal opinion: if the full power of python would be available, the > build > >scripts would quickly turn into real programs, because programmers would > be > >tempted to do so if all of python would be available. Then developers > would > >have to understand two programs: the program itself, and the "build > program". > > > >I'm not saying that the cmake language is beautiful, but it helps to keep > >cmake scripts somewhat simple, and not evolve into a second program > >additionally to the actual program which is being built. > > > >Alex > > > >-- > > > >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 > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Thu Jan 14 07:34:14 2016 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Thu, 14 Jan 2016 13:34:14 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: <1509633.2oM98exVdc@tuxedo.neundorf.net> References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf wrote: > > My personal opinion: if the full power of python would be available, the > build > scripts would quickly turn into real programs, because programmers would be > tempted to do so if all of python would be available. Then developers would > have to understand two programs: the program itself, and the "build > program". The problem is when you have to do a real program for your build system anyways (which occurs one day or another for any large enough project I guess). Currently it's a real pain (but it'd be even more painful to have to ship Python / Bash / $script_language as part of your build system). -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.huet at gmail.com Thu Jan 14 08:08:05 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 14 Jan 2016 13:08:05 +0000 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: As long as CMake embeds everything that is required, I don't see the additional pain (since this is what it already does with the CMake language). Le jeu. 14 janv. 2016 ? 13:35, Jean-Micha?l Celerier < jeanmichael.celerier at gmail.com> a ?crit : > > On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf > wrote: > >> >> My personal opinion: if the full power of python would be available, the >> build >> scripts would quickly turn into real programs, because programmers would >> be >> tempted to do so if all of python would be available. Then developers >> would >> have to understand two programs: the program itself, and the "build >> program". > > > The problem is when you have to do a real program for your build system > anyways (which occurs one day or another for any large enough project I > guess). > Currently it's a real pain (but it'd be even more painful to have to ship > Python / Bash / $script_language as part of your build system). > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannsuisini at gmail.com Thu Jan 14 08:32:50 2016 From: yannsuisini at gmail.com (yann suisini) Date: Thu, 14 Jan 2016 14:32:50 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: <1452691654.2609.47.camel@atmarama.com> References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> <1452691654.2609.47.camel@atmarama.com> Message-ID: Maybe just implement the python syntax (or a t lease a subset) in the cmake core , so no need extern dep and provide a clean/defined interface to be able to call complex external script is whatever languages. 2016-01-13 14:27 GMT+01:00 Sa?a Jani?ka : > On Sri, 2016-01-13 at 13:14 +0000, Charles Huet wrote: > > > I don't think this is a dumb question, actually this is part of the > > problem I think would be resolved whit a new language. > > > > The barrier of entry to using CMake is too high in my opinion, and I > > think using an existing language would lower it *a lot*. > > Personally I'm determinant to use CMake, mostly due to its maturity and > CPack's features, but recently stumbled upon Meson http://mesonbuild.com/ > ) > build system whose goal is "to be both extremely fast, and, even more > importantly, as user friendly as possible."...it also uses Ninja instead > of Make as backend. > > Otoh, I believe that main problem with CMake is lack of quality docs - > even > Mastering CMake book has constantly very bad reviews. > > Sincerely, > Gour > > > -- > One who sees inaction in action, and action in inaction, > is intelligent among men, and he is in the transcendental position, > although engaged in all sorts of activities. > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Thu Jan 14 08:46:07 2016 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 14 Jan 2016 05:46:07 -0800 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> <1452691654.2609.47.camel@atmarama.com> Message-ID: I am hesitant to add more fuel to the fire for this discussion because it has been discussed many times before through the years and my sense is that this isn?t what Brad is really interested in pursuing. I encourage you search the mailing list history. I?ll try to summarize (off the top of my head) about why Lua (as opposed to other languages). - Lua above all other languages was recommended by me and others because it satisfied all the constraints: - It is tiny and can be included with the CMake source and doesn?t impact the size of CMake in any significant way - Being 100% ANSI C allows it to go everywhere CMake already goes and satisfies the requirement that only a C++ compiler is needed to bootstrap it. - Lua is a language designed to be embedded, for this very kind of purpose. - Lua is sandboxed by default and has a minimal (and optional) standard library. - This means users won?t be encouraged to call all sorts of non-portable library calls like with some other languages. CMake can control what APIs are exposed addressing those concerns that a full programming language may allow too much variance and craziness in the community. - Lua?s liberal license is compatible with CMake?s liberal license. - Lua is one of the cleanest, simplest mainstream languages out there and is incredibly easy to learn, yet still supporting a wide range of higher-level constructs (functions as first class values, closures, proper tail recursion). Documentation and tutorials are readily available. - Lua?s core data structure is the table, which is a extremely similar to JSON (which it happens to also predate), which makes lists and declarative data style very easy and natural to do. - Lua has proven itself in the video game industry in that C/C++ developers are comfortable dealing with it (not a syntax shell shock to them, say like LISP, or quite frankly CMake) - Lua being a full, well designed programming language allows for ways to write things which is currently really hard in CMake?s language. Additionally, adding features to CMake?s language is hard in that you have to think about all the potential side-effects, edge cases, and inconsistencies. Lua takes this burden away and how to use everything is well known/documented. - To prove to us that CMake was already too far down the road and retrofitting Lua into CMake was not practical, Dr. Ken Martin had a CMake/Lua proof of concept working in like 13 hours. (Oops.) - But it was decided that Kitware didn?t want to go down this road. - We attempted to build off Ken Martin?s experiment to keep it alive, but that project essentially failed. - Lack of time, resources, expertise, etc, and this was back in the CVS days so keeping up with the mainline was hell since merge tracking is pretty much non-existent. - There was one interesting thing implemented showing that both existing CMake script and Lua script could co-exist. And I think there was even a proof a concept that different language scripts could call one another. So just on the constraints/requirements issue, I think we convinced Brad, that *if* anything should be chosen, it should be Lua, which is why Lua is still in his head. And these constraints are still in play. I am constantly fighting dependency hell on platforms. It is nice that CMake has no external dependencies except a C++ compiler and can bootstrap itself. I recently did a bunch of work on a Raspberry Pi and I needed to build CMake; no problem. I just tried to build Swift on the Pi. I got hit by a bug where the build process pulls in the wrong version of Python (2 vs 3) if both exist on the system. What a mess. (And a 9+ hour build cycle to retry.) Not to mention the disk space problem of needing all these dependencies. But it sounds like Brad is more interesting in a purely declarative replacement for CMake. That would be nice for all the editor-assist reasons. Though I?m also skeptical of pulling that off (though I hope it can be done in a useful way). There are other systems like that, yet, I?m using CMake for a reason. I don?t have any real insight on the problem, but I recall hacking Ant XML files and just to have a simple conditional (if/else) was a huge PITA. And as these things cascade with more conditionals, it becomes a major effort. Antidotally, I watched several projects try to use Gyp even though there was a CMake description already written (albeit, not working for the platforms we needed). I watched from the sidelines as those projects failed to get Gyp working. I don?t have any insight in why unfortunately. For one project though, I did later come in and did get the CMake description working. I try really hard to keep my CMake really simple. But unfortunately, it always gets complicated. Just the fact that platforms and environments are so different always impacts my CMake scripts. But I?m very glad that CMake seems to get the job done. Lua would help me avoid fighting the CMake language, and that would be very welcome. But I don?t expect the messiness to ever truly go away?that is the byproduct of systems/environments being so different and ever changing. From brad.king at kitware.com Thu Jan 14 08:48:52 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 14 Jan 2016 08:48:52 -0500 Subject: [cmake-developers] fixup_bundle with @loader_path In-Reply-To: References: Message-ID: <5697A744.4020002@kitware.com> On 01/13/2016 01:38 AM, Simon Wells wrote: > it kept saying that @loader_path/libboost_chrono-mt.dylib was not found It looks like this was now reported here with a patch: https://cmake.org/Bug/view.php?id=15918 We already handle @executable_path, so @loader_path should be handled in a similar way but we need to make sure enough information is passed to know the loader path. Clinton? Thanks, -Brad From charles.huet at gmail.com Thu Jan 14 09:11:39 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 14 Jan 2016 14:11:39 +0000 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> <1452691654.2609.47.camel@atmarama.com> Message-ID: Thanks for the insight ! I started going towards python because I am more familiar with it, but Lua seems to be a better fit for CMake now that I think about the constraints you listed. The main point I am getting from your mail is that Kitware may not want to go down this route, even if provided with a working prototype, with the ability of slow migration by using both CMake script and Lua. I understand that some users are against such a change (as pointed out in this very thread) but I'd be willing to contribute time and effort towards it, if given the assurance it would not be in vain. >I try really hard to keep my CMake really simple. But unfortunately, it always gets complicated. Just the fact that platforms and environments are so different always impacts my CMake scripts. But I?m very glad that CMake seems to get the job done. Lua would help me avoid fighting the CMake language, and that would be very welcome. But I don?t expect the messiness to ever truly go away?that is the byproduct of systems/environments being so different and ever changing. This perfectly sums up what I feel :) Le jeu. 14 janv. 2016 ? 14:46, Eric Wing a ?crit : > I am hesitant to add more fuel to the fire for this discussion because > it has been discussed many times before through the years and my sense > is that this isn?t what Brad is really interested in pursuing. I > encourage you search the mailing list history. > > I?ll try to summarize (off the top of my head) about why Lua (as > opposed to other languages). > > - Lua above all other languages was recommended by me and others > because it satisfied all the constraints: > - It is tiny and can be included with the CMake source and doesn?t > impact the size of CMake in any significant way > - Being 100% ANSI C allows it to go everywhere CMake already goes > and > satisfies the requirement that only a C++ compiler is needed to > bootstrap it. > - Lua is a language designed to be embedded, for this very kind of > purpose. > - Lua is sandboxed by default and has a minimal (and optional) > standard library. > - This means users won?t be encouraged to call all sorts of > non-portable library calls like with some other languages. CMake can > control what APIs are exposed addressing those concerns that a full > programming language may allow too much variance and craziness in the > community. > - Lua?s liberal license is compatible with CMake?s liberal license. > > - Lua is one of the cleanest, simplest mainstream languages out there > and is incredibly easy to learn, yet still supporting a wide range of > higher-level constructs (functions as first class values, closures, > proper tail recursion). Documentation and tutorials are readily > available. > - Lua?s core data structure is the table, which is a extremely similar > to JSON (which it happens to also predate), which makes lists and > declarative data style very easy and natural to do. > - Lua has proven itself in the video game industry in that C/C++ > developers are comfortable dealing with it (not a syntax shell shock > to them, say like LISP, or quite frankly CMake) > - Lua being a full, well designed programming language allows for ways > to write things which is currently really hard in CMake?s language. > Additionally, adding features to CMake?s language is hard in that you > have to think about all the potential side-effects, edge cases, and > inconsistencies. Lua takes this burden away and how to use everything > is well known/documented. > > - To prove to us that CMake was already too far down the road and > retrofitting Lua into CMake was not practical, Dr. Ken Martin had a > CMake/Lua proof of concept working in like 13 hours. (Oops.) > - But it was decided that Kitware didn?t want to go down this road. > > - We attempted to build off Ken Martin?s experiment to keep it alive, > but that project essentially failed. > - Lack of time, resources, expertise, etc, and this was back in the > CVS days so keeping up with the mainline was hell since merge tracking > is pretty much non-existent. > - There was one interesting thing implemented showing that both > existing CMake script and Lua script could co-exist. And I think there > was even a proof a concept that different language scripts could call > one another. > > > > So just on the constraints/requirements issue, I think we convinced > Brad, that *if* anything should be chosen, it should be Lua, which is > why Lua is still in his head. And these constraints are still in play. > I am constantly fighting dependency hell on platforms. It is nice that > CMake has no external dependencies except a C++ compiler and can > bootstrap itself. I recently did a bunch of work on a Raspberry Pi and > I needed to build CMake; no problem. I just tried to build Swift on > the Pi. I got hit by a bug where the build process pulls in the wrong > version of Python (2 vs 3) if both exist on the system. What a mess. > (And a 9+ hour build cycle to retry.) Not to mention the disk space > problem of needing all these dependencies. > > But it sounds like Brad is more interesting in a purely declarative > replacement for CMake. > That would be nice for all the editor-assist reasons. Though I?m also > skeptical of pulling that off (though I hope it can be done in a > useful way). There are other systems like that, yet, I?m using CMake > for a reason. I don?t have any real insight on the problem, but I > recall hacking Ant XML files and just to have a simple conditional > (if/else) was a huge PITA. And as these things cascade with more > conditionals, it becomes a major effort. Antidotally, I watched > several projects try to use Gyp even though there was a CMake > description already written (albeit, not working for the platforms we > needed). I watched from the sidelines as those projects failed to get > Gyp working. I don?t have any insight in why unfortunately. For one > project though, I did later come in and did get the CMake description > working. > > I try really hard to keep my CMake really simple. But unfortunately, > it always gets complicated. Just the fact that platforms and > environments are so different always impacts my CMake scripts. But I?m > very glad that CMake seems to get the job done. Lua would help me > avoid fighting the CMake language, and that would be very welcome. But > I don?t expect the messiness to ever truly go away?that is the > byproduct of systems/environments being so different and ever > changing. > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Thu Jan 14 10:11:51 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 14 Jan 2016 10:11:51 -0500 Subject: [cmake-developers] [CMake 0015919]: Building CUDA files fails when source path contains parenthesis Message-ID: <92ba9f6425404f37303a187881e14898@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15919 ====================================================================== Reported By: qiv Assigned To: ====================================================================== Project: CMake Issue ID: 15919 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-14 10:11 EST Last Modified: 2016-01-14 10:11 EST ====================================================================== Summary: Building CUDA files fails when source path contains parenthesis Description: When working in a source path containing "()" I get the following error upon building CUDA files: 15:13 sandbox$ make [ 6%] Building NVCC (Device) object CMakeFiles/githash.dir//./githash_generated_float3.cu.o /bin/sh: 1: Syntax error: "(" unexpected CMakeFiles/githash.dir/build.make:167: recipe for target 'CMakeFiles/githash.dir/./githash_generated_float3.cu.o' failed make[2]: *** [CMakeFiles/githash.dir/./githash_generated_float3.cu.o] Error 2 CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/githash.dir/all' failed make[1]: *** [CMakeFiles/githash.dir/all] Error 2 Makefile:76: recipe for target 'all' failed make: *** [all] Error 2 The following fix provided by ngladitz in #cmake solves the issue on my machine: diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake index ada5b8a..fe2647a 100644 --- a/Modules/FindCUDA.cmake +++ b/Modules/FindCUDA.cmake @@ -1474,6 +1474,7 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files) -P "${custom_target_script}" WORKING_DIRECTORY "${cuda_compile_intermediate_directory}" COMMENT "${cuda_build_comment_string}" + VERBATIM ) # Make sure the build system knows the file is generated. Steps to Reproduce: 16:06 sandbox$ cat CMakeLists.txt CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(githash) FIND_PACKAGE(CUDA REQUIRED) # FIND_PACKAGE(MPI REQUIRED) INCLUDE(FindCUDA) # INCLUDE_DIRECTORIES(/usr/local/cuda/include ${MPI_INCLUDE_PATH}) FILE(GLOB SOURCES "*.cu" "*.cpp" "*.c" "*.h") CUDA_ADD_EXECUTABLE(githash ${SOURCES}) LIST(APPEND CMAKE_CXX_FLAGS "-std=c++0x -O3 -ffast-math -Wall") LIST(APPEND CUDA_NVCC_FLAGS --compiler-options -fno-strict-aliasing -lineinfo -use_fast_math -Xptxas -dlcm=cg) # LIST(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_20,code=sm_20) LIST(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_30,code=sm_30) # LIST(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_35,code=sm_35) # TARGET_LINK_LIBRARIES(githash /usr/local/cuda/lib64/libcudart.so ${MPI_LIBRARIES}) 15:13 sandbox$ cmake . -- Configuring done -- Generating done -- Build files have been written to: /home/.../Dropbox (CRG)/.../sandbox ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-14 10:11 qiv New Issue ====================================================================== From mantis at public.kitware.com Thu Jan 14 10:32:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 14 Jan 2016 10:32:15 -0500 Subject: [cmake-developers] [CMake 0015920]: Tests fail Message-ID: <105de8ea2bcaf2dcbb6f0bffaa22ef12@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15920 ====================================================================== Reported By: R Jones Assigned To: ====================================================================== Project: CMake Issue ID: 15920 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-14 10:32 EST Last Modified: 2016-01-14 10:32 EST ====================================================================== Summary: Tests fail Description: 98% tests passed, 7 tests failed out of 410 Label Time Summary: Label1 = 0.35 sec (1 test) Label2 = 0.35 sec (1 test) Total Test time (real) = 4137.46 sec The following tests FAILED: 115 - BuildDepends (Failed) 173 - CTestTestUpload (Failed) 174 - CTestCoverageCollectGCOV (Failed) 193 - CMakeCommands.target_link_libraries (Failed) 223 - Fortran (Failed) 327 - RunCMake.ctest_submit (Failed) 372 - RunCMake.IfacePaths_INCLUDE_DIRECTORIES (Failed) Additional Information: What information is needed to diagnose these? These also fail on 3.3.1. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-14 10:32 R Jones New Issue ====================================================================== From brad.king at kitware.com Thu Jan 14 10:41:50 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 14 Jan 2016 10:41:50 -0500 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> <1452691654.2609.47.camel@atmarama.com> Message-ID: <5697C1BE.4010503@kitware.com> On 01/14/2016 09:11 AM, Charles Huet wrote: > Thanks for the insight ! [snip] > but Lua seems to be a better fit for CMake now that I think about the > constraints you listed. Yes, Eric, thanks for the excellent post summarizing the history of this issue and why Lua is a great candidate. > The main point I am getting from your mail is that Kitware may not > want to go down this route, even if provided with a working prototype, > with the ability of slow migration by using both CMake script and Lua. I'm not opposed to this in principle but it will be a huge change to the ecosystem and so cannot be taken lightly. FYI, CMake 3.0 introduced Lua-style bracket arguments (of the form "[[...]]") specifically to enable the possibility of embedding Lua code (or other content) inside CMake scripts without having to do any escaping. This could aid with incremental transitions. > I understand that some users are against such a change (as pointed out > in this very thread) but I'd be willing to contribute time and effort > towards it, if given the assurance it would not be in vain. I think the first step is design brainstorming and discussion to see if we can find something acceptable. IIRC one problem with earlier attempts at introducing Lua was that CMake's dynamic scoping is difficult to reconcile with Lua's lexical scoping. Lua cannot be given direct access to CMake variable scopes because Lua data structures may outlive the CMake dynamic scopes, leading to dangling references. I'd also prefer an approach that allows us to offer newer versions of Lua as they come out while still processing old scripts unchanged. This means that all Lua code must lie in a context where CMake knows the version of Lua for which it was written. I'd like to retain the possibility of supporting multiple Lua versions to allow future such version transitions. (Implementation symbols can be mangled to support multiple versions linked in one program.) I once designed the following CMake language command as a way to embed Lua inside CMake scripts while addressing both of the above concerns. I'm not necessarily proposing this, but it serves as an example approach: -------------------------------------------------------------------------- Usage: cmake_lua( [LOCAL ...] CODE ...) The must be "5.2", the Lua language version. Each specifies a Lua local variable with the form "var=type{value}" or "type{var}" (short for "var=type{${var}}") where "var" is the Lua identifier for the local and "type" determines how "value" is converted to Lua. Valid types are: string: value is stored directly in a Lua string. list: value is a ;-separated list of the form "a;b;c" to be stored in a Lua table of the form {'a','b','c'}. number: value is interpreted as a decimal representation of a floating point value to be stored in a Lua number. All arguments are concatenated into a Lua chunk with form " ... " where and are generated by CMake to provide s by unspecified means. The ... must return a single Lua table containing zero or more identifier keys to be set as CMake variables. Values must be convertible by the reverse of the above type mapping. Example: set(deg 90) cmake_lua(5.2 LOCAL number{deg} CODE [[ return { sin = math.sin(deg*math.pi) }]]) message("sin(${deg}') = ${sin}') -------------------------------------------------------------------------- Of course the above all assumes that Lua code may run simultaneously with CMake code during configuration. Other approaches that involve pure-Lua programs do not have the same scoping challenges (but would still have to deal with Lua versioning). >> But it sounds like Brad is more interesting in a purely declarative >> replacement for CMake. >> That would be nice for all the editor-assist reasons. Though I?m also >> skeptical of pulling that off (though I hope it can be done in a >> useful way). There are other systems like that, yet, I?m using CMake >> for a reason. I'm raising the declarative approach here because it is an important consideration. See the "CMake daemon for user tools" thread for discussion of how a declarative spec would greatly improve integration with IDEs and other tools: https://cmake.org/pipermail/cmake-developers/2016-January/027413.html A declarative spec allows tools to load and work with it easily. A JSON document with a schema is easy to load, edit, validate, and save, for example. A procedural specification must be executed to be interpreted, and only humans can really edit it. ======================================================================== Currently CMake language code is a program that runs to generate a build specification stored within CMake's implementation that is then used by the generators. Since the CMake language files (CMakeLists.txt) are procedural, projects can do all kinds of things like system introspection, configuring files, etc. before and after calling the commands like add_library, add_executable, and target_link_libraries that actually specify the build rules. The language was originally meant only for the latter part. In fact originally the commands were more declarative and did not have a defined order of execution. Then it grew into what it is now to support the other parts. Both the earlier attempt to use Lua that Eric mentioned and the Python approach proposed at the beginning of this thread follow the same approach just with another language. I think if we are going to go through the effort to change the status quo then we need to consider other weaknesses of the approach than just the language. These include the lack of a declarative (i.e. toolable) spec and the serial nature of the programs limiting possibility for parallel or partial evaluation. -Brad From rcdailey.lists at gmail.com Thu Jan 14 11:28:17 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 14 Jan 2016 10:28:17 -0600 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> References: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> Message-ID: On Wed, Jan 13, 2016 at 3:16 PM, Alexander Neundorf wrote: > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: >> Running version 3.2.2 on Ubuntu 15. I run the following command: >> >> $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 >> -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config >> -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake" > > are you sure you actually want to use the KDevelop3 generator ? > This is for the KDE3 version, and you are probably using the KDE4 version of > KDevelop ? For that you don't need these generated project files. > > Actually I was thinking about removing this generator, because KDevelop3 is > really really old, not sure whether it is still available in current Linux > distributions. This might explain it. I just installed kdevelop on Ubuntu 15, not sure what version it is using. I also have never used kdevelop before so I was not aware that it had built in support for CMake. I saw it in the list of generators so I naturally assumed I had to use it. Note that Eclipse is in kind of the same boat, as far as which versions it supports and its not immediately obvious. From clinton at elemtech.com Thu Jan 14 13:26:44 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 14 Jan 2016 11:26:44 -0700 (MST) Subject: [cmake-developers] fixup_bundle with @loader_path In-Reply-To: <5697A744.4020002@kitware.com> References: <5697A744.4020002@kitware.com> Message-ID: <1388770192.12590982.1452796004618.JavaMail.zimbra@elemtech.com> ----- On Jan 14, 2016, at 6:48 AM, Brad King brad.king at kitware.com wrote: > On 01/13/2016 01:38 AM, Simon Wells wrote: >> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found > > It looks like this was now reported here with a patch: > > https://cmake.org/Bug/view.php?id=15918 > > We already handle @executable_path, so @loader_path should be handled in > a similar way but we need to make sure enough information is passed to > know the loader path. > As far as I know, the information needed is already available, so my initial guess is that we don't need any significant re-engineering. Simon, Would you happen to have a simple example showing the problem without boost, that would be easy to replicate? That could become the basis for a test. Clint From brad.king at kitware.com Thu Jan 14 13:56:04 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 14 Jan 2016 13:56:04 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> Message-ID: <5697EF44.60001@kitware.com> On 01/13/2016 06:17 PM, Eric Wing wrote: > Under the hood, I think the LLVM linker can handle all of these > through ld. But I think the thing that is tripping me up is that Swift > seems to need to link against some additional libraries which are not > needed in the pure C case. The swiftc command seems to know how to > automatically link in those extra dependencies (and I don't need to > add all the search paths to where the Swift core libraries are > located). That is the same as for C++. See CMAKE_PARSE_IMPLICIT_LINK_INFO and the call to it in "Modules/CMakeDetermineCompilerABI.cmake". That is responsible for extracting the implicit link information passed by a given language compiler's front-end. We'll need to extract that for Swift. > Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same > as Java). But it didn't seem to do anything for me. Where did you add the code to set it? > I just tried not filtering the current primary file from the list. It > still worked. So maybe we can get away with not filtering that. Great. It will be simplest to list all the sources in every call and then repeat the one that is current. > Anyway, it seems like adding SOURCES is the next step. Any hints on > how to do that? The cmLocalGenerator::ExpandRuleVariable method does the placeholder substitution. It relies on values in the RuleVariables structure to be populated by the calling generator. The Makefile generator populates that for the compile line here: cmMakefileTargetGenerator::WriteObjectBuildFile and the Ninja generator here: cmNinjaTargetGenerator::WriteCompileRule cmNinjaTargetGenerator::WriteObjectBuildStatement Note that for Ninja we actually convert our placeholders to Ninja rule placeholders and then provide the values on the actual build statement line. You should be able to call this->GeneratorTarget->GetObjectSources(objectSources, config); to get the list of source files and then filter it based on sf->GetLanguage(). The name "" is not very good because it does not specify how any filtering is done. Perhaps a special case name such as "" would be better. Do we know that there is a one-to-one mapping between libraries and Swift modules? -Brad From kfunk at kde.org Thu Jan 14 15:31:51 2016 From: kfunk at kde.org (Kevin Funk) Date: Thu, 14 Jan 2016 21:31:51 +0100 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> References: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> Message-ID: <6807116.THnBlI3QFq@kerberos> On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote: > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > > Running version 3.2.2 on Ubuntu 15. I run the following command: > > > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 > > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config > > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake" > > are you sure you actually want to use the KDevelop3 generator ? > This is for the KDE3 version, and you are probably using the KDE4 version of > KDevelop ? For that you don't need these generated project files. > > Actually I was thinking about removing this generator, because KDevelop3 is > really really old, not sure whether it is still available in current Linux > distributions. > > Alex +1 from my side, KDevelop 3 is super ancient (last release around 2008 according to the interwebs). Get rid off the generator. Cheers, Kevin -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From neundorf at kde.org Thu Jan 14 15:38:24 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 14 Jan 2016 21:38:24 +0100 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: <6807116.THnBlI3QFq@kerberos> References: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> <6807116.THnBlI3QFq@kerberos> Message-ID: <9499674.BuZYg62jfg@tuxedo.neundorf.net> On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote: > On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote: > > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > > > Running version 3.2.2 on Ubuntu 15. I run the following command: > > > > > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 > > > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config > > > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake" > > > > are you sure you actually want to use the KDevelop3 generator ? > > This is for the KDE3 version, and you are probably using the KDE4 version > > of KDevelop ? For that you don't need these generated project files. > > > > Actually I was thinking about removing this generator, because KDevelop3 > > is > > really really old, not sure whether it is still available in current Linux > > distributions. > > > > Alex > > +1 from my side, KDevelop 3 is super ancient (last release around 2008 > according to the interwebs). Get rid off the generator. Brad, what's your opinion on this ? Removing this is something I could do :-) Alex From brad.king at kitware.com Thu Jan 14 15:41:06 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 14 Jan 2016 15:41:06 -0500 Subject: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu In-Reply-To: <9499674.BuZYg62jfg@tuxedo.neundorf.net> References: <4327794.BQN6O7JsmN@tuxedo.neundorf.net> <6807116.THnBlI3QFq@kerberos> <9499674.BuZYg62jfg@tuxedo.neundorf.net> Message-ID: <569807E2.5070209@kitware.com> On 01/14/2016 03:38 PM, Alexander Neundorf wrote: > On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote: >> +1 from my side, KDevelop 3 is super ancient (last release around 2008 >> according to the interwebs). Get rid off the generator. > > Brad, what's your opinion on this ? > Removing this is something I could do :-) Sounds good to me. For compatibility we should continue to support the generator name and have it simply not create an extra generator (and instead warn that it no longer creates one). It can be dropped from the documentation though. Please include a Help/release/dev/*.rst file with a release note about the removal. Thanks, -Brad From tamas.kenez at gmail.com Thu Jan 14 15:48:35 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 14 Jan 2016 21:48:35 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: Looking at what kind of mistakes the newcomers make, I think it's rather the global workflow and the roles of certain key variables/properties they don't get. At first their problem is not that they can't make a for-loop or increment a variable. It's that they don't understand how the build and install phases relate to each other, how to organise the files and targets of a multi-target project, how to connect two projects. These would be just as difficult to grasp in Python or Lua as it is in CMake-script. I support replacing the CMake language but in order to lower the barrier I think 10-20 nice, minimal sample projects would be more important. Tamas On Wed, Jan 13, 2016 at 2:14 PM, Charles Huet wrote: > I don't think this is a dumb question, actually this is part of the > problem I think would be resolved whit a new language. > > The barrier of entry to using CMake is too high in my opinion, and I think > using an existing language would lower it *a lot*. > > Thanks for sharing :) > > > Le mer. 13 janv. 2016 ? 10:59, yann suisini a > ?crit : > >> Hi, >> >> I'm a new user of CMake, but I just want to express my newcomer point of >> view. >> Honestly , I can feel the power of CMAKE, but it's a real pain to learn >> ... >> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at >> the end the CMAKE description is longer than the one I built directly in >> Ninja. >> I had to write a python script to parse my eclipse project xml to create >> a list of sources files usable by CMAKE. >> The first thing I thought was: why this is not a part of cmake ? And the >> second thing was : why not using the scripting power of an existing >> language like Python(or other one) >> and add CMAKE as a framework / library ? >> Probably a dumb question ! :) >> >> Yann >> >> 2016-01-13 10:34 GMT+01:00 Charles Huet : >> >>> Hi, >>> >>> > * There is a lot of code out there in the current CMake language so I >>> do not >>> think it is realistic to drop it. I'm not proposing that this change. >>> >>> I am. (more below) >>> >>> > * Many projects build elaborate macro/function systems in the CMake >>> language >>> in order to end up with a declarative specification listing the actual >>> source files, dependencies, and usage requirements. I'd like to offer >>> an alternative to this. >>> >>> In my experience, most of the elaborate macros/functions come either >>> from a misunderstanding of some of CMake's internals (scope, link >>> debug/release libs, etc) or to circumvent some shortcoming of the CMake >>> language (e.g. no return value for functions). >>> >>> > I'd like to improve this by *optionally* moving part of the >>> specification >>> to a (stateless) declarative format that IDEs can load/edit/save >>> directly >>> >>> Split the buildsystem in two different languages ? Would the declarative >>> part be in a different file ? >>> Also, the declarative part in my opinion must take advantage of the >>> language. >>> For instance, add a source file only for WIN32 systems should be easy in >>> said declarative format. >>> Using a custom language (based on JSON for instance) would mean to add >>> conditionals, which comes back to making a custom language again. >>> >>> >>> To come back to my first point, I understand completely that this would >>> be a tremendous change, and the transition would be difficult to say the >>> least. But I think it would be more than worth it in the long term. >>> >>> > The moment you make CMake scriptable in more than one language, you >>> are forcing >>> > every CMake user to learn that additional language because sooner or >>> later he >>> > will step into a third-party that is using that additional language. >>> >>> What I have in mind is to deprecate the current CMake language and >>> replace it with another language. So there would be a transition period, >>> but in the end there would only be one language again, and a better one. >>> >>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake >>> would not need learn a new language (or at least learn one that has many >>> resources, and can be used for other purposes). >>> Old-timers would have to learn a new language (or maybe not, most >>> programmers I know have played a bit with python to automate simple tasks), >>> but this would be easier than learning CMake was, since there are >>> established rules and a more consistent design to it. >>> >>> Of course I'm not saying this should happen overnight, nor am I saying >>> this *must* happen, but I think discussing it can only be beneficial. >>> >>> I've seen lots of people wonder how to make their CMake scripts more >>> efficient, and currently this is a very difficult thing to do, since there >>> is no profiling possible. >>> And who can say they never spent way too much time trying to understand >>> why a variable was not correctly initialized ? When the configure step >>> takes about 30 seconds, and all you can do is use MESSAGE() to find what >>> happens, this is no walk in the park. A real debugger would do a world of >>> good to CMake. >>> I have seen some hardly understandable CMake code, and only thanks to >>> the git history was I able to understand that the person who wrote the >>> script completely misunderstood the CMake language. >>> >>> >As discussed above if some kind of callback or user-coded function >>> needs to >>> be included for advanced usage of the declarative spec then we would need >>> a language for it. The current CMake language is not well suited to that >>> use case (e.g. no expressions or return values), so an existing >>> alternative >>> language should be chosen. >>> >>> >CMake's current "generator expressions" fill this role somewhat now and >>> are >>> essentially a sub-language. As with the main language they grew out of >>> something not intended to serve their current full role. They could be >>> superseded by a common alternative generate-time language too. >>> >>> These points are part of the reason I think a new language should be >>> used, if it can cover all of these issues. I'd rather not see a new CMake >>> declarative language that might itself grow out and become something >>> difficult to grasp. >>> Something like generator expressions could be expressed in a language >>> such as python or lua, by using objects that get resolved at generate time >>> (or functions, or whatever). >>> >>> >>> Cheers >>> >>> Le lun. 11 janv. 2016 ? 21:53, Brad King a >>> ?crit : >>> >>>> Hi Folks, >>>> >>>> I'm replying directly to my previous post in this thread in order to >>>> consolidate >>>> responses to related discussion raised in others' responses to it: >>>> >>>> >>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383 >>>> >>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386 >>>> >>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389 >>>> >>>> General comments: >>>> >>>> * There is a lot of code out there in the current CMake language so I >>>> do not >>>> think it is realistic to drop it. I'm not proposing that this change. >>>> >>>> * CMake's procedural/imperative design is good as the main entry point >>>> to >>>> configuration of a project. It can do system introspection, file >>>> generation, >>>> etc. I'm not proposing that this change. >>>> >>>> * Many projects build elaborate macro/function systems in the CMake >>>> language >>>> in order to end up with a declarative specification listing the actual >>>> source files, dependencies, and usage requirements. I'd like to offer >>>> an alternative to this. >>>> >>>> * Integration with IDEs is currently based on one-way generation (VS IDE >>>> projects, Xcode projects, CodeBlocks, etc.). Editing the project >>>> build >>>> specification requires editing CMake code directly because IDEs cannot >>>> easily pierce CMake's procedural/imperative specification: >>>> >>>> >>>> https://cmake.org/pipermail/cmake-developers/2016-January/027386.html >>>> >>>> I'd like to improve this by *optionally* moving part of the >>>> specification >>>> to a (stateless) declarative format that IDEs can load/edit/save >>>> directly. >>>> >>>> Specific responses follow. >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> On 01/11/2016 12:24 PM, Charles Huet wrote: >>>> > I think these goals aim towards a faster configure, and the ability to >>>> > only partly reconfigure, right? >>>> >>>> Yes. >>>> >>>> > I know I am largely biased by the project I work on, but I do not see >>>> how >>>> > parallel evaluation woud be a huge benefit. >>>> [snip] >>>> > And how would that work with CMakeLists that affect their parent >>>> scope ? >>>> >>>> Evaluation of the imperative language is currently serial for reasons >>>> like >>>> this, which is why I said it would take semantic changes to enable >>>> parallel >>>> evaluation. This is not the main point of my proposal so I'd rather not >>>> get bogged down in the details of this part of the discussion. >>>> >>>> >> Ideally most of the specification (sources, libraries, executables, >>>> etc.) >>>> >> should be in a pure format that can be evaluated without side >>>> effects (e.g. >>>> >> declarative or functional). >>>> > >>>> > I'm not sure I understand how this could be done without losing a lot >>>> of >>>> > what CMake offers, such as copying or generating files. >>>> >>>> I'm not proposing dropping the current imperative capabilities. >>>> >>>> > I'm leaning towards a declarative approach as it is quite easy to >>>> learn >>>> > (since you declare objects, and every C++ programmer I know is >>>> familiar >>>> > with those) >>>> >>>> Yes. >>>> >>>> > It seems you are leaning towards pure functional, but I do not see how >>>> > this would work with the current way CMake handles variables and >>>> scope, >>>> > could you elaborate ? >>>> >>>> While declarative may get us most of the way, advanced users may wish to >>>> hook in to generation-time evaluation. A clean way to do that would be >>>> to specify a function within the declared values. It would not have to >>>> be in a functional language as long as it has no access to anything >>>> other >>>> than the inputs passed to it during evaluation. >>>> >>>> I mentioned "functional" mostly as an example of a specification whose >>>> evaluation is free of side effects. >>>> >>>> > To clarify, only the following lines should be considered when >>>> looking at the POC. >>>> >> myProject=cmake.Project("MyTestProject") >>>> >> >>>> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])] >>>> >>>> Yes, this is the kind of stuff that can be in a declarative format. >>>> >>>> > It seems you have in mind to write a new CMake language. >>>> >>>> No, at most a new specification format that can be used for IDE >>>> integration. >>>> If some kind of user-coded function were included in the specification >>>> it >>>> should certainly be in an existing language. >>>> >>>> > Maybe I should take my POC further >>>> >>>> I think implementation even of a POC is premature at this point. We >>>> should explore the design space further. >>>> >>>> > CMake's own buildsystem seems like a good testing ground for this, but >>>> > it is a little too big for a first go, do you know of a small >>>> CMake-based >>>> > project that would be better suited ? >>>> >>>> Maybe you could find something in our test suite. >>>> >>>> > I don't have a clear view of what a pure functional CMake would look >>>> like, >>>> > but if you give me some mock code, I could give a try at bringing >>>> some pure >>>> > functional language up to the level of my POC and we could use it as >>>> a more >>>> > concrete discussion support. >>>> >>>> I have no prototype (nor substantial time to spend on design myself) but >>>> I've imagined a declarative format in a well-known syntax (e.g. JSON or >>>> one >>>> of the lightweight human-friendly choices). If generate-time >>>> functionality >>>> is needed then code snippets in e.g. Lua could be included. >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> Petr Kmoch wrote: >>>> > I'd like to voice my opinion as a somewhat advanced CMake user here. >>>> >>>> Thanks for joining the discussion with this point of view. >>>> >>>> > For me, one of the strongest points of CMake is the fact that its >>>> project >>>> > specification is procedural rather than declarative. >>>> >>>> Good. We will not be dropping imperative capabilities. >>>> >>>> > end result of our framework is that the CMakeLists consist mostly of >>>> > declarative commands from our framework >>>> >>>> Yes, many projects have such frameworks. Most of them result in a >>>> declarative spec inside calls to their macros/functions. I'd like to >>>> formalize such specs in a re-usable way. >>>> >>>> > If I understand Brad's suggestion correctly, it would amount to a >>>> > (possibly empty) procedural step being used to generate a declarative >>>> > description of the buildsystem. >>>> >>>> Not quite. Yes, the procedural/imperative part would still be the entry >>>> point as it is now. However, the declarative part would also be an >>>> input, not an output. The procedural part's role would be to compute >>>> *parameters* to be used for the evaluation of the declarative spec. >>>> >>>> For example, imagine the declarative spec somehow encodes that source >>>> file "foo.c" is optional based on some condition "FOO". The value of >>>> that condition could be computed by the procedural part of the process >>>> based on system introspection, command-line options, etc., and then >>>> provided to CMake for use in the final evaluation. >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> On 01/11/2016 01:21 PM, Pau Garcia i Quiles wrote: >>>> > The moment you make CMake scriptable in more than one language, you >>>> are forcing >>>> > every CMake user to learn that additional language because sooner or >>>> later he >>>> > will step into a third-party that is using that additional language. >>>> >>>> I don't think the main "entry point" language should be selectable. >>>> >>>> As discussed above if some kind of callback or user-coded function >>>> needs to >>>> be included for advanced usage of the declarative spec then we would >>>> need >>>> a language for it. The current CMake language is not well suited to >>>> that >>>> use case (e.g. no expressions or return values), so an existing >>>> alternative >>>> language should be chosen. >>>> >>>> CMake's current "generator expressions" fill this role somewhat now and >>>> are >>>> essentially a sub-language. As with the main language they grew out of >>>> something not intended to serve their current full role. They could be >>>> superseded by a common alternative generate-time language too. >>>> >>>> > Also, declarative? Why? >>>> >>>> See above. >>>> >>>> > There are already a few declarative build systems >>>> >>>> Yes, and perhaps we can learn from their formats for the proposed >>>> declarative >>>> part. >>>> >>>> > qbs, one of the reasons for its existence was CMake was not >>>> declarative >>>> >>>> IIUC that is exactly because of the fact that an imperative spec cannot >>>> be pierced easily for editing in IDEs. >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> Thanks all for the discussion so far! >>>> >>>> -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 >>>> >>> >>> -- >>> >>> 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 >>> >> >> > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Thu Jan 14 16:12:49 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 14 Jan 2016 22:12:49 +0100 Subject: [cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug Message-ID: It seems that the names of the PRIVATE dependencies of a library are not affected by either the NAMESPACE option or the EXPORT_NAME property. A minimal example: add_library(one STATIC ...) add_library(two STATIC ...) target_link_libraries(two PRIVATE one) install(TARGETS one two EXPORT targets DESTINATION lib) install(EXPORT targets NAMESPACE ns:: DESTINATION cmake) The generated `targets.cmake` describes the dependency relation with: set_target_properties(ns::two PROPERTIES INTERFACE_LINK_LIBRARIES "\$" ) That is, it uses `one` instead of `ns::one`. Changing the EXPORT_NAME of `one` has no effect either. It works find if I replace PRIVATE with PUBLIC or INTERFACE (of course there'll be no more LINK_ONLY genexp in that case). Is this really a bug or did I miss something? I also searched Mantis and haven't found anything related. Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Jan 14 17:06:57 2016 From: d3ck0r at gmail.com (J Decker) Date: Thu, 14 Jan 2016 14:06:57 -0800 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: My stumbling blocks are the use of keywords instead of operators... if( Something == ${SomeOtherThing} ) vs if( Something STREQUAL ${SomeOtherTHing} ) It might be nice if the operator '=' could be used in addition to the function SET() SET( a something ) becomes A = something Was gong to say 'I understand that it would be difficult' but ... not really, if the first word isn't a 'keyword' (Function/Macro name) then if the next token is a = instead of a ( then assume it's a SET .... ----- Re: "no return values for functions" that's not true... this script sets the return value just fine... --- cmake_minimum_required( VERSION 3.0 ) macro( SomeFunc ReturnVal ) set( ${ReturnVal} SomeResult ) endmacro( SomeFunc ) SomeFunc( RetVal ) message( "and we have a result of " ${RetVal} ) ---- output : and we have a result of SomeResult ------------- J/K : I think the alternative language should be LISP; oh wait that's already what it is. other than the function is outside of the parens One of the last comments mentioned something about.... the named parameters passed to methods like SET_TARGET_PROPERTIES(${project} PROPERTIES FOLDER utils COMPILE_DEFINTIIONS "SomeOtherSyms" ) Is at first a little confusing... but at least I don't have some required order where I have to isnert a bunch of blank ',,,,,,' to get to the option I want to use. It might be nice if there were methods to define your own syntax for these things for use in passing options to MACRO where as you iterate through the ARGN members it can trigger some sort of state table lookup/dispatch... but then I really don't have a use for such a thing in the reality of switching to cmake maybe 5 years ago. Re: Profile-ability of CMake. I haven't yet found anywhere that I would blame any part of the build process slowness on CMAKE, but rather on the build tools themselves (CygWin or MinGW for instances). Although... there is One project I often rebuild (OpenAL) which uses a bunch of CHECK_FUNCTION_EXISTS(snprintf HAVE_SNPRINTF) which seems to be pretty slow. But Really, I think the target rules would be better to test CMAKE_COMPILER_IS_ and WIN32/UNIX variables to get that result. There's certainly less permutations to test that way than testing for each function that might exist; since the variations are limited to environments (each generator) with perhaps a minor off case for some toolchains. But I guess that was put in to satisy autotool people coming to a different build system. From steveire at gmail.com Thu Jan 14 17:23:58 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 14 Jan 2016 23:23:58 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <56951624.1040302@kitware.com> <569653F3.1010100@kitware.com> Message-ID: Brad King wrote: > I think the responses in this thread have indicated there is interest > in working toward the full daemon approach. Perhaps discussion should > now proceed on the daemon protocol design over in the thread Tobias > started on cmake-developers: > > cmake daemon mode protocol > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15424 Yes, let's assume that anyone interested in this topic is now subscribed to the cmake mailing list use that thread which does not include the other mailing lists. Thanks, Steve. From steveire at gmail.com Thu Jan 14 17:53:56 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 14 Jan 2016 23:53:56 +0100 Subject: [cmake-developers] CMake alternative language References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> Message-ID: Charles Huet wrote: > When the configure step takes > about 30 seconds, and all you can do is use MESSAGE() to find what > happens, this is no walk in the park. A real debugger would do a world of > good to CMake. This is one of the things that I address with the daemon work - a 'recording' is made during the configure step which can then be inspected. Thanks, Steve. From jeanmichael.celerier at gmail.com Thu Jan 14 18:09:36 2016 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 15 Jan 2016 00:09:36 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: The problem is doing : list(LENGTH MyList NumList) math(EXPR MaxItList ${NumList}-1) foreach(i RANGE ${MaxItList}) list(GET MyOtherListOfSameSizeThanMyList ${i} Element) foobazify(${Element}) endforeach() instead of : for i in range(0, MyList.size): foobazifiy(MyOtherListOfSameSizeThanMyList[i]) On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet wrote: > As long as CMake embeds everything that is required, I don't see the > additional pain (since this is what it already does with the CMake > language). > > > Le jeu. 14 janv. 2016 ? 13:35, Jean-Micha?l Celerier < > jeanmichael.celerier at gmail.com> a ?crit : > >> >> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf >> wrote: >> >>> >>> My personal opinion: if the full power of python would be available, the >>> build >>> scripts would quickly turn into real programs, because programmers would >>> be >>> tempted to do so if all of python would be available. Then developers >>> would >>> have to understand two programs: the program itself, and the "build >>> program". >> >> >> The problem is when you have to do a real program for your build system >> anyways (which occurs one day or another for any large enough project I >> guess). >> Currently it's a real pain (but it'd be even more painful to have to ship >> Python / Bash / $script_language as part of your build system). >> -- >> >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Thu Jan 14 18:38:11 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 15 Jan 2016 00:38:11 +0100 Subject: [cmake-developers] cmake daemon mode protocol References: Message-ID: Tobias Hunger wrote: > Hi Stephen, > > I have successfully build and run your cmake server mode changes and > the python client script does work as advertised. Thanks for doing that! > I do have a couple of remarks about it. This is more intended as a > starting point for discussion as a real proposal. Would something > along these lines be possible: > * Start daemon-mode without any additional parameters > > * Daemon responds with " > { > "type": "handShake", > "version": "3.5.x", > "supportedProtocols": "3.5" > } As you discovered, the cmake binary might not even support the daemon mode at all. I think what you are really asking for is 'the capabilities of the cmake binary'. In that sense, you might also want to know what generators are available, whether daemon mode is available (and with which protocol versions) etc. The issue at http://public.kitware.com/Bug/view.php?id=15462 proposes to dump that information to stdout with a different -E command. > > * Client Handshake: > { > "type": "handshake", > "requestProtocolVersion": "3.5" > } > > * Daemon: > { > "type:"handshake", > "protocolVersion": "3.5" > } Something like this is possible too. It's not far off what is already done in the branch. > > At this point the normal operation should be possible. > > * Client: > { > "type": "setProjectInformation", > "sourceDirectory": "/some/path", > "cookie": "1" > } > > Being able to set the source directory is important so that a fresh > checkout can be configured. There is no build directory available at > that time... I understand the desire to inspect a cmake project without asking the user to specify a build dir, but cmake has to write build files somewhere in order to test the compiler etc. For this case, I suggest that if the user tries to 'open the source directory', you would use QTemporaryDir to build in a temporary location and run the daemon there. I believe clion does something equivalent to that. Is that viable? I suppose you are suggesting that cmake do that instead of leaving it for clients to do? > * Daemon should do progress handling while reading the CMakeLists.txt > or whatever it does: > { "type": "progress", "state": "busy", "task": "someId", > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" } > > * Daemon sends occasional: > { "type": "progress", "task": "someId", progressTotal: 25, > progressCurrent: 12, "cookie": "1" } Yes. CMake can provide approximate values of how complete the configure step is. See cmGlobalGenerator::AddMakefile. That could be exposed to the daemon 'somehow', such as by defining some virtual callback interface. Richer information about some semantics like 'task' and 'busy state' could also be provided in a similar way I expect, assuming those could be defined. > * Finally Daemon responds sends data as that is available now. > { > "type": "projectInformation", > "sourceDirectory": "/some/path", > "buildDirectory": "", > "projectName": "SomeProject", > "cookie": "1" > } At this point in your proposal, cmake has run the configure step in a temporary directory, right? So it would be "buildDirectory": "/tmp/foo/bar" right? > * Client: > { > "type": "setProjectInformation", > "buildDirectory": "/some/other/path", > "cookie": "2" > } As this sets a new build directory, cmake will have to run the configure step from scratch in this new location. > * Daemon does progress indication as above... > > * Daemon responds with project info: > { > "type": "progressInformation", > "sourceDirectory": "/some/path", > "buildDirectory": "/some/other/path", > "projectName": "SomeProject", > "cookie": "2" > } I must admit I'm not seduced by this idea as it seems to be that it should be easy for an IDE to build in a temporary dir itself. However, I think it makes sense to design the protocol to handle specifying either a sourceDir or a buildDir (or both if from scratch). Starting daemon mode without arguments as you suggest could work (though we would have to see how that affects the protocol). Or with a different argument (eg cmake -E daemon buildDir cmake -E daemon_source sourceDir ) could work. I am also just brainstorming ideas, not proscribing anything. > We might also want a "ping"/"pong" to detect if the daemon is still > responding. Yes, I had the same thought. I also considered self-terminating the daemon if there is no message on the wire for N seconds, effectively requiring the IDE to ping every N seconds if it is not doing anything else. I considered this because otherwise the IDE might crash and leave zombie cmake daemons running, but I didn't investigate that possibility. > That would require the daemon to be able to handle > multiple requests to be in flight... not sure that this is worth it. Yes, adding a multi-threading requirement to the daemon might make some implementation more difficult. I've seen some videos on designs for things like that though, and I am interested in trying them out. > But if we can not do that, then we need to provide constant progress > information, which is also not great:-) The good news is that after the initial configure and compute steps are finished (where progress makes sense anyway I think), all other requests are 'very fast'. > Not sure about the need for cookies (text set by the client and > repeated by the server in all its replies to that request). I do think > having them makes sense, even when only one request can be active at > any time: They make it so much easier to sanity-check communication. Yes, I considered something like that in the protocol too. I didn't add any because I didn't encounter the need yet in the parts of the protocol I implemented and the proof-of-concept tooling I made, so I deferred that part of the design space until a time when more requirements are known. > Consistently having a "type" in all messages going back and forth is > probably a good idea for the same reason as having cookies. Yep. Thanks for this useful feedback! Steve. From shawn.waldon at kitware.com Thu Jan 14 18:48:59 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 14 Jan 2016 18:48:59 -0500 Subject: [cmake-developers] Git for windows patch Message-ID: Hi, Recently I had to build a project on windows whose build required git. And even though I had installed git from here [1] in the default location, I had to tell CMake where to find it every time I did a build in a clean build tree. So here is a patch that tells CMake to look in the default install location for Git for Windows [2] when asked for git. I have tested it on my windows machine and it works there. Shawn [1]: https://git-for-windows.github.io/ [2]: C:\Program Files\Git\bin\git.exe ('Program Files (x86)' for older versions or 32 bit systems) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-git-add-search-paths-for-default-git-for-windows-ins.patch Type: text/x-patch Size: 1090 bytes Desc: not available URL: From d3ck0r at gmail.com Thu Jan 14 19:28:07 2016 From: d3ck0r at gmail.com (J Decker) Date: Thu, 14 Jan 2016 16:28:07 -0800 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: On Thu, Jan 14, 2016 at 3:09 PM, Jean-Micha?l Celerier wrote: > The problem is doing : > > list(LENGTH MyList NumList) > math(EXPR MaxItList ${NumList}-1) > > foreach(i RANGE ${MaxItList}) > list(GET MyOtherListOfSameSizeThanMyList ${i} Element) > foobazify(${Element}) > endforeach() > Probably a bad exmple, since you're not using MyList or i that simplifies to.... foreach( Element ${MyOtherListOfSameSizeThanMylist} ) foobazify( ${Element} ) endforeach() > instead of : > > for i in range(0, MyList.size): > foobazifiy(MyOtherListOfSameSizeThanMyList[i]) > > > > > > On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet > wrote: >> >> As long as CMake embeds everything that is required, I don't see the >> additional pain (since this is what it already does with the CMake >> language). >> >> >> Le jeu. 14 janv. 2016 ? 13:35, Jean-Micha?l Celerier >> a ?crit : >>> >>> >>> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf >>> wrote: >>>> >>>> >>>> My personal opinion: if the full power of python would be available, the >>>> build >>>> scripts would quickly turn into real programs, because programmers would >>>> be >>>> tempted to do so if all of python would be available. Then developers >>>> would >>>> have to understand two programs: the program itself, and the "build >>>> program". >>> >>> >>> The problem is when you have to do a real program for your build system >>> anyways (which occurs one day or another for any large enough project I >>> guess). >>> Currently it's a real pain (but it'd be even more painful to have to ship >>> Python / Bash / $script_language as part of your build system). >>> -- >>> >>> 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 > > > > -- > > 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 From konstantin at podsvirov.pro Thu Jan 14 22:42:36 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 15 Jan 2016 06:42:36 +0300 Subject: [cmake-developers] Git for windows patch In-Reply-To: References: Message-ID: <213111452829356@web10j.yandex.ru> Hi, Shawn! I am using CMake and Git on the Windows. As an IDE I use Qt Creator. My experience is that on Windows you need to use: "C:\Program Files [(x86)]\Git\cmd\git.exe" If you use your proposed way, I'm having problems work with Git in my project. It seems to me that this decision is necessary to discuss here. Dear list, does anyone have experience and recommendations? 15.01.2016, 02:49, "Shawn Waldon" : > Hi, > > Recently I had to build a project on windows whose required build git. And even though I had installed git from here [1] in the default location, I had to tell CMake where to find it every time I did a build in a clean build tree. So here is a patch that tells CMake to look in the default install location for Git for Windows [2] when asked for git. I have tested it on my windows machine and it works there. > > Shawn > > [1]: https://git-for-windows.github.io/ > [2]: C:\Program Files\Git\bin\git.exe ('Program Files (x86)' for older versions or 32 bit systems) > ,-- > > 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 Regards, Konstantin Podsvirov From jeanmichael.celerier at gmail.com Fri Jan 15 03:23:45 2016 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 15 Jan 2016 09:23:45 +0100 Subject: [cmake-developers] CMake alternative language In-Reply-To: References: <1509633.2oM98exVdc@tuxedo.neundorf.net> Message-ID: Throw in a > list(GET MyList ${i} ElementA) > list(GET MyOtherListOfSameSizeThanMyList ${i} ElementB) > foobazify(${ElementA} ${ElementB}) (I did not want to put a ginormous code snippet, just to outline the amount of code necessary to do simple things) On Fri, Jan 15, 2016 at 1:28 AM, J Decker wrote: > On Thu, Jan 14, 2016 at 3:09 PM, Jean-Micha?l Celerier > wrote: > > The problem is doing : > > > > list(LENGTH MyList NumList) > > math(EXPR MaxItList ${NumList}-1) > > > > foreach(i RANGE ${MaxItList}) > > list(GET MyOtherListOfSameSizeThanMyList ${i} Element) > > foobazify(${Element}) > > endforeach() > > > Probably a bad exmple, since you're not using MyList or i that simplifies > to.... > > foreach( Element ${MyOtherListOfSameSizeThanMylist} ) > foobazify( ${Element} ) > endforeach() > > > instead of : > > > > for i in range(0, MyList.size): > > foobazifiy(MyOtherListOfSameSizeThanMyList[i]) > > > > > > > > > > > > On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet > > wrote: > >> > >> As long as CMake embeds everything that is required, I don't see the > >> additional pain (since this is what it already does with the CMake > >> language). > >> > >> > >> Le jeu. 14 janv. 2016 ? 13:35, Jean-Micha?l Celerier > >> a ?crit : > >>> > >>> > >>> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf > > >>> wrote: > >>>> > >>>> > >>>> My personal opinion: if the full power of python would be available, > the > >>>> build > >>>> scripts would quickly turn into real programs, because programmers > would > >>>> be > >>>> tempted to do so if all of python would be available. Then developers > >>>> would > >>>> have to understand two programs: the program itself, and the "build > >>>> program". > >>> > >>> > >>> The problem is when you have to do a real program for your build system > >>> anyways (which occurs one day or another for any large enough project I > >>> guess). > >>> Currently it's a real pain (but it'd be even more painful to have to > ship > >>> Python / Bash / $script_language as part of your build system). > >>> -- > >>> > >>> 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 > > > > > > > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Fri Jan 15 09:11:42 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 15 Jan 2016 06:11:42 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <5697EF44.60001@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> Message-ID: Okay, I think I'm making some good progress. I got a trivial program built on Mac. I've now switched to Linux. I'm mostly there, but there are still some things that need to be done. More inline... https://github.com/ewmailing/CMake/tree/SwiftMakefile >> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same >> as Java). But it didn't seem to do anything for me. > > Where did you add the code to set it? I got it working. I put it in. CMakeSwiftCompiler.cmake.in I figured out I also needed to add: set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1) >> Under the hood, I think the LLVM linker can handle all of these >> through ld. But I think the thing that is tripping me up is that Swift >> seems to need to link against some additional libraries which are not >> needed in the pure C case. The swiftc command seems to know how to >> automatically link in those extra dependencies (and I don't need to >> add all the search paths to where the Swift core libraries are >> located). > > That is the same as for C++. See CMAKE_PARSE_IMPLICIT_LINK_INFO and > the call to it in "Modules/CMakeDetermineCompilerABI.cmake". That is > responsible for extracting the implicit link information passed by a > given language compiler's front-end. We'll need to extract that for > Swift. I looked at this file, but I still havne't groked what I need to do with this yet. However, I'm heavily debating if 'cc' or 'clang' is the right thing to do here. I'm starting to think 'swiftc' might be the most robust and correct thing for the linking command. There are several reasons for this: - swiftc seems to already do the right thing - Not using swiftc requires me to set a lot of things, including the Apple SDK when on Mac. This feels really messy. - On Linux, I think there is a danger in calling 'cc'. realized I may need to take a step back. > > >> I just tried not filtering the current primary file from the list. It >> still worked. So maybe we can get away with not filtering that. > > Great. It will be simplest to list all the sources in every call and then > repeat the one that is current. > >> Anyway, it seems like adding SOURCES is the next step. Any hints on >> how to do that? > > The cmLocalGenerator::ExpandRuleVariable method does the placeholder > substitution. It relies on values in the RuleVariables structure > to be populated by the calling generator. The Makefile generator > populates that for the compile line here: > > cmMakefileTargetGenerator::WriteObjectBuildFile > > and the Ninja generator here: > > cmNinjaTargetGenerator::WriteCompileRule > cmNinjaTargetGenerator::WriteObjectBuildStatement > > Note that for Ninja we actually convert our placeholders to Ninja > rule placeholders and then provide the values on the actual build > statement line. > > You should be able to call > > this->GeneratorTarget->GetObjectSources(objectSources, config); > > to get the list of source files and then filter it based on > sf->GetLanguage(). > > The name "" is not very good because it does not specify > how any filtering is done. Perhaps a special case name such as > "" would be better. > > Do we know that there is a one-to-one mapping between libraries > and Swift modules? > > -Brad > > -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From ewmailing at gmail.com Fri Jan 15 09:47:42 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 15 Jan 2016 06:47:42 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <5697EF44.60001@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> Message-ID: (Ignore the last post. The last message sent accidentally before I was even close to done. Not sure why it sent. I must have accidentally discovered a hot key in Gmail. Everything is rewritten here.) Okay, I think I'm making some good progress. I got a trivial program built on Mac. I've now switched to Linux. I'm mostly there, but there are still some things that need to be done. More inline... >> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same >> as Java). But it didn't seem to do anything for me. > > Where did you add the code to set it? I got it working. I put it in. CMakeSwiftCompiler.cmake.in I figured out I also needed to add: set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1) >> Under the hood, I think the LLVM linker can handle all of these >> through ld. But I think the thing that is tripping me up is that Swift >> seems to need to link against some additional libraries which are not >> needed in the pure C case. The swiftc command seems to know how to >> automatically link in those extra dependencies (and I don't need to >> add all the search paths to where the Swift core libraries are >> located). > > That is the same as for C++. See CMAKE_PARSE_IMPLICIT_LINK_INFO and > the call to it in "Modules/CMakeDetermineCompilerABI.cmake". That is > responsible for extracting the implicit link information passed by a > given language compiler's front-end. We'll need to extract that for > Swift. I looked at this file, but I still havne't groked what I need to do with this yet. However, I'm heavily debating if 'cc' or 'clang' is the right thing to do here. I'm starting to think 'swiftc' might be the most robust and correct thing for the linking command. There are several reasons for this: - swiftc seems to already do the right thing - Not using swiftc requires me to set a lot of things, including the Apple SDK when on Mac. This feels really messy. - On Linux, I think there is a danger in calling 'cc' because it could be gcc or it could be an older version of clang. (Officially, clang 3.5 is needed, but the default one on the particular Linux I'm using is less than that.) Invoking swiftc theoretically side-steps this problem. But if I use swiftc, I create a few new complications: - First, CMake seems to be passing the flag -rdynamic to the link instructions, and this is causing a "unknown argument" error. I think this needs to be removed. I'm not sure where this flag is coming from. - Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument" error. As shown in the beginning of this thread, swiftc wants each argument to lead with -Xlinker (and there is no -Wl,) -Xlinker -rpath -Xlinker /foo/bar Again, I'm not sure where the old stuff is, and what is involved to inject the -Xlinker stuff. Additionally, I realized I should have some other variable besides Seems like I should have . I'm not sure what the correct way to create this is. However, I currently employ a clever cheat. Since the compiler is 'swift', and the linker is 'swiftc', I just do 'c' > cmMakefileTargetGenerator::WriteObjectBuildFile > You should be able to call > this->GeneratorTarget->GetObjectSources(objectSources, config); Okay, I added this code. It seems to be working. Though I'm not completely sure I fetched config correctly. My current changes can be found here in the SwiftMakefile branch https://github.com/ewmailing/CMake/tree/SwiftMakefile > and the Ninja generator here: > > cmNinjaTargetGenerator::WriteCompileRule > cmNinjaTargetGenerator::WriteObjectBuildStatement > > Note that for Ninja we actually convert our placeholders to Ninja > rule placeholders and then provide the values on the actual build > statement line. > I actually don't' know anything about Ninja. I assume it is just a string translation at this point since I did the other? Any guidance on the mapping? > Do we know that there is a one-to-one mapping between libraries > and Swift modules? Sorry, I'm still not completely up to speed on Swift modules. My impression is there are 3 parts: .swiftmodule (which contains the public interface/definitions), .swiftdoc (for documentation), and a library (.a, .so). I suspect the .swiftmodule will need to be part of the compile parameters and the library will be part of the link, but I'm not sure if there will be additional requirements. But anyway, I would like to get something building on Linux first, so I need to fix the swiftc/linker stuff first. Any suggestions? Then, I would like to enhance the trivial test to support actually using something from the intermixed C files. This means I need to add the bridging header parameter. So I need a new per-target variable in CMake for this and a way to inject it into the compiler flags, maybe something like this: " -frontend -c -import-objc-header -primary-file -emit-module -module-name -o ") With those two pieces, I think that actually makes add_executable() usable in the Makefile generator. Thanks, Eric From liorgol.dev+cmake at gmail.com Fri Jan 15 09:47:56 2016 From: liorgol.dev+cmake at gmail.com (Lior Goldberg) Date: Fri, 15 Jan 2016 16:47:56 +0200 Subject: [cmake-developers] RPATH bug + patch suggestion Message-ID: Hi, I think there is a bug in the way CMake handles rpath for installed targets. My GCC installation contains the following definition in the specs file: *link_libgcc: %D -rpath <> This configuration leads to the following bug in CMake: Whenever a target (which depends on a library in the project) is created, the rpath is completely removed from the installed targets (including the linker's predefined rpath). This is not the case when there are no dependencies on other libraries in the project. Of course this can be fixed by changing CMake rpath-related variables but I think that this suggests that the default rpath handling should be fixed. (Note that the same behavior happens when "-Wl,-rpath" is used in CMAKE_EXE_LINKER_FLAGS) Specifically, I think that the command "FILE(RPATH_REMOVE ...)" is not subtle enough, as it removes the compiler's predefined rpath together with the rpath added by CMake. I suggest replacing it with the command "FILE(RPATH_CHANGE ...)" (even when NEW_RPATH is empty) and allowing this command to decide (based on the actual rpath defined in the file) whether the rpath entry should be removed. Attached is the suggested patch. Please let me know what you think. Thanks, Lior -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-RPATH_CHANGE-instead-of-RPATH_REMOVE.patch Type: application/octet-stream Size: 3588 bytes Desc: not available URL: From shawn.waldon at kitware.com Fri Jan 15 10:05:03 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Fri, 15 Jan 2016 10:05:03 -0500 Subject: [cmake-developers] Git for windows patch In-Reply-To: <213111452829356@web10j.yandex.ru> References: <213111452829356@web10j.yandex.ru> Message-ID: Hi Kanstantin, Thanks for the feedback. The location of git that I have always used is "C:\Program Files [(x86)]\bin\git.exe". Looking at the git installation, there is another executable "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed CMake at that one. What is the difference between the two? I can change the patch to use the other one, but I'd like to understand why it is necessary. Thanks, Shawn On Thu, Jan 14, 2016 at 10:42 PM, Konstantin Podsvirov < konstantin at podsvirov.pro> wrote: > Hi, Shawn! > > I am using CMake and Git on the Windows. As an IDE I use Qt Creator. > > My experience is that on Windows you need to use: > > "C:\Program Files [(x86)]\Git\cmd\git.exe" > > If you use your proposed way, I'm having problems > work with Git in my project. > > It seems to me that this decision is necessary to discuss here. > > Dear list, does anyone have experience and recommendations? > > 15.01.2016, 02:49, "Shawn Waldon" : > > Hi, > > > > Recently I had to build a project on windows whose required build git. > And even though I had installed git from here [1] in the default location, > I had to tell CMake where to find it every time I did a build in a clean > build tree. So here is a patch that tells CMake to look in the default > install location for Git for Windows [2] when asked for git. I have tested > it on my windows machine and it works there. > > > > Shawn > > > > [1]: https://git-for-windows.github.io/ > > [2]: C:\Program Files\Git\bin\git.exe ('Program Files (x86)' for older > versions or 32 bit systems) > > ,-- > > > > 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 > > > Regards, > Konstantin Podsvirov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Jan 15 10:25:55 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Jan 2016 10:25:55 -0500 Subject: [cmake-developers] Git for windows patch In-Reply-To: References: Message-ID: <56990F83.6010000@kitware.com> On 01/14/2016 06:48 PM, Shawn Waldon wrote: > patch that tells CMake to look in the default install location for > Git for Windows [2] when asked for git. This is expected to work already as follows. This code: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/WindowsPaths.cmake;hb=v3.4.1#l25 adds the program files directories to CMAKE_SYSTEM_PREFIX_PATH. Then the find_program call in FindGit: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindGit.cmake;hb=v3.4.1#l54 uses the PATH_SUFFIXES options "Git/cmd" and "Git/bin" to look in the relevant install directories. You'll have to investigate locally to determine why this method is not working. -Brad From brad.king at kitware.com Fri Jan 15 10:26:43 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Jan 2016 10:26:43 -0500 Subject: [cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug In-Reply-To: References: Message-ID: <56990FB3.4040905@kitware.com> On 01/14/2016 04:12 PM, Tam?s Ken?z wrote: > Is this really a bug or did I miss something? It is a bug. Good catch and thanks for the simple example. This should fix it: Fix export of STATIC library PRIVATE dependencies with CMP0022 NEW https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aea1b036 -Brad From paul at mad-scientist.net Fri Jan 15 11:24:30 2016 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 15 Jan 2016 11:24:30 -0500 Subject: [cmake-developers] Git for windows patch In-Reply-To: References: <213111452829356@web10j.yandex.ru> Message-ID: <1452875070.3787.146.camel@mad-scientist.net> On Fri, 2016-01-15 at 10:05 -0500, Shawn Waldon wrote: > Looking at the git installation, there is another executable > "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed > CMake at that one. What is the difference between the two? I can > change the patch to use the other one, but I'd like to understand why > it is necessary. There is no difference between them. When you install Git for Windows the installer gives a choice of three different ways to set up %PATH%. One way is to not add anything to %PATH%: then git is only available from within the Git bash shell not from within command.com shell. The second way is to make git, only (plus a few helpers like gitk, start-ssh-agent, etc.) available on %PATH%: then git is available from command.com but none of the other UNIX tools like find, diff, etc. are available from command.com (only from Git shell). In this install method the \cmd directory is added to %PATH%. The last way is to allow git plus all the ming32 versions of UNIX tools that come with Git to be available to command.com. In this install method both \cmd AND \usr\bin are added to %PATH%. The existence of \bin is there only for backward -compatibility, because some people coming from older versions of Git for Windows might be referencing it. It shouldn't be used anymore by modern installs (it contains bash.exe and sh.exe both of which are in \usr\bin, and git.exe which is in \cmd). From jchris.fillionr at kitware.com Fri Jan 15 11:37:29 2016 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 15 Jan 2016 11:37:29 -0500 Subject: [cmake-developers] Git for windows patch In-Reply-To: <1452875070.3787.146.camel@mad-scientist.net> References: <213111452829356@web10j.yandex.ru> <1452875070.3787.146.camel@mad-scientist.net> Message-ID: Hi, > The existence of \bin is there only for backward -compatibility I guess we could also add "Git/usr/bin" to the suffixes so that it prefer newer version first ? PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin Hth Jc On Fri, Jan 15, 2016 at 11:24 AM, Paul Smith wrote: > On Fri, 2016-01-15 at 10:05 -0500, Shawn Waldon wrote: > > Looking at the git installation, there is another executable > > "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed > > CMake at that one. What is the difference between the two? I can > > change the patch to use the other one, but I'd like to understand why > > it is necessary. > > There is no difference between them. When you install Git for Windows > the installer gives a choice of three different ways to set up %PATH%. > > One way is to not add anything to %PATH%: then git is only available > from within the Git bash shell not from within command.com shell. > > The second way is to make git, only (plus a few helpers like gitk, > start-ssh-agent, etc.) available on %PATH%: then git is available from > command.com but none of the other UNIX tools like find, diff, etc. are > available from command.com (only from Git shell). In this install > method the \cmd directory is added to %PATH%. > > The last way is to allow git plus all the ming32 versions of UNIX tools > that come with Git to be available to command.com. In this install > method both \cmd AND \usr\bin are added to %PATH%. > > The existence of \bin is there only for backward > -compatibility, because some people coming from older versions of Git > for Windows might be referencing it. It shouldn't be used anymore by > modern installs (it contains bash.exe and sh.exe both of which are in > \usr\bin, and git.exe which is in \cmd). > -- > > 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 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Fri Jan 15 11:58:27 2016 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 15 Jan 2016 11:58:27 -0500 Subject: [cmake-developers] Git for windows patch In-Reply-To: References: <213111452829356@web10j.yandex.ru> <1452875070.3787.146.camel@mad-scientist.net> Message-ID: <1452877107.3787.162.camel@mad-scientist.net> On Fri, 2016-01-15 at 11:37 -0500, Jean-Christophe Fillion-Robin wrote: > > The existence of \bin is there only for backward > -compatibility > > I guess we could also add "Git/usr/bin" to the suffixes so that it > prefer newer version first ? > > PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin I'm not sure which command you're looking for? git.exe exists only in Git/bin (old-style) and Git/cmd. Where both exist they'll have exactly the same version of git.exe in them. I think using Git/cmd only to find git.exe is fine; I'm pretty sure it's always existed there even in older releases of Git for Windows, an d will continue to do so going forward. You definitely don't need Git/usr/bin unless you want to find all the UNIX tools. Git.exe is not there. From arankin at robarts.ca Fri Jan 15 12:50:57 2016 From: arankin at robarts.ca (Adam Rankin) Date: Fri, 15 Jan 2016 17:50:57 +0000 Subject: [cmake-developers] Patch for ExternalProject_Add git clone -o support Message-ID: <9dd7d85429a243ba851ab774c914f592@dag2.robarts.ca> Hello all, As per my inquiry on the users mailing list, I have implemented support for the -origin parameter of git clone. It is backwards compatible as the parameter is optional and defaults to "origin". Example use case: After using ExternalProject_Add to download and built a supporting library, development of that library is needed. In the case of github/bitbucket, the cloned repository can be a fork. To simplify management, providing a more descriptive remote name is desired. Usage: ExternalProject_Add( OpenIGTLink "${PLUSBUILD_EXTERNAL_PROJECT_CUSTOM_COMMANDS}" SOURCE_DIR "${PLUS_OpenIGTLink_SRC_DIR}" BINARY_DIR "${PLUS_OpenIGTLink_DIR}" #--Download step-------------- GIT_REPOSITORY "${GIT_PROTOCOL}://github.com/adamrankin/OpenIGTLink.git" GIT_TAG "master" GIT_REMOTE_NAME "adamrankin_igtl" #--Configure step------------- ... I have attached a patch that provides an implementation of this parameter and tested it for both cloning and updating. Feedback is appreciated and I hope this is of use for others. Kind regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: git_remote_name_support.patch Type: application/octet-stream Size: 4557 bytes Desc: git_remote_name_support.patch URL: From brad.king at kitware.com Fri Jan 15 14:11:52 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Jan 2016 14:11:52 -0500 Subject: [cmake-developers] Git for windows patch In-Reply-To: <56990F83.6010000@kitware.com> References: <56990F83.6010000@kitware.com> Message-ID: <56994478.4060209@kitware.com> On 01/15/2016 10:25 AM, Brad King wrote: > You'll have to investigate locally to determine why this method is > not working. It looks like a 64-bit CMake binary would not properly include the "Program Files (x86)" directory as a search location due to outdated assumptions. Please try this fix: Windows: Find Program Files directories more robustly from environment https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09b2f1c3 -Brad From brad.king at kitware.com Fri Jan 15 14:22:31 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Jan 2016 14:22:31 -0500 Subject: [cmake-developers] Patch for ExternalProject_Add git clone -o support In-Reply-To: <9dd7d85429a243ba851ab774c914f592@dag2.robarts.ca> References: <9dd7d85429a243ba851ab774c914f592@dag2.robarts.ca> Message-ID: <569946F7.4020601@kitware.com> On 01/15/2016 12:50 PM, Adam Rankin wrote: > I have attached a patch that provides an implementation of this parameter Thanks! Applied with minor tweaks and a release note: ExternalProject: Add option to set `git clone -o` argument https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83d63391 -Brad From brad.king at kitware.com Fri Jan 15 14:54:03 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Jan 2016 14:54:03 -0500 Subject: [cmake-developers] RPATH bug + patch suggestion In-Reply-To: References: Message-ID: <56994E5B.8090106@kitware.com> On 01/15/2016 09:47 AM, Lior Goldberg wrote: > Specifically, I think that the command "FILE(RPATH_REMOVE ...)" is not subtle > enough, as it removes the compiler's predefined rpath together with the rpath > added by CMake. Good catch, thanks. Patch applied with minor tweaks: install: Do not remove compiler-defined RPATH entries https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ec92267 -Brad From tamas.kenez at gmail.com Fri Jan 15 14:54:32 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 15 Jan 2016 20:54:32 +0100 Subject: [cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug In-Reply-To: <56990FB3.4040905@kitware.com> References: <56990FB3.4040905@kitware.com> Message-ID: Thanks for the quick response! Tamas On Fri, Jan 15, 2016 at 4:26 PM, Brad King wrote: > On 01/14/2016 04:12 PM, Tam?s Ken?z wrote: > > Is this really a bug or did I miss something? > > It is a bug. Good catch and thanks for the simple example. > This should fix it: > > Fix export of STATIC library PRIVATE dependencies with CMP0022 NEW > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aea1b036 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Jan 15 15:41:31 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Jan 2016 15:41:31 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> Message-ID: <5699597B.80108@kitware.com> On 01/15/2016 09:47 AM, Eric Wing wrote: >> That is the same as for C++. See CMAKE_PARSE_IMPLICIT_LINK_INFO and > > I looked at this file, but I still havne't groked what I need to do > with this yet. Somehow we need to get swift to print verbose output about the command line it uses to invoke the linker on the small test project CMake uses while enabling the language. Then we need to parse that link line to get the list of libraries and link directories. This can be a later step once most other things work though. > However, I'm heavily debating if 'cc' or 'clang' is the right thing to > do here. If the user sets LINKER_LANGUAGE to "C" and does not have main in Swift then CMake will want to link with the C compiler. FYI, it is not actually 'cc' but the CMAKE_C_COMPILER selected, which happens to be 'cc' often. Anyway, we should go with CMAKE_Swift_COMPILER for now. > - First, CMake seems to be passing the flag -rdynamic to the link > instructions, and this is causing a "unknown argument" error. I think > this needs to be removed. I'm not sure where this flag is coming from. > > - Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument" > error. As shown in the beginning of this thread, swiftc wants each > argument to lead with -Xlinker (and there is no -Wl,) > -Xlinker -rpath -Xlinker /foo/bar You'll need to add proper settings in files of the form Modules/Platform/--.cmake Modules/Compiler/-.cmake such as Modules/Platform/Linux-Apple-Swift.cmake Modules/Platform/Darwin-Apple-Swift.cmake Modules/Compiler/Apple-Swift.cmake See Modules/Platform/Linux-NAG-Fortran.cmake for an example that changes from -Wl,-rpath to -Xlinker -rpath. Similarly the CMAKE_SHARED_LIBRARY_LINK__FLAGS must not have -rdynamic in it. You're getting the settings from C right now because your CMakeSwiftInformation.cmake file is copying them. Instead leave all those out and add them as needed, preferably without copying from C. > Additionally, I realized I should have some other variable besides > > Seems like I should have . I'm not sure what the > correct way to create this is. All the languages use CMAKE__COMPILER as the front-end to invoke for linking. There should not need to be a separate linker value unless that is new to Swift semantics. > However, I currently employ a clever cheat. Since the compiler is > 'swift', and the linker is 'swiftc', I just do > 'c' So plain 'swift' cannot be used to drive the linker too? >> Note that for Ninja we actually convert our placeholders to Ninja >> rule placeholders and then provide the values on the actual build >> statement line. > > I actually don't' know anything about Ninja. I assume it is just a > string translation at this point since I did the other? Any guidance > on the mapping? Let's start with the Makefile generator. Porting the results to the Ninja generator should not be too much work later. > So I need a new per-target variable in CMake for this and a way to > inject it into the compiler flags, maybe something like this: > > " -frontend -c > -import-objc-header -primary-file > -emit-module -module-name -o > ") > > With those two pieces, I think that actually makes add_executable() > usable in the Makefile generator. The values for the placeholders are always determined in the context of a specific target, so just "" should be fine. Thanks, -Brad From mantis at public.kitware.com Fri Jan 15 18:10:28 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 15 Jan 2016 18:10:28 -0500 Subject: [cmake-developers] [CMake 0015921]: CUDA_nvcuvid_LIBRARY and CUDA_nvcuvenc_LIBRARY is never set to anything in FindCUDA.cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15921 ====================================================================== Reported By: Jason Juang Assigned To: ====================================================================== Project: CMake Issue ID: 15921 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-15 18:10 EST Last Modified: 2016-01-15 18:10 EST ====================================================================== Summary: CUDA_nvcuvid_LIBRARY and CUDA_nvcuvenc_LIBRARY is never set to anything in FindCUDA.cmake Description: The variables CUDA_nvcuvenc_LIBRARY and CUDA_nvcuvid_LIBRARY is never set to anything in FindCUDA.cmake, despite it being two of the variables and is suppose to represent libnvcuvenc.so and libnvcuvid.so. Additionally, there are comments saying that these are windows only which is outdated because now the CUDA video SDK is also available in linux. Steps to Reproduce: At any CMakeLists.txt: find_package( CUDA REQUIRED ) message(cuda decoder lib ${CUDA_nvcuvid_LIBRARY}) message(cuda encoder lib ${CUDA_nvcuvenc_LIBRARY}) Nothing will be there. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-15 18:10 Jason Juang New Issue ====================================================================== From tobias.hunger at gmail.com Sat Jan 16 04:38:11 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sat, 16 Jan 2016 10:38:11 +0100 Subject: [cmake-developers] cmake daemon mode protocol In-Reply-To: References: Message-ID: Hi Stephen, Am 15.01.2016 00:38 schrieb "Stephen Kelly" : > > * Start daemon-mode without any additional parameters > > > > * Daemon responds with " > > { > > "type": "handShake", > > "version": "3.5.x", > > "supportedProtocols": "3.5" > > } > > As you discovered, the cmake binary might not even support the daemon mode > at all. That is really straight forward to detect: It will send malformed JSON on stdout if daemon-mode is unsupported:-) The error message you get is not JSON and definitely on of type handShake. > I think what you are really asking for is 'the capabilities of the cmake > binary'. In that sense, you might also want to know what generators are > available, whether daemon mode is available (and with which protocol > versions) etc. > > The issue at > > http://public.kitware.com/Bug/view.php?id=15462 > > proposes to dump that information to stdout with a different -E command. I do not really see the need for that. Daemon-mode is easy to detect by the reply to the attempt to start it. Everything else I expect to extract from within daemon mode. > > > > * Client Handshake: > > { > > "type": "handshake", > > "requestProtocolVersion": "3.5" > > } > > > > * Daemon: > > { > > "type:"handshake", > > "protocolVersion": "3.5" > > } > > Something like this is possible too. It's not far off what is already done > in the branch. I know, that is what this is based on after all. All I want is to be able to start daemon-mode without having a builddir that is already associated with a sourcedir. > > At this point the normal operation should be possible. > > > > * Client: > > { > > "type": "setProjectInformation", > > "sourceDirectory": "/some/path", > > "cookie": "1" > > } > > > > Being able to set the source directory is important so that a fresh > > checkout can be configured. There is no build directory available at > > that time... > > I understand the desire to inspect a cmake project without asking the user > to specify a build dir, You can safely read the CMakelists at this point, give syntax errors, maybe even extract basic information like project name at this point. > but cmake has to write build files somewhere in > order to test the compiler etc. If this works with a temporary build directory, then these files probably do not need to litter the build directory in the first place:-) > For this case, I suggest that if the user tries to 'open the source > directory', you would use QTemporaryDir to build in a temporary location and > run the daemon there. I believe clion does something equivalent to that. Hey, the idea is to improve on the current situation, not to perpetuate the workarounds. And how do I associate an empty directory as a builddir to a sourcedir? How can I switch between builds when the daemon-mode is set up to work with one builddir? Do I have to close it down and start a new daemon for the next build? That would be suboptimal, as all the built-in dependent state of the project would need to get regenerated by the new daemon. Associating a daemon with a sourcedir and being able to switch builddir would be nicer. > Is that viable? I suppose you are suggesting that cmake do that instead of > leaving it for clients to do? It is doable. I just do not see why this should be necessary. The daemon is not need to persist its state to disk all the time like command-based cmake currently needs to. > > * Daemon should do progress handling while reading the CMakeLists.txt > > or whatever it does: > > { "type": "progress", "state": "busy", "task": "someId", > > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" } > > > > * Daemon sends occasional: > > { "type": "progress", "task": "someId", progressTotal: 25, > > progressCurrent: 12, "cookie": "1" } > > Yes. CMake can provide approximate values of how complete the configure step > is. See cmGlobalGenerator::AddMakefile. That could be exposed to the daemon > 'somehow', such as by defining some virtual callback interface. > > Richer information about some semantics like 'task' and 'busy state' could > also be provided in a similar way I expect, assuming those could be defined. This is some basic functionality that we should get right soon, as this can influence how long-running tasks need to be designed. > > * Finally Daemon responds sends data as that is available now. > > { > > "type": "projectInformation", > > "sourceDirectory": "/some/path", > > "buildDirectory": "", > > "projectName": "SomeProject", > > "cookie": "1" > > } > > At this point in your proposal, cmake has run the configure step in a > temporary directory, right? I am currently arguing with complete ignorance of how cmake works internally:-) This is just what I think makes the most sense from an IDE perspective. > So it would be > > "buildDirectory": "/tmp/foo/bar" > > right? No. The daemon should be associated with a sourcedir, not a builddir. At this point there should not be a builddir yet! I think it makes sense to get the built-in dependent information first, before having a builddir set and then proceeding to generate the build-dependent information. > > * Client: > > { > > "type": "setProjectInformation", > > "buildDirectory": "/some/other/path", > > "cookie": "2" > > } > > As this sets a new build directory, cmake will have to run the configure > step from scratch in this new location. > > > * Daemon does progress indication as above... > > > > * Daemon responds with project info: > > { > > "type": "progressInformation", > > "sourceDirectory": "/some/path", > > "buildDirectory": "/some/other/path", > > "projectName": "SomeProject", > > "cookie": "2" > > } > > I must admit I'm not seduced by this idea as it seems to be that it should > be easy for an IDE to build in a temporary dir itself. > > However, I think it makes sense to design the protocol to handle specifying > either a sourceDir or a buildDir (or both if from scratch). Starting daemon > mode without arguments as you suggest could work (though we would have to > see how that affects the protocol). Or with a different argument (eg > > cmake -E daemon buildDir > cmake -E daemon_source sourceDir > > ) could work. I am also just brainstorming ideas, not proscribing anything. You are a prisoner of the current implementation:-) > > We might also want a "ping"/"pong" to detect if the daemon is still > > responding. > > Yes, I had the same thought. I also considered self-terminating the daemon > if there is no message on the wire for N seconds, effectively requiring the > IDE to ping every N seconds if it is not doing anything else. I considered > this because otherwise the IDE might crash and leave zombie cmake daemons > running, but I didn't investigate that possibility. True. But I am actually more concerned with the daemon freezing:-) > > That would require the daemon to be able to handle > > multiple requests to be in flight... not sure that this is worth it. > > Yes, adding a multi-threading requirement to the daemon might make some > implementation more difficult. I've seen some videos on designs for things > like that though, and I am interested in trying them out. > > > But if we can not do that, then we need to provide constant progress > > information, which is also not great:-) > > The good news is that after the initial configure and compute steps are > finished (where progress makes sense anyway I think), all other requests are > 'very fast'. So "cmake --build" is out of scope for the daemon? > > Not sure about the need for cookies (text set by the client and > > repeated by the server in all its replies to that request). I do think > > having them makes sense, even when only one request can be active at > > any time: They make it so much easier to sanity-check communication. > > Yes, I considered something like that in the protocol too. I didn't add any > because I didn't encounter the need yet in the parts of the protocol I > implemented and the proof-of-concept tooling I made, so I deferred that part > of the design space until a time when more requirements are known. That is why I brought up progress information so early: They make things complicated by there suddenly being several responses to a request and you need a way to identify those. At that point simpler solutions tend to blow up:-) > > Consistently having a "type" in all messages going back and forth is > > probably a good idea for the same reason as having cookies. > > Yep. Good! > Thanks for this useful feedback! You are welcome. Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sat Jan 16 06:26:55 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 16 Jan 2016 12:26:55 +0100 Subject: [cmake-developers] cmake daemon mode protocol References: Message-ID: Tobias Hunger wrote: >> For this case, I suggest that if the user tries to 'open the source >> directory', you would use QTemporaryDir to build in a temporary location > and >> run the daemon there. I believe clion does something equivalent to that. >> Is that viable? I suppose you are suggesting that cmake do that instead >> of leaving it for clients to do? > > It is doable. I just do not see why this should be necessary. I'm aiming to first design as much as possible of a 'minimal viable protocol' as a first step. Given the above I think your ideas of running the daemon with no build dir are not 'minimal' and I'm convinced they're not viable. Someone would have to prototype the ideas, but I don't think that's a good use of time or energy right now (mostly because I think they're not viable). I recommend focussing on the tasks in my OP: http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 >> Richer information about some semantics like 'task' and 'busy state' >> could also be provided in a similar way I expect, assuming those could be > defined. > > This is some basic functionality that we should get right soon, as this > can influence how long-running tasks need to be designed. Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in mind. Particularly if you can relate them to what is already in my github branch. > So "cmake --build" is out of scope for the daemon? I listed three ways cmake and an IDE could interface here: http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 'triggering the build' would be a fourth. I don't think it needs to be part of the initial discussion of the design. Let's try to keep scope small so that we can get on common ground. > That is why I brought up progress information so early: They make things > complicated by there suddenly being several responses to a request and you > need a way to identify those. At that point simpler solutions tend to blow > up:-) Yes. BTW: I don't expect to get any part of the design of the protocol 'right' on the first iteration. I think we need to start everything that will need to be in the protocol, then iterate. Start high level ignoring details, and fill in the details as we iterate and can encode needs in unit tests. Thanks, Steve. From steveire at gmail.com Sat Jan 16 07:03:25 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 16 Jan 2016 13:03:25 +0100 Subject: [cmake-developers] cmake daemon mode protocol References: Message-ID: Stephen Kelly wrote: > I recommend focussing on the tasks in my OP: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 To be more clear: The goal I have is to enable debugging, introspection of the buildsystem and the state during execution, code completion etc. Your goal seems to be completely orthogonal to that and requires an entirely different set of steps to achieve (perhaps the first being 'demonstrate viability'). I don't think I can help with your goal. Thanks, Steve. From tobias.hunger at gmail.com Sat Jan 16 08:28:03 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sat, 16 Jan 2016 14:28:03 +0100 Subject: [cmake-developers] cmake daemon mode protocol In-Reply-To: References: Message-ID: Hi Stephen, I think what I suggested so far is covered by the first way of interaction covered in http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 . I am just proposing something that is convenient for me to use. On Sat, Jan 16, 2016 at 12:26 PM, Stephen Kelly wrote: >>> For this case, I suggest that if the user tries to 'open the source >>> directory', you would use QTemporaryDir to build in a temporary location >> and >>> run the daemon there. I believe clion does something equivalent to that. >>> Is that viable? I suppose you are suggesting that cmake do that instead >>> of leaving it for clients to do? >> >> It is doable. I just do not see why this should be necessary. > > I'm aiming to first design as much as possible of a 'minimal viable > protocol' as a first step. Given the above I think your ideas of running the > daemon with no build dir are not 'minimal' and I'm convinced they're not > viable. I am thinking about the simplest possible use-case I can think of right now: User gets sources from a project somewhere and wants to build those. What is entirely unclear to me with your current implementation is how do I get from "sources are checked out in $DIR" to "I have a $BUILD that I can use to start the daemon"? Then I also do not see how I can support a user switching between two build directories. Do I need to close down one daemon and start another? > Someone would have to prototype the ideas, but I don't think that's a good > use of time or energy right now (mostly because I think they're not viable). > > I recommend focussing on the tasks in my OP: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 That list is so full of cmake internals that it is basically meaningless to me. Sorry. >>> Richer information about some semantics like 'task' and 'busy state' >>> could also be provided in a similar way I expect, assuming those could be >> defined. >> >> This is some basic functionality that we should get right soon, as this >> can influence how long-running tasks need to be designed. > > Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in > mind. Particularly if you can relate them to what is already in my github > branch. "task" is just some Id to identify what the daemon is currently doing. "state" is just some indication of whether the daemon thinks it is busy with something or not. In "idle" state it should accept more requests, in "busy" state it will just queue them or maybe even ignore them. >> So "cmake --build" is out of scope for the daemon? > > I listed three ways cmake and an IDE could interface here: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 > > 'triggering the build' would be a fourth. I don't think it needs to be part > of the initial discussion of the design. > > Let's try to keep scope small so that we can get on common ground. So let's forget about all the interactive stuff for now. That is IMHO step 2, after the basic protocol is validated by implementing bare bones project information:-) >> That is why I brought up progress information so early: They make things >> complicated by there suddenly being several responses to a request and you >> need a way to identify those. At that point simpler solutions tend to blow >> up:-) > > Yes. > > BTW: I don't expect to get any part of the design of the protocol 'right' on > the first iteration. I think we need to start everything that will need to > be in the protocol, then iterate. Start high level ignoring details, and > fill in the details as we iterate and can encode needs in unit tests. I agree and do not expect anything different. Basic protocol functionality from my point of view needs to include: * Being able to detect the daemon or IDE becoming unresponsive * Being able to find which responses are the result of which requests * Being able to reliably find what kind of object I got as request or response >From the point of view of an IDE: Being able to have progress information is not a high level detail to be filled in later. Best Regards, Tobias From ashley at awhetter.co.uk Sat Jan 16 12:10:07 2016 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Sat, 16 Jan 2016 17:10:07 +0000 Subject: [cmake-developers] [PATCH] Added FILTER subcommand to list command Message-ID: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> In response to issue 0003986, I've implemented a FILTER subcommand to the "list" command that filters a list using a regular expression. This doesn't implement an optional "OUTPUT_VARIABLE" parameter. There was a discussion on the issue as to whether or not the user using a macro would be a better option. Therefore I've submitted a sample macro for the reporter on the issue as well if this patch isn't accepted. --- Help/command/list.rst | 12 +++-- Source/cmListCommand.cxx | 54 ++++++++++++++++++++++ Source/cmListCommand.h | 1 + Tests/RunCMake/list/EmptyFilter-result.txt | 1 + Tests/RunCMake/list/EmptyFilter-stderr.txt | 0 Tests/RunCMake/list/EmptyFilter.cmake | 2 + Tests/RunCMake/list/FILTER-InvalidRegex-result.txt | 1 + Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt | 4 ++ Tests/RunCMake/list/FILTER-InvalidRegex.cmake | 2 + Tests/RunCMake/list/FILTER-NotList-result.txt | 1 + Tests/RunCMake/list/FILTER-NotList-stderr.txt | 4 ++ Tests/RunCMake/list/FILTER-NotList.cmake | 2 + .../list/FILTER-TooManyArguments-result.txt | 1 + .../list/FILTER-TooManyArguments-stderr.txt | 4 ++ Tests/RunCMake/list/FILTER-TooManyArguments.cmake | 1 + Tests/RunCMake/list/FILTER-Valid0-result.txt | 1 + Tests/RunCMake/list/FILTER-Valid0-stderr.txt | 2 + Tests/RunCMake/list/FILTER-Valid0.cmake | 4 ++ Tests/RunCMake/list/RunCMakeTest.cmake | 6 +++ 19 files changed, 100 insertions(+), 3 deletions(-) create mode 100644 Tests/RunCMake/list/EmptyFilter-result.txt create mode 100644 Tests/RunCMake/list/EmptyFilter-stderr.txt create mode 100644 Tests/RunCMake/list/EmptyFilter.cmake create mode 100644 Tests/RunCMake/list/FILTER-InvalidRegex-result.txt create mode 100644 Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-InvalidRegex.cmake create mode 100644 Tests/RunCMake/list/FILTER-NotList-result.txt create mode 100644 Tests/RunCMake/list/FILTER-NotList-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-NotList.cmake create mode 100644 Tests/RunCMake/list/FILTER-TooManyArguments-result.txt create mode 100644 Tests/RunCMake/list/FILTER-TooManyArguments-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-TooManyArguments.cmake create mode 100644 Tests/RunCMake/list/FILTER-Valid0-result.txt create mode 100644 Tests/RunCMake/list/FILTER-Valid0-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-Valid0.cmake diff --git a/Help/command/list.rst b/Help/command/list.rst index a7a05c7..797cc14 100644 --- a/Help/command/list.rst +++ b/Help/command/list.rst @@ -9,6 +9,7 @@ List operations. list(GET [ ...] ) list(APPEND [ ...]) + list(FILTER ) list(FIND ) list(INSERT [ ...]) list(REMOVE_ITEM [ ...]) @@ -23,6 +24,11 @@ List operations. ``APPEND`` will append elements to the list. +``FILTER`` will remove the items from the list that match the given regular +expression. +For more information on regular expressions see also the :command:`string` +command. + ``FIND`` will return the index of the element specified in the list or -1 if it wasn't found. @@ -38,9 +44,9 @@ difference is that ``REMOVE_ITEM`` will remove the given items, while ``SORT`` sorts the list in-place alphabetically. -The list subcommands ``APPEND``, ``INSERT``, ``REMOVE_AT``, ``REMOVE_ITEM``, -``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new values for -the list within the current CMake variable scope. Similar to the +The list subcommands ``APPEND``, ``INSERT``, ``FILTER``, ``REMOVE_AT``, +``REMOVE_ITEM``, ``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new +values for the list within the current CMake variable scope. Similar to the :command:`set` command, the LIST command creates new variable values in the current scope, even if the list itself is actually defined in a parent scope. To propagate the results of these operations upwards, use diff --git a/Source/cmListCommand.cxx b/Source/cmListCommand.cxx index 6041fb7..bafd647 100644 --- a/Source/cmListCommand.cxx +++ b/Source/cmListCommand.cxx @@ -14,6 +14,7 @@ #include #include "cmAlgorithms.h" +#include #include // required for atoi #include #include @@ -68,6 +69,10 @@ bool cmListCommand { return this->HandleReverseCommand(args); } + if(subCommand == "FILTER") + { + return this->HandleFilterCommand(args); + } std::string e = "does not recognize sub-command "+subCommand; this->SetError(e); @@ -517,3 +522,52 @@ bool cmListCommand::HandleRemoveAtCommand( return true; } +//---------------------------------------------------------------------------- +class MatchesRegex { +public: + MatchesRegex(cmsys::RegularExpression& in_regex) : regex(in_regex) {} + + bool operator()(const std::string& target) { + return regex.find(target); + } + +private: + cmsys::RegularExpression& regex; +}; + +bool cmListCommand::HandleFilterCommand( + std::vector const& args) +{ + if(args.size() != 3) + { + this->SetError("sub-command FILTER requires two arguments."); + return false; + } + + const std::string& listName = args[1]; + // expand the variable + std::vector varArgsExpanded; + if ( !this->GetList(varArgsExpanded, listName) ) + { + this->SetError("sub-command FILTER requires list to be present."); + return false; + } + + const std::string& pattern = args[2]; + cmsys::RegularExpression regex(pattern); + if(!regex.is_valid()) + { + this->SetError( + "sub-command FILTER failed to compile regex \"" + pattern + "\"."); + return false; + } + + std::vector::iterator argsBegin = varArgsExpanded.begin(); + std::vector::iterator argsEnd = varArgsExpanded.end(); + std::vector::iterator newArgsEnd = + std::remove_if(argsBegin, argsEnd, MatchesRegex(regex)); + + std::string value = cmJoin(cmMakeRange(argsBegin, newArgsEnd), ";"); + this->Makefile->AddDefinition(listName, value.c_str()); + return true; +} diff --git a/Source/cmListCommand.h b/Source/cmListCommand.h index 5ea1d9f..e66b480 100644 --- a/Source/cmListCommand.h +++ b/Source/cmListCommand.h @@ -58,6 +58,7 @@ protected: bool HandleRemoveDuplicatesCommand(std::vector const& args); bool HandleSortCommand(std::vector const& args); bool HandleReverseCommand(std::vector const& args); + bool HandleFilterCommand(std::vector const& args); bool GetList(std::vector& list, const std::string& var); diff --git a/Tests/RunCMake/list/EmptyFilter-result.txt b/Tests/RunCMake/list/EmptyFilter-result.txt new file mode 100644 index 0000000..573541a --- /dev/null +++ b/Tests/RunCMake/list/EmptyFilter-result.txt @@ -0,0 +1 @@ +0 diff --git a/Tests/RunCMake/list/EmptyFilter-stderr.txt b/Tests/RunCMake/list/EmptyFilter-stderr.txt new file mode 100644 index 0000000..e69de29 diff --git a/Tests/RunCMake/list/EmptyFilter.cmake b/Tests/RunCMake/list/EmptyFilter.cmake new file mode 100644 index 0000000..4048414 --- /dev/null +++ b/Tests/RunCMake/list/EmptyFilter.cmake @@ -0,0 +1,2 @@ +set(mylist "") +list(FILTER mylist "^FILTER_THIS_.+") diff --git a/Tests/RunCMake/list/FILTER-InvalidRegex-result.txt b/Tests/RunCMake/list/FILTER-InvalidRegex-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-InvalidRegex-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt b/Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt new file mode 100644 index 0000000..77151aa --- /dev/null +++ b/Tests/RunCMake/list/FILTER-InvalidRegex-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-InvalidRegex.cmake:2 \(list\): + list sub-command FILTER failed to compile regex "UHOH!\)\(". +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-InvalidRegex.cmake b/Tests/RunCMake/list/FILTER-InvalidRegex.cmake new file mode 100644 index 0000000..5cee0a6 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-InvalidRegex.cmake @@ -0,0 +1,2 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +list(FILTER mylist "UHOH!)(") diff --git a/Tests/RunCMake/list/FILTER-NotList-result.txt b/Tests/RunCMake/list/FILTER-NotList-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-NotList-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-NotList-stderr.txt b/Tests/RunCMake/list/FILTER-NotList-stderr.txt new file mode 100644 index 0000000..159c28d --- /dev/null +++ b/Tests/RunCMake/list/FILTER-NotList-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-NotList.cmake:2 \(list\): + list sub-command FILTER requires list to be present. +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-NotList.cmake b/Tests/RunCMake/list/FILTER-NotList.cmake new file mode 100644 index 0000000..87ab82e --- /dev/null +++ b/Tests/RunCMake/list/FILTER-NotList.cmake @@ -0,0 +1,2 @@ +unset(nosuchlist) +list(FILTER nosuchlist "^FILTER_THIS_.+") diff --git a/Tests/RunCMake/list/FILTER-TooManyArguments-result.txt b/Tests/RunCMake/list/FILTER-TooManyArguments-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-TooManyArguments-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-TooManyArguments-stderr.txt b/Tests/RunCMake/list/FILTER-TooManyArguments-stderr.txt new file mode 100644 index 0000000..44ab8ab --- /dev/null +++ b/Tests/RunCMake/list/FILTER-TooManyArguments-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-TooManyArguments.cmake:1 \(list\): + list sub-command FILTER requires two arguments. +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-TooManyArguments.cmake b/Tests/RunCMake/list/FILTER-TooManyArguments.cmake new file mode 100644 index 0000000..65df1da --- /dev/null +++ b/Tests/RunCMake/list/FILTER-TooManyArguments.cmake @@ -0,0 +1 @@ +list(FILTER mylist "^FILTER_THIS_.+" one_too_many) diff --git a/Tests/RunCMake/list/FILTER-Valid0-result.txt b/Tests/RunCMake/list/FILTER-Valid0-result.txt new file mode 100644 index 0000000..573541a --- /dev/null +++ b/Tests/RunCMake/list/FILTER-Valid0-result.txt @@ -0,0 +1 @@ +0 diff --git a/Tests/RunCMake/list/FILTER-Valid0-stderr.txt b/Tests/RunCMake/list/FILTER-Valid0-stderr.txt new file mode 100644 index 0000000..d9ba38d --- /dev/null +++ b/Tests/RunCMake/list/FILTER-Valid0-stderr.txt @@ -0,0 +1,2 @@ +^mylist was: FILTER_THIS_BIT;DO_NOT_FILTER_THIS;thisisanitem;FILTER_THIS_THING +mylist is: DO_NOT_FILTER_THIS;thisisanitem$ diff --git a/Tests/RunCMake/list/FILTER-Valid0.cmake b/Tests/RunCMake/list/FILTER-Valid0.cmake new file mode 100644 index 0000000..41f0e9e --- /dev/null +++ b/Tests/RunCMake/list/FILTER-Valid0.cmake @@ -0,0 +1,4 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +message("mylist was: ${mylist}") +list(FILTER mylist "^FILTER_THIS_.+") +message("mylist is: ${mylist}") diff --git a/Tests/RunCMake/list/RunCMakeTest.cmake b/Tests/RunCMake/list/RunCMakeTest.cmake index 25d6a03..c7d5311 100644 --- a/Tests/RunCMake/list/RunCMakeTest.cmake +++ b/Tests/RunCMake/list/RunCMakeTest.cmake @@ -1,5 +1,6 @@ include(RunCMake) +run_cmake(EmptyFilter) run_cmake(EmptyGet0) run_cmake(EmptyRemoveAt0) run_cmake(EmptyInsert-1) @@ -8,17 +9,22 @@ run_cmake(NoArguments) run_cmake(InvalidSubcommand) run_cmake(GET-CMP0007-WARN) +run_cmake(FILTER-InvalidRegex) run_cmake(GET-InvalidIndex) run_cmake(INSERT-InvalidIndex) run_cmake(REMOVE_AT-InvalidIndex) +run_cmake(FILTER-TooManyArguments) run_cmake(LENGTH-TooManyArguments) run_cmake(REMOVE_DUPLICATES-TooManyArguments) run_cmake(REVERSE-TooManyArguments) run_cmake(SORT-TooManyArguments) +run_cmake(FILTER-NotList) run_cmake(REMOVE_AT-NotList) run_cmake(REMOVE_DUPLICATES-NotList) run_cmake(REMOVE_ITEM-NotList) run_cmake(REVERSE-NotList) run_cmake(SORT-NotList) + +run_cmake(FILTER-Valid0) -- 2.6.4 From mantis at public.kitware.com Sat Jan 16 20:49:14 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 16 Jan 2016 20:49:14 -0500 Subject: [cmake-developers] [CMake 0015922]: Unable to configure Fortan through minGW with Visual Studio 14 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15922 ====================================================================== Reported By: Alex Ghosh Assigned To: ====================================================================== Project: CMake Issue ID: 15922 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-16 20:49 EST Last Modified: 2016-01-16 20:49 EST ====================================================================== Summary: Unable to configure Fortan through minGW with Visual Studio 14 Description: I am trying to compile a fortran/c++ code to build SNOPT for windows. I have extracted all the C++ related issues and are still having problems with the core Fortran compilation using Visual Studio and minGW. The sub-project is valid and will configure and make a minGW makefile just fine. When I try to then use the cmake_add_fortran_subdirectory() features, at the configuration level I receive the error output shown in the additional information. All attempts for for an win64 target. Steps to Reproduce: 1) Install Visual Studio 2015 (tested with Enterprise, but also occured with VS 2013 Community) 2) Install mingw-64 from sourceforge 3) See the attached CMakeList for the root directory. Substitute any fortran project for the sub-directory, which has a valid, functional CMakeLists.txt project. 4) Attempt to configure. Additional Information: The Fortran compiler identification is unknown The CXX compiler identification is MSVC 19.0.23506.0 Check for working Fortran compiler using: Visual Studio 14 2015 Win64 Check for working Fortran compiler using: Visual Studio 14 2015 Win64 -- broken CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.4/Modules/CMakeTestFortranCompiler.cmake:54 (message): The Fortran compiler "C:/mingw-64/mingw64/bin/gfortran.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/snopt74/build/CMakeFiles/CMakeTmp Run Build Command:"C:/Program Files (x86)/Microsoft Visual Studio 14.0/Common7/IDE/devenv.com" "CMAKE_TRY_COMPILE.sln" "/build" "Debug" "/project" "cmTC_f832e" Microsoft Visual Studio 2015 Version 14.0.24720.0. Copyright (C) Microsoft Corp. All rights reserved. Some errors occurred during migration. For more information, see the migration report: C:\snopt74\build\CMakeFiles\CMakeTmp\UpgradeLog.htm The operation could not be completed Use: devenv [solutionfile | projectfile | anyfile.ext] [switches] The first argument for devenv is usually a solution file or project file. You can also use any other file as the first argument if you want to have the file open automatically in an editor. When you enter a project file, the IDE looks for an .sln file with the same base name as the project file in the parent directory for the project file. If no such .sln file exists, then the IDE looks for a single .sln file that references the project. If no such single .sln file exists, then the IDE creates an unsaved solution with a default .sln file name that has the same base name as the project file. Command line builds: devenv solutionfile.sln /build [ solutionconfig ] [ /project projectnameorfile [ /projectconfig name ] ] Available command line switches: /Build Builds the solution or project with the specified solution configuration. For example "Debug". If multiple platforms are possible, the configuration name must be enclosed in quotes and contain platform name. For example: "Debug|Win32". /Clean Deletes build outputs. /Command Starts the IDE and executes the command. /Deploy Builds and then deploys the specified build configuration. /Edit Opens the specified files in a running instance of this application. If there are no running instances, it will start a new instance with a simplified window layout. /LCID Sets the default language in the IDE for the UI. /Log Logs IDE activity to the specified file for troubleshooting. /NoVSIP Disables the VSIP developer's license key for VSIP testing. /Out Appends the build log to a specified file. /Project Specifies the project to build, clean, or deploy. Must be used with /Build, /Rebuild, /Clean, or /Deploy. /ProjectConfig Overrides the project configuration specified in the solution configuration. For example "Debug". If multiple platforms are possible, the configuration name must be enclosed in quotes and contain platform name. For example: "Debug|Win32". Must be used with /Project. /Rebuild Cleans and then builds the solution or project with the specified configuration. /ResetSettings Restores the IDE's default settings, optionally resets to the specified VSSettings file. /ResetSkipPkgs Clears all SkipLoading tags added to VSPackages. /Run Compiles and runs the specified solution. /RunExit Compiles and runs the specified solution then closes the IDE. /SafeMode Launches the IDE in safe mode loading minimal windows. /Upgrade Upgrades the project or the solution and all projects in it. A backup of these files will be created as appropriate. Please see Help on 'Visual Studio Conversion Wizard' for more information on the backup process. Product-specific switches: /componentsDiff Compares two component folders. Requires three arguments: OptionalTfsServerCollectionUri SourceVersionedServerFolderPath TargetVersionedServerFolderPath If OptionalTfsServerCollectionUri is not provided, then an attempt is made to use the current TFS project collection. /debugexe Open the specified executable to be debugged. The remainder of the command line is passed to this executable as its arguments. /diff Compares two files. Takes four parameters: SourceFile, TargetFile, SourceDisplayName(optional), TargetDisplayName(optional) /openProjects /scc:git Opens committed project from git. Arguments: /repositoryUrl (/repo): /commitId (/id): /project: /solution (/sln): /displayId: /timestamp: /comment: /author: /openProjects /scc:tfs Opens versioned project from tfs. Arguments: /collection (/col): /version: /project: /solution (/sln): If OptionalTfsServerCollectionUri is not provided, then an attempt is made to use the current TFS project collection. /TfsLink Opens Team Explorer and launches a viewer for the provided artifact URI if one is registered. /useenv Use PATH, INCLUDE, LIBPATH, and LIB environment variables instead of IDE paths for VC++ builds. To attach the debugger from the command line, use: VsJITDebugger.exe -p CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:8 (project) Configuring incomplete, errors occurred! See also "C:/snopt74/build/CMakeFiles/CMakeOutput.log". See also "C:/snopt74/build/CMakeFiles/CMakeError.log". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-16 20:49 Alex Ghosh New Issue 2016-01-16 20:49 Alex Ghosh File Added: CMakeLists.txt ====================================================================== From ashley at awhetter.co.uk Sun Jan 17 11:35:35 2016 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Sun, 17 Jan 2016 16:35:35 +0000 Subject: [cmake-developers] [PATCH] Now prints warning when --build is not honored Message-ID: <1453048535-4038-1-git-send-email-ashley@awhetter.co.uk> As per issue 12641, this patch means that a warning is given when the "--build" option is ignored. I'm not sure if you'd want a different error message here. I feel like it might be better to print something about the fact that "--build" should be used after the binary tree has been generated, but I can't think of a good way to word it. Also this doesn't print a warning when "--build" is used in command mode. It felt unnecessary. --- Source/cmake.cxx | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Source/cmake.cxx b/Source/cmake.cxx index 8f6b952..27378c9 100644 --- a/Source/cmake.cxx +++ b/Source/cmake.cxx @@ -798,6 +798,11 @@ void cmake::SetArgs(const std::vector& args, this->SetGlobalGenerator(gen); } } + else if (arg.find("--build", 0) == 0) + { + cmSystemTools::Message("--build is not a valid option when " + "generating a project binary tree. Ignoring.", "Warning"); + } // no option assume it is the path to the source else { -- 2.6.4 From ashley at awhetter.co.uk Sun Jan 17 17:09:30 2016 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Sun, 17 Jan 2016 22:09:30 +0000 Subject: [cmake-developers] [PATCH] Now prints line number of cache parse error Message-ID: <1453068570-14837-1-git-send-email-ashley@awhetter.co.uk> To fix issue 11109, this patch implements the printing of the line number of the CMakeCache.txt file that causes a parse error when an error occurs. --- Source/cmCacheManager.cxx | 10 ++++++++-- Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 5 +++++ Tests/RunCMake/CommandLine/cache-bad-entry-result.txt | 1 + Tests/RunCMake/CommandLine/cache-bad-entry-stderr.txt | 1 + Tests/RunCMake/CommandLine/cache-bad-entry/CMakeCache.txt | 10 ++++++++++ Tests/RunCMake/CommandLine/cache-empty-entry-result.txt | 1 + Tests/RunCMake/CommandLine/cache-empty-entry-stderr.txt | 1 + Tests/RunCMake/CommandLine/cache-empty-entry/CMakeCache.txt | 7 +++++++ 8 files changed, 34 insertions(+), 2 deletions(-) create mode 100644 Tests/RunCMake/CommandLine/cache-bad-entry-result.txt create mode 100644 Tests/RunCMake/CommandLine/cache-bad-entry-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/cache-bad-entry/CMakeCache.txt create mode 100644 Tests/RunCMake/CommandLine/cache-empty-entry-result.txt create mode 100644 Tests/RunCMake/CommandLine/cache-empty-entry-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/cache-empty-entry/CMakeCache.txt diff --git a/Source/cmCacheManager.cxx b/Source/cmCacheManager.cxx index ce8af55..7466c29 100644 --- a/Source/cmCacheManager.cxx +++ b/Source/cmCacheManager.cxx @@ -64,12 +64,14 @@ bool cmCacheManager::LoadCache(const std::string& path, const char *realbuffer; std::string buffer; std::string entryKey; + unsigned int lineno = 0; while(fin) { // Format is key:type=value std::string helpString; CacheEntry e; cmSystemTools::GetLineFromStream(fin, buffer); + lineno++; realbuffer = buffer.c_str(); while(*realbuffer != '0' && (*realbuffer == ' ' || @@ -77,6 +79,7 @@ bool cmCacheManager::LoadCache(const std::string& path, *realbuffer == '\r' || *realbuffer == '\n')) { + if (*realbuffer == '\n') lineno++; realbuffer++; } // skip blank lines and comment lines @@ -96,6 +99,7 @@ bool cmCacheManager::LoadCache(const std::string& path, helpString += &realbuffer[2]; } cmSystemTools::GetLineFromStream(fin, buffer); + lineno++; realbuffer = buffer.c_str(); if(!fin) { @@ -138,8 +142,10 @@ bool cmCacheManager::LoadCache(const std::string& path, } else { - cmSystemTools::Error("Parse error in cache file ", cacheFile.c_str(), - ". Offending entry: ", realbuffer); + std::ostringstream error; + error << "Parse error in cache file " << cacheFile; + error << " on line " << lineno << ". Offending entry: " << realbuffer; + cmSystemTools::Error(error.str().c_str()); } } this->CacheMajorVersion = 0; diff --git a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake index e77ba1f..8068973 100644 --- a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake +++ b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake @@ -33,6 +33,11 @@ run_cmake_command(build-bad-dir run_cmake_command(build-bad-generator ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-bad-generator) +run_cmake_command(cache-bad-entry + ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-bad-entry/) +run_cmake_command(cache-empty-entry + ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-empty-entry/) + function(run_BuildDir) # Use a single build tree for a few tests without cleaning. set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/BuildDir-build) diff --git a/Tests/RunCMake/CommandLine/cache-bad-entry-result.txt b/Tests/RunCMake/CommandLine/cache-bad-entry-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/cache-bad-entry-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/cache-bad-entry-stderr.txt b/Tests/RunCMake/CommandLine/cache-bad-entry-stderr.txt new file mode 100644 index 0000000..35e8be2 --- /dev/null +++ b/Tests/RunCMake/CommandLine/cache-bad-entry-stderr.txt @@ -0,0 +1 @@ +^CMake Error: Parse error in cache file /home/ashley/workspace/cmake/Tests/RunCMake/CommandLine/cache-bad-entry/CMakeCache.txt on line 7. Offending entry: BAD ENTRY.* diff --git a/Tests/RunCMake/CommandLine/cache-bad-entry/CMakeCache.txt b/Tests/RunCMake/CommandLine/cache-bad-entry/CMakeCache.txt new file mode 100644 index 0000000..75cd7c2 --- /dev/null +++ b/Tests/RunCMake/CommandLine/cache-bad-entry/CMakeCache.txt @@ -0,0 +1,10 @@ +# This is a comment + +// That was an empty line. This isn't. +EMPTY_LINE:BOOL=FALSE + +// Uhoh! Here it comes +BAD ENTRY + +// This is fine +GOOD_ENTRY:BOOL=TRUE diff --git a/Tests/RunCMake/CommandLine/cache-empty-entry-result.txt b/Tests/RunCMake/CommandLine/cache-empty-entry-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/cache-empty-entry-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/cache-empty-entry-stderr.txt b/Tests/RunCMake/CommandLine/cache-empty-entry-stderr.txt new file mode 100644 index 0000000..3bd4af6 --- /dev/null +++ b/Tests/RunCMake/CommandLine/cache-empty-entry-stderr.txt @@ -0,0 +1 @@ +^CMake Error: Parse error in cache file /home/ashley/workspace/cmake/Tests/RunCMake/CommandLine/cache-empty-entry/CMakeCache.txt on line 5. Offending entry:.* diff --git a/Tests/RunCMake/CommandLine/cache-empty-entry/CMakeCache.txt b/Tests/RunCMake/CommandLine/cache-empty-entry/CMakeCache.txt new file mode 100644 index 0000000..44da1c9 --- /dev/null +++ b/Tests/RunCMake/CommandLine/cache-empty-entry/CMakeCache.txt @@ -0,0 +1,7 @@ +// This is valid +VALID:BOOL=TRUE + +// This isn't + +// One final entry +FINAL:BOOL=TRUE -- 2.6.4 From mantis at public.kitware.com Mon Jan 18 07:20:32 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 18 Jan 2016 07:20:32 -0500 Subject: [cmake-developers] [CMake 0015923]: Makefile is written/updated even if there are errors in cmake. Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15923 ====================================================================== Reported By: Mads Brix Assigned To: ====================================================================== Project: CMake Issue ID: 15923 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-18 07:20 EST Last Modified: 2016-01-18 07:20 EST ====================================================================== Summary: Makefile is written/updated even if there are errors in cmake. Description: If there is an error when running cmake (e.g. because of misspelled source file name) the Makefile will be written. This means that the next time one runs make, compilation is attempted (since the Makefile is up-to-date), and therefore the output is a compilation error, and not the (root cause) error from running cmake. With ninja this does not happen - the build.ninja is only written/updated if cmake execution is error free. Another situation is where a succesful build has been done, and error is then introduced (e.g. by spelling mistake when adding new source file). Correction would be to change Makefile generator to work like Ninja generator and only write/update Makefile if cmake is error free. Found with cmake 3.3.2, also present in 3.4.1. Steps to Reproduce: 1) create directories source, build.Ninja, build.Make. 2) create simple CMakeLists.txt in source directory: project (TestMakefileError) add_executable(TestMakefileError NonExistentFile.cc) 3) In build.Make run: "cmake ../source/" Error from cmake is reported, but Makefile is written, so when running make the cmake error is not reported. 4) In build.Ninja run. "cmake -G Ninja ../source/" Error from cmake is reported, but build.ninja is not written. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-18 07:20 Mads Brix New Issue ====================================================================== From mantis at public.kitware.com Mon Jan 18 09:24:50 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 18 Jan 2016 09:24:50 -0500 Subject: [cmake-developers] [CMake 0015924]: include_external_msproject does not specify project type Message-ID: <753b177641110dec41a0bb3f99d6d00b@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15924 ====================================================================== Reported By: Lars Assigned To: ====================================================================== Project: CMake Issue ID: 15924 Category: Documentation Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-18 09:24 EST Last Modified: 2016-01-18 09:24 EST ====================================================================== Summary: include_external_msproject does not specify project type Description: The documentation for include_external_msproject should state which project types that are supported. It appears .vcxproj project is supported but .csproj is not supported. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-18 09:24 Lars New Issue ====================================================================== From Harry at codexdigital.com Mon Jan 18 13:32:06 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 18 Jan 2016 18:32:06 +0000 Subject: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns Message-ID: <79534F1B-F1FE-4072-B8F4-86DA211AE617@codexdigital.com> Hello, I have just submitted a pull request (https://github.com/Kitware/CMake/pull/209). This passes through the output of the run (as well as the return value) so that users can access any output without using try_run. H Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Mon Jan 18 13:51:40 2016 From: ewmailing at gmail.com (Eric Wing) Date: Mon, 18 Jan 2016 10:51:40 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <5699597B.80108@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> Message-ID: On 1/15/16, Brad King wrote: > On 01/15/2016 09:47 AM, Eric Wing wrote: >>> That is the same as for C++. See CMAKE_PARSE_IMPLICIT_LINK_INFO and >> >> I looked at this file, but I still havne't groked what I need to do >> with this yet. > > Somehow we need to get swift to print verbose output about the command > line it uses to invoke the linker on the small test project CMake uses > while enabling the language. Then we need to parse that link line to > get the list of libraries and link directories. This can be a later > step once most other things work though. > >> However, I'm heavily debating if 'cc' or 'clang' is the right thing to >> do here. > > If the user sets LINKER_LANGUAGE to "C" and does not have main in Swift > then CMake will want to link with the C compiler. FYI, it is not actually > 'cc' but the CMAKE_C_COMPILER selected, which happens to be 'cc' often. > Anyway, we should go with CMAKE_Swift_COMPILER for now. > >> - First, CMake seems to be passing the flag -rdynamic to the link >> instructions, and this is causing a "unknown argument" error. I think >> this needs to be removed. I'm not sure where this flag is coming from. >> >> - Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument" >> error. As shown in the beginning of this thread, swiftc wants each >> argument to lead with -Xlinker (and there is no -Wl,) >> -Xlinker -rpath -Xlinker /foo/bar > > You'll need to add proper settings in files of the form > > Modules/Platform/--.cmake > Modules/Compiler/-.cmake > > such as > > Modules/Platform/Linux-Apple-Swift.cmake > Modules/Platform/Darwin-Apple-Swift.cmake > Modules/Compiler/Apple-Swift.cmake > > See Modules/Platform/Linux-NAG-Fortran.cmake for an example that > changes from -Wl,-rpath to -Xlinker -rpath. Similarly the > CMAKE_SHARED_LIBRARY_LINK__FLAGS must not have -rdynamic > in it. You're getting the settings from C right now because > your CMakeSwiftInformation.cmake file is copying them. Instead > leave all those out and add them as needed, preferably without > copying from C. > >> Additionally, I realized I should have some other variable besides >> >> Seems like I should have . I'm not sure what the >> correct way to create this is. > > All the languages use CMAKE__COMPILER as the front-end to > invoke for linking. There should not need to be a separate linker > value unless that is new to Swift semantics. > >> However, I currently employ a clever cheat. Since the compiler is >> 'swift', and the linker is 'swiftc', I just do >> 'c' > > So plain 'swift' cannot be used to drive the linker too? > >>> Note that for Ninja we actually convert our placeholders to Ninja >>> rule placeholders and then provide the values on the actual build >>> statement line. >> >> I actually don't' know anything about Ninja. I assume it is just a >> string translation at this point since I did the other? Any guidance >> on the mapping? > > Let's start with the Makefile generator. Porting the results to > the Ninja generator should not be too much work later. > >> So I need a new per-target variable in CMake for this and a way to >> inject it into the compiler flags, maybe something like this: >> >> " -frontend -c >> -import-objc-header -primary-file >> -emit-module -module-name -o >> ") >> >> With those two pieces, I think that actually makes add_executable() >> usable in the Makefile generator. > > The values for the placeholders are always determined in the context > of a specific target, so just "" should be > fine. > > Thanks, > -Brad > > This email is intended to be positive news, though there will be a lot of details about what still needs to be done or is not quite right yet. So the good news is I have a basic add_executable working with Swift on Linux via the Makefile generator. It works with all Swift files, or intermixed C+Swift files. Bridging header is also supported. I took one of my small, but non-trivial programs which does a lot with CMake to package up resources (images, audio, etc) and set rpaths and has lots of (C) dynamic libraries it links to which also get shipped with the bundle to make a self-contained app (rpath), and ported the core parts to Swift. CMake handled this pretty much transparently (had to enable_language(Swift), set the bridging header, and there are Swift Standard Library things to sort out later). So overall, I?m really happy with this. So now the details. - I?m still copying over some CFLAGS to Swift_FLAGS. For example, I couldn?t figure out what was providing the ?-I? flag for include paths. Rules like this still need to be rewritten for Swift. - TODO: I need to look at Swift's DEFINE system. - Link flags for -rpath are now rewritten (and -rdynamic is removed) - Added set_target_property(my_exe SWIFT_BRIDGING_HEADER ?/foo/bar/mybridge.h?). There is a token in the .cmake description for , but the full flag for -import-objc-header /foo/bar/mybridge.h is generated in the C++ side. This is because I need to dynamically decide whether this flag gets submitted or not based on whether a header was provided. (I can?t have a -import-objc-header without an argument.) - TODO: Unify SWIFT_BRIDGING_HEADER with the Xcode generator. Right now, we rely on the user setting the Xcode property directly which has a different name. Seems like if they set SWIFT_BRIDGING_HEADER, it should set the Xcode one for them. - TODO: Need to do Platform/Darwin-Apple-Swift.cmake. - Note: The new file is Linux-unknown-Swift.cmake. When I compile Swift myself, there is no company or organization identifier (swift --version) unlike the one Apple ships with Xcode, and CMake refers to the identifier as ?unknown?. I made the file reflect this, but maybe we should rename this later (maybe Swift_org). - Quirks/Bugs/Limitations about add_executable and the main symbol: I learned a few details and there are some quirks. Swift treats main.swift specially and will generate a main symbol. If you have a C main function, there is an edge case bug... If you have only 1 Swift file (and your C main), Swift will autogenerate a main symbol for Swift. This will cause a duplicate symbol problem and fail to link. If you have multiple Swift files (and your C main), this will link correctly, with the exception that you must not have a main.swift file. I still need to look deeper into how Xcode deals with this, but a quick glance, and I noticed an extra build stage between the object files and the linking. I think this extra stage in Xcode takes all the Swift object files and makes a .swiftmodule (library?) out of them and then may submit this to the linker. This could be the mechanism Xcode to avoid duplicate symbol problems, though as I said, I haven?t dissected this for real yet. But I?m thinking this may automatically come into more focus as we work on the library/module support for Swift. - To answer your question about whether ?swift? instead of ?swiftc? can be used for linking, I think the answer is yes, but I have been unable to figure out the correct incantation. I usually get a link failure and a bunch of console spew which contains non-ASCII characters and my terminal starts beeping and going crazy. It?s unpleasant to debug. And I can?t find one real world example of using swift for just linking. It?s either clang, ld, or swiftc. I?m also worried about how to determine the SDK paths when I?m not using swiftc, since I don?t provide that information explicitly when on Mac. Interesting Trivia: The swiftc linker calls clang++ under the hood for linking. - Swift Standard (or Core) Libraries: Swift comes with multiple standard libraries. There is swiftCore which I think contains a lot of the fundamental types like Int and Double and containers like Array and Dictionary. (It?s still fuzzy to me where the line between language and library begins.) https://developer.apple.com/library/ios/documentation/Swift/Reference/Swift_Int_Structure/index.html#//apple_ref/swift/struct/s:Si Then there is Foundation which is a Swift rewrite of Apple?s Cocoa (Obj-C) Foundation, which contains a large set of classes and convenience methods for non-GUI stuff, like NSString, NSURL, NSURLSession, etc. It is mostly incompletely right now on Linux. Then they also plan to include libdispatch and XCTest. https://swift.org/core-libraries/ Additionally, they provide a wrapper interface to the C standard library on the platform. This library has either the darwin or glibc name in it depending on situation. So I think something as simple as M_PI from C?s math.h will bring in the C library dependency. As far as I can tell, the swiftc linker knows how to automatically link to these libraries as needed depending if your code uses them or not. So the nice thing is that the CMake user scripts don?t currently need you to specify anything explicitly for these libraries. However, the one complication for me is that I am trying to ship stand-alone, redistributable application binaries, which means I need to copy these libraries with my application on non-Apple platforms. (I?ve already been setting path $ORIGIN on Linux). So I think CMake should provide some variables to the full paths to these libraries since users like me will want to refer to them. The question is whether these are set as part of the language bootstrap scripts, or a separate FindSwiftCoreLibraries.cmake module the user needs to manually include. (And unfortunately, for me, I don?t see a good way to know which libraries I actually need to copy without running ldd on the binary unless I know a priori. I know for now, I?m avoiding Foundation since it is unfinished and probably going to be huge binary and I don?t need it for my stuff.) Thanks, Eric From mantis at public.kitware.com Mon Jan 18 15:01:52 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 18 Jan 2016 15:01:52 -0500 Subject: [cmake-developers] [CMake 0015925]: Reproduce preprocessor definitions specified with target_compile_definitions() in Eclipse project file Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15925 ====================================================================== Reported By: Richard Lang Assigned To: ====================================================================== Project: CMake Issue ID: 15925 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-18 15:01 EST Last Modified: 2016-01-18 15:01 EST ====================================================================== Summary: Reproduce preprocessor definitions specified with target_compile_definitions() in Eclipse project file Description: preprocessor definitions specified in CMakeLists.txt file with add_definitions() statement are reproduced in Eclipse project file, but those specified with target_compile_definitions() are not. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-18 15:01 Richard Lang New Issue ====================================================================== From marc.chevrier at sap.com Tue Jan 19 03:58:11 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 19 Jan 2016 08:58:11 +0000 Subject: [cmake-developers] [CMAKE][PATCH] fix create_javah on Windows Message-ID: <9A6153AA-97EC-409B-A87C-E575DECEA157@sap.com> Hi, Attached is a patch fixing erroneous handling of CLASSPATH parameter for function create_javah (module UseJava). Update tests accordingly. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch Type: application/octet-stream Size: 3235 bytes Desc: 0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch URL: From mantis at public.kitware.com Tue Jan 19 08:52:29 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 19 Jan 2016 08:52:29 -0500 Subject: [cmake-developers] [CMake 0015926]: FindCURL.cmake exposed variables are empty Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15926 ====================================================================== Reported By: Lars K?hne Assigned To: ====================================================================== Project: CMake Issue ID: 15926 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-19 08:52 EST Last Modified: 2016-01-19 08:52 EST ====================================================================== Summary: FindCURL.cmake exposed variables are empty Description: The FindCURL.cmake module exposes variables CURL_INCLUDE_DIRS and CURL_LIBRARIES, among others. These variables are empty, even though CURL_FOUND is true. Internally, the FindCURL.cmake script uses CURL_INCLUDE_DIR and CURL_LIBRARY variables. These are set correctly to the found locations on my system. Using these instead of the variables documented in the reference and at the beginning of the script works. Steps to Reproduce: find_package(CURL REQUIRED) message(CURL_FOUND) # true on my system message(${CURL_INCLUDE_DIRS}) # this fails message(${CURL_LIBRARIES}) # this too message(${CURL_INCLUDE_DIR}) # this works message(${CURL_LIBRARY}) # this too ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-19 08:52 Lars K?hne New Issue ====================================================================== From mantis at public.kitware.com Tue Jan 19 10:07:24 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 19 Jan 2016 10:07:24 -0500 Subject: [cmake-developers] [CMake 0015927]: Escape semicolon "; " in CMake/CTest variables? Message-ID: <000baddcc61471fe4f623343e42e706b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15927 ====================================================================== Reported By: Gehua Yang Assigned To: ====================================================================== Project: CMake Issue ID: 15927 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-19 10:07 EST Last Modified: 2016-01-19 10:07 EST ====================================================================== Summary: Escape semicolon ";" in CMake/CTest variables? Description: My CMake-Controlled private build depends on a couple external libraries. On Windows, the build needs to find the dll files of external libraries in order to run the automated tests. The solution I came up with is to add those folders to the PATH environment variable for the build. Here is what I did in the CTest script (using CMake 3.4.1 for Windows): SET(MYPATH "$ENV{PATH}\;C:\\Gehua\\Code\\tbb\\tbb43_20150611oss\\bin\\intel64\\vc14") # set any extra envionment variables here # a. TBB path is needed to run tests # b. Use the "true" command-line plink for git's ssh use. SET (CTEST_ENVIRONMENT "GIT_SSH=c:\\Program Files (x86)\\PuTTY\\plink.exe" "PATH=${MYPATH}" ) MESSAGE(STATUS "env=${CTEST_ENVIRONMENT}") Here is the output from running the build from the code above: -- env=GIT_SSH=c:\Program Files (x86)\PuTTY\plink.exe;PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program Files\Broadcom\Broadcom 802.11 Network Adapter;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;%USERPROFILE%\.dnx\bin;C:\Program Files (x86)\Skype\Phone\;C:\Program Files\IDM Computer Solutions\UltraCompare;C:\Program Files\IDM Computer Solutions\UltraFinder\\;C:\Gehua\Code\tbb\tbb43_20150611oss\bin\intel64\vc14 But this change does NOT work for the tests. The tests failed without execution. I suspected that it still did not find the depending dll files. So I added the following code in a simple test file: std::cout << "env PATH=" << getenv ("PATH") << '\n'; std::cout << "env GIT_SSH=" << getenv ("GIT_SSH") << '\n'; The output is : env PATH=C:\ProgramData\Oracle\Java\javapath env GIT_SSH=c:\Program Files (x86)\PuTTY\plink.exe As one can see, The PATH variable content was truncated at the semicolon mark (";"). It is not surprising outcome as CMake use semicolon as delimiter of list elements. But in this particular case, I am seeking for a way to escape the semicolons so that CMake/CTest treats it as an integral part of the string. Is there a way to do it? Steps to Reproduce: SET(MYPATH "$ENV{PATH}\;C:\\Gehua\\Code\\tbb\\tbb43_20150611oss\\bin\\intel64\\vc14") # set any extra envionment variables here # a. TBB path is needed to run tests # b. Use the "true" command-line plink for git's ssh use. SET (CTEST_ENVIRONMENT "GIT_SSH=c:\\Program Files (x86)\\PuTTY\\plink.exe" "PATH=${MYPATH}" ) MESSAGE(STATUS "env=${CTEST_ENVIRONMENT}") But the result is: PATH=C:\ProgramData\Oracle\Java\javapath GIT_SSH=c:\Program Files (x86)\PuTTY\plink.exe ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-19 10:07 Gehua Yang New Issue ====================================================================== From brad.king at kitware.com Tue Jan 19 10:41:13 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 10:41:13 -0500 Subject: [cmake-developers] [PATCH] Now prints line number of cache parse error In-Reply-To: <1453068570-14837-1-git-send-email-ashley@awhetter.co.uk> References: <1453068570-14837-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <569E5919.4020606@kitware.com> On 01/17/2016 05:09 PM, Ashley Whetter wrote: > To fix issue 11109, this patch implements the printing of the line number of the > CMakeCache.txt file that causes a parse error when an error occurs. Thanks! Applied with minor fix to the test suite: Print line number of cache parse errors (#11109) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77cd74a3 -Brad From brad.king at kitware.com Tue Jan 19 10:42:18 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 10:42:18 -0500 Subject: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns In-Reply-To: <79534F1B-F1FE-4072-B8F4-86DA211AE617@codexdigital.com> References: <79534F1B-F1FE-4072-B8F4-86DA211AE617@codexdigital.com> Message-ID: <569E595A.3050205@kitware.com> On 01/18/2016 01:32 PM, Harry Mallon wrote: > https://github.com/Kitware/CMake/pull/209 > This passes through the output of the run (as well as the return value) > so that users can access any output without using try_run. Thanks. The signature of the macro takes a variable for the return value to be stored. We need something similar to control the name of the variable used to store the output. This could either be done with an optional/named argument or simply by documenting that the output will come in `_OUTPUT`. We also need to define what happens when the check has already been run. The normal `` result is cached to prevent repeat runs of the check. I don't think we can reasonably cache the entire output of the run and provide it on later re-runs of CMake when the check does not actually run. OTOH your use case for extracting versions may have other solutions. We generally try to avoid try_run because it only works when the toolchain targets the host architecture and so does not work when cross compiling in general. Look at what Modules/CMakeDetermineCompilerId.cmake does to extract the compiler id and version information. It also leaves files in build trees under CMakeFiles/${CMAKE_VERSION}/CompilerIdC that you can see. Basically it encodes the needed information in strings that can be extracted from the binaries without running them. -Brad From brad.king at kitware.com Tue Jan 19 10:42:37 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 10:42:37 -0500 Subject: [cmake-developers] [CMAKE][PATCH] fix create_javah on Windows In-Reply-To: <9A6153AA-97EC-409B-A87C-E575DECEA157@sap.com> References: <9A6153AA-97EC-409B-A87C-E575DECEA157@sap.com> Message-ID: <569E596D.8040202@kitware.com> On 01/19/2016 03:58 AM, CHEVRIER, Marc wrote: > Attached is a patch fixing erroneous handling of CLASSPATH > Update tests accordingly. Thanks, applied: UseJava: Fix create_javah CLASSPATH handling on Windows https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18c3714f -Brad From brad.king at kitware.com Tue Jan 19 10:42:58 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 10:42:58 -0500 Subject: [cmake-developers] [PATCH] Now prints warning when --build is not honored In-Reply-To: <1453048535-4038-1-git-send-email-ashley@awhetter.co.uk> References: <1453048535-4038-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <569E5982.7050205@kitware.com> On 01/17/2016 11:35 AM, Ashley Whetter wrote: > As per issue 12641, this patch means that a warning is given when the "--build" > option is ignored. Thanks for working on this. > I'm not sure if you'd want a different error message here. Ideally all unused arguments would get a warning but that will take significant refactoring of how arguments are stored and passed around internally. > I feel like it might be better to print something about the fact that "--build" > should be used after the binary tree has been generated, > but I can't think of a good way to word it. How about: Ignoring option '--build' because it is meant to be used only to drive an already-generated project build system. ? Please also add a test somewhere in Tests/RunCMake for this. Thanks, -Brad From brad.king at kitware.com Tue Jan 19 10:43:08 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 10:43:08 -0500 Subject: [cmake-developers] [PATCH] Added FILTER subcommand to list command In-Reply-To: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> References: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <569E598C.4050109@kitware.com> On 01/16/2016 12:10 PM, Ashley Whetter wrote: > In response to issue 0003986, I've implemented a FILTER subcommand to the "list" > command that filters a list using a regular expression. Nice work. The change looks good except I'd like to bikeshed the name of the option. This is the first list() API that will use a regular expression as an argument, so I think "REGEX" should appear in the name, e.g. "FILTER_REGEX". Also the name should clarify whether the filter result includes or excludes the matches. Perhaps list(FILTER_REGEX_INCLUDE ) ? Alternatively the name could still be "FILTER" and there could be named arguments to control the rest of the details. I have no preference but would welcome other opinions. Thanks, -Brad From marc.chevrier at sap.com Tue Jan 19 11:19:16 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 19 Jan 2016 16:19:16 +0000 Subject: [cmake-developers] [PATCH] Added FILTER subcommand to list command In-Reply-To: <569E598C.4050109@kitware.com> References: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> <569E598C.4050109@kitware.com> Message-ID: I am in favour to use FILTER keyword and named arguments for filter behaviour. I think this approach is more elegant and also more flexible for any future enhancements. On 19/01/16 16:43, "cmake-developers on behalf of Brad King" wrote: >On 01/16/2016 12:10 PM, Ashley Whetter wrote: >> In response to issue 0003986, I've implemented a FILTER subcommand to the "list" >> command that filters a list using a regular expression. > >Nice work. The change looks good except I'd like to bikeshed the name >of the option. This is the first list() API that will use a regular >expression as an argument, so I think "REGEX" should appear in the >name, e.g. "FILTER_REGEX". Also the name should clarify whether the >filter result includes or excludes the matches. Perhaps > > list(FILTER_REGEX_INCLUDE ) > >? Alternatively the name could still be "FILTER" and there could >be named arguments to control the rest of the details. I have no >preference but would welcome other opinions. > >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 From brad.king at kitware.com Tue Jan 19 11:28:59 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 11:28:59 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> Message-ID: <569E644B.2020404@kitware.com> On 01/18/2016 01:51 PM, Eric Wing wrote: > So the good news is I have a basic add_executable working with Swift > on Linux via the Makefile generator. > > It works with all Swift files, or intermixed C+Swift files. Bridging > header is also supported. Great! > - I?m still copying over some CFLAGS to Swift_FLAGS. For example, I > couldn?t figure out what was providing the ?-I? flag for include > paths. Rules like this still need to be rewritten for Swift. Try adding to CMakeSwiftInformation: set(CMAKE_INCLUDE_FLAG_Swift -I) > - TODO: I need to look at Swift's DEFINE system. Yes. After we get things building correctly the first time then we'll also need to see about adding needed dependencies to the build system. > - Note: The new file is Linux-unknown-Swift.cmake. When I compile > Swift myself, there is no company or organization identifier (swift > --version) unlike the one Apple ships with Xcode, and CMake refers to > the identifier as ?unknown?. I made the file reflect this, but maybe > we should rename this later (maybe Swift_org). In an earlier Swift thread there was discussion about the name of the compiler id and ``Apple`` was chosen because that is the vendor of their version. We definitely need to choose an id besides "unknown" for this. Perhaps ``SwiftOrg``? Also, we need a good way to check the id. We could use `--version` if necessary but do we know whether the language provides any kind of identifier for code to use for conditional compilation? > - To answer your question about whether ?swift? instead of ?swiftc? > can be used for linking, I think the answer is yes, but I have been > unable to figure out the correct incantation. Okay. Let's go with the ``c`` hack until we know more. I'd prefer not to have to expose a separate setting for the link driver only to remove it later. > - Swift Standard (or Core) Libraries: Swift comes with multiple > standard libraries. [snip] > I think CMake should provide some variables to the full paths to > these libraries since users like me will want to refer to them. Perhaps, but we currently don't do that for any other languages. We do provide CMAKE_{C,CXX,Fortran}_IMPLICIT_LINK_DIRECTORIES listing directories that may contain the standard libraries. This is the same as the information needed to use the C linker to mix languages that we previously discussed trying to extract for Swift. -Brad From rleigh at codelibre.net Tue Jan 19 11:39:22 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 19 Jan 2016 16:39:22 +0000 Subject: [cmake-developers] [patch] New find module FindXalanC Message-ID: <569E66BA.9020406@codelibre.net> Merged into next from the staging branch "xalanc" for review and testing. Includes a couple of unit tests to validate. Since it depends on XercesC, I hope what I've done here for the imported and non-imported target cases is OK. I've tested on Linux and Windows. Regards, Roger From mantis at public.kitware.com Tue Jan 19 11:47:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 19 Jan 2016 11:47:15 -0500 Subject: [cmake-developers] [CMake 0015928]: FindwxWidgets Fails Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15928 ====================================================================== Reported By: deaths_soul Assigned To: ====================================================================== Project: CMake Issue ID: 15928 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-19 11:47 EST Last Modified: 2016-01-19 11:47 EST ====================================================================== Summary: FindwxWidgets Fails Description: When I try to use FindwxWidgets in CMake 3.4.1, I keep getting the following error: CMake Error at /usr/share/cmake/Modules/FindwxWidgets.cmake:870 (message): wxWidgets wx/version.h file not found in /home/User/Code/wxWidgets/win_build32/lib/wx/include/i686-w64-mingw32-msw-unicode-static-3.0;/home/User/Code/wxWidgets/include. Even though the file exists and I've even made a symlink in the other location to make sure. In either case, I get that error. However, if I downgrade to CMake 3.3.2, everything works as it should. The full path to wx/version.h is /home/User/Code/wxWidgets/include/wx/version.h. In CMakeCache.txt, the _filename variable is set as follows: _filename:FILEPATH=_filename-NOTFOUND It's set to this value in both the CMakeCache.txt for 3.3.2 and 3.4.1. In testing, I even deleted the working directory and started from a clean slate and the issue still occurred with 3.4.1. This is under Fedora 23 and cross-compiling using MinGW. The wxWidgets library is self-compiled. CMAKE_FIND_ROOT_PATH is set to usr/x86_64-w64-mingw32/sys-root/mingw or /usr/i686-w64-mingw32/sys-root/mingw depending on which architecture I'm building for. I use a mixture of libraries from the repos and self-built, though. CMAKE_FIND_ROOT_PATH_MODE_INCLUDE is set to ONLY. Manually passing -D_filename=/home/User/Code/wxWidgets/include/wx/version.h when I run the CMake configuration fixes the issue. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-19 11:47 deaths_soul New Issue ====================================================================== From brad.king at kitware.com Tue Jan 19 11:50:24 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 11:50:24 -0500 Subject: [cmake-developers] [patch] New find module FindXalanC In-Reply-To: <569E66BA.9020406@codelibre.net> References: <569E66BA.9020406@codelibre.net> Message-ID: <569E6950.9070006@kitware.com> On 01/19/2016 11:39 AM, Roger Leigh wrote: > Merged into next from the staging branch "xalanc" for review and > testing. Includes a couple of unit tests to validate. Since it depends > on XercesC, I hope what I've done here for the imported and non-imported > target cases is OK. Thanks. Please also add a Help/release/dev/FindXalanC.rst release note that mentions the new module. I've updated one of our nightly testing machines to enable the new test for this topic. > +find_package(XercesC 3.0.0 REQUIRED) Please add a comment here justifying use of this particular version number. Explain that/why it does not depend on the XalanC version requested. > +# ``XalanC_LIBRARIES`` > +# Xalan libraries to be linked; note ``XercesC_LIBRARIES`` is also > +# required Our convention is to include dependencies in reported values automatically. See FindPNG for its use of ZLIB, for example. Thanks, -Brad From sam.thursfield at codethink.co.uk Tue Jan 19 11:50:35 2016 From: sam.thursfield at codethink.co.uk (Sam Thursfield) Date: Tue, 19 Jan 2016 16:50:35 +0000 Subject: [cmake-developers] [PATCH] FindALSA: Create an imported ALSA:ASound target Message-ID: <1453222235-27596-1-git-send-email-sam.thursfield@codethink.co.uk> Imported targets are now the recommended way of dealing with external library dependencies. The documentation for FindALSA is rewritten slightly. This commit also adds a test case, you can run it like this: cmake ... -DCMake_TEST_FindALSA=ON ctest -R FindALSA --output-on-failure The testcase requires the libasound library and headers to be installed. This change is based on the equivalent changes to FindTIFF, found in commit ebaca6290d2c0be7dec22452389632949a700d28. --- Modules/FindALSA.cmake | 51 ++++++++++++++++++++++++++++---------- Tests/CMakeLists.txt | 4 +++ Tests/FindALSA/CMakeLists.txt | 10 ++++++++ Tests/FindALSA/Test/CMakeLists.txt | 16 ++++++++++++ Tests/FindALSA/Test/main.c | 12 +++++++++ 5 files changed, 80 insertions(+), 13 deletions(-) create mode 100644 Tests/FindALSA/CMakeLists.txt create mode 100644 Tests/FindALSA/Test/CMakeLists.txt create mode 100644 Tests/FindALSA/Test/main.c diff --git a/Modules/FindALSA.cmake b/Modules/FindALSA.cmake index 5c30eb9..7f98250 100644 --- a/Modules/FindALSA.cmake +++ b/Modules/FindALSA.cmake @@ -2,28 +2,42 @@ # FindALSA # -------- # -# Find alsa +# Find the alsa libraries (asound). # -# Find the alsa libraries (asound) +# Imported targets +# ^^^^^^^^^^^^^^^^ # -# :: +# This module defines the following :prop_tgt:`IMPORTED` target: # -# This module defines the following variables: -# ALSA_FOUND - True if ALSA_INCLUDE_DIR & ALSA_LIBRARY are found -# ALSA_LIBRARIES - Set when ALSA_LIBRARY is found -# ALSA_INCLUDE_DIRS - Set when ALSA_INCLUDE_DIR is found +# ``ALSA::ASound`` +# The asound library, if found. # +# Result variables +# ^^^^^^^^^^^^^^^^ # +# This module will set the following variables in your project: # -# :: +# ``ALSA_FOUND`` +# true if the ALSA headers and libraries were found +# ``ALSA_INCLUDE_DIRS`` +# the directory containing the ALSA headers +# ``ALSA_LIBRARIES`` +# ALSA libraries to be linked. # -# ALSA_INCLUDE_DIR - where to find asoundlib.h, etc. -# ALSA_LIBRARY - the asound library -# ALSA_VERSION_STRING - the version of alsa found (since CMake 2.8.8) +# Cache variables +# ^^^^^^^^^^^^^^^ +# +# The following cache variables may also be set. +# +# ``ALSA_INCLUDE_DIR`` +# the directory containing the ALSA headers +# ``ALSA_LIBRARY`` +# the path to the ALSA ASound library #============================================================================= # Copyright 2009-2011 Kitware, Inc. # Copyright 2009-2011 Philip Lowman +# Copyright 2016 Raumfeld # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. @@ -58,8 +72,19 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(ALSA VERSION_VAR ALSA_VERSION_STRING) if(ALSA_FOUND) - set( ALSA_LIBRARIES ${ALSA_LIBRARY} ) - set( ALSA_INCLUDE_DIRS ${ALSA_INCLUDE_DIR} ) + set(ALSA_VERSION ${ALSA_VERSION_STRING}) + set(ALSA_LIBRARIES ${ALSA_LIBRARY}) + set(ALSA_INCLUDE_DIRS ${ALSA_INCLUDE_DIR}) + + if(NOT TARGET ALSA::ASound) + add_library(ALSA::ASound UNKNOWN IMPORTED) + set_target_properties(ALSA::ASound PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES "C" + IMPORTED_LOCATION "${ALSA_LIBRARY}" + INTERFACE_INCLUDE_DIRECTORIES "${ALSA_INCLUDE_DIRS}" + INTERFACE_LIBRARIES "${ALSA_LIBRARY}" + ) + endif() endif() mark_as_advanced(ALSA_INCLUDE_DIR ALSA_LIBRARY) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index 043b757..26b0cee 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1355,6 +1355,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() endif() + if(CMake_TEST_FindALSA) + add_subdirectory(FindALSA) + endif() + if(CMake_TEST_FindBoost) add_subdirectory(FindBoost) endif() diff --git a/Tests/FindALSA/CMakeLists.txt b/Tests/FindALSA/CMakeLists.txt new file mode 100644 index 0000000..891f7a4 --- /dev/null +++ b/Tests/FindALSA/CMakeLists.txt @@ -0,0 +1,10 @@ +add_test(NAME FindALSA.Test COMMAND + ${CMAKE_CTEST_COMMAND} -C $ + --build-and-test + "${CMake_SOURCE_DIR}/Tests/FindALSA/Test" + "${CMake_BINARY_DIR}/Tests/FindALSA/Test" + ${build_generator_args} + --build-project TestFindALSA + --build-options ${build_options} + --test-command ${CMAKE_CTEST_COMMAND} -V -C $ + ) diff --git a/Tests/FindALSA/Test/CMakeLists.txt b/Tests/FindALSA/Test/CMakeLists.txt new file mode 100644 index 0000000..2dae457 --- /dev/null +++ b/Tests/FindALSA/Test/CMakeLists.txt @@ -0,0 +1,16 @@ +cmake_minimum_required(VERSION 3.4) +project(TestFindALSA C) +include(CTest) + +find_package(ALSA REQUIRED) + +add_definitions(-DCMAKE_ASOUNDLIB_EXPECTED_VERSION=\"${ALSA_VERSION}\") + +add_executable(test_tgt main.c) +target_link_libraries(test_tgt ALSA::ASound) +add_test(NAME test_tgt COMMAND test_tgt) + +add_executable(test_vars main.c) +target_include_directories(test_vars PRIVATE ${ALSA_INCLUDE_DIRS}) +target_link_libraries(test_vars PRIVATE ${ALSA_LIBRARIES}) +add_test(NAME test_vars COMMAND test_vars) diff --git a/Tests/FindALSA/Test/main.c b/Tests/FindALSA/Test/main.c new file mode 100644 index 0000000..9240c7b --- /dev/null +++ b/Tests/FindALSA/Test/main.c @@ -0,0 +1,12 @@ +#include +#include +#include + +int main() +{ + const char *asoundlib_version; + asoundlib_version = snd_asoundlib_version(); + assert (strcmp(asoundlib_version, CMAKE_ASOUNDLIB_EXPECTED_VERSION) == 0); + + return 0; +} -- 2.4.3 From rleigh at codelibre.net Tue Jan 19 12:02:39 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 19 Jan 2016 17:02:39 +0000 Subject: [cmake-developers] [patch] New find module FindXalanC In-Reply-To: <569E6950.9070006@kitware.com> References: <569E66BA.9020406@codelibre.net> <569E6950.9070006@kitware.com> Message-ID: <569E6C2F.4020209@codelibre.net> On 19/01/2016 16:50, Brad King wrote: > On 01/19/2016 11:39 AM, Roger Leigh wrote: >> Merged into next from the staging branch "xalanc" for review and >> testing. Includes a couple of unit tests to validate. Since it depends >> on XercesC, I hope what I've done here for the imported and non-imported >> target cases is OK. > > Thanks. Please also add a Help/release/dev/FindXalanC.rst release note > that mentions the new module. Done. I can add more detail if needed here. > I've updated one of our nightly testing machines to enable the new test > for this topic. > >> +find_package(XercesC 3.0.0 REQUIRED) > > Please add a comment here justifying use of this particular version number. > Explain that/why it does not depend on the XalanC version requested. I think this is an assumption leaking from my own usage of it. I've removed the version here. >> +# ``XalanC_LIBRARIES`` >> +# Xalan libraries to be linked; note ``XercesC_LIBRARIES`` is also >> +# required > > Our convention is to include dependencies in reported values automatically. > See FindPNG for its use of ZLIB, for example. OK, I've updated this to match. Thanks, Roger From Harry at codexdigital.com Tue Jan 19 12:03:31 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 19 Jan 2016 17:03:31 +0000 Subject: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns In-Reply-To: <569E595A.3050205@kitware.com> References: <79534F1B-F1FE-4072-B8F4-86DA211AE617@codexdigital.com> <569E595A.3050205@kitware.com> Message-ID: <8A1F7886-A48A-4ABA-92C3-4636C0CD37D5@codexdigital.com> Inline responses. Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 > On 19 Jan 2016, at 15:42, Brad King wrote: > > On 01/18/2016 01:32 PM, Harry Mallon wrote: >> https://github.com/Kitware/CMake/pull/209 >> This passes through the output of the run (as well as the return value) >> so that users can access any output without using try_run. > > Thanks. The signature of the macro takes a variable for the return value > to be stored. We need something similar to control the name of the variable > used to store the output. This could either be done with an optional/named > argument or simply by documenting that the output will come in `_OUTPUT`. Sounds sensible > We also need to define what happens when the check has already been run. > The normal `` result is cached to prevent repeat runs of the check. > I don't think we can reasonably cache the entire output of the run and > provide it on later re-runs of CMake when the check does not actually run. I agree, we shouldn't be caching all of that > OTOH your use case for extracting versions may have other solutions. > We generally try to avoid try_run because it only works when the toolchain > targets the host architecture and so does not work when cross compiling > in general. Look at what Modules/CMakeDetermineCompilerId.cmake does to > extract the compiler id and version information. It also leaves files > in build trees under CMakeFiles/${CMAKE_VERSION}/CompilerIdC that you > can see. Basically it encodes the needed information in strings that > can be extracted from the binaries without running them. I have read CMakeDetermineCompilerId.cmake but I can't see how I can use that kind of an approach. Having static const char* set by the preprocessor is a good idea for the reasons that you mention but I cannot retrieve a version number without linking and interrogating the library. I could be missing something though. H From sam.thursfield at codethink.co.uk Tue Jan 19 12:43:05 2016 From: sam.thursfield at codethink.co.uk (Sam Thursfield) Date: Tue, 19 Jan 2016 17:43:05 +0000 Subject: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target Message-ID: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> Imported targets are now the recommended way of dealing with external library dependencies. The documentation for FindPNG is rewritten slightly. This commit also adds a test case, you can run it like this: cmake ... -DCMake_TEST_FindPNG=ON ctest -R FindPNG --output-on-failure The testcase requires the libpng library and headers to be installed. This change is based on the equivalent changes to FindTIFF, found in commit ebaca6290d2c0be7dec22452389632949a700d28. https://cmake.org/Bug/view.php?id=15911 --- Help/release/dev/FindPNG-imported-targets.rst | 4 +++ Modules/FindPNG.cmake | 50 +++++++++++++++++++++++---- Tests/CMakeLists.txt | 4 +++ Tests/FindPNG/CMakeLists.txt | 10 ++++++ Tests/FindPNG/Test/CMakeLists.txt | 16 +++++++++ Tests/FindPNG/Test/main.c | 20 +++++++++++ 6 files changed, 97 insertions(+), 7 deletions(-) create mode 100644 Help/release/dev/FindPNG-imported-targets.rst create mode 100644 Tests/FindPNG/CMakeLists.txt create mode 100644 Tests/FindPNG/Test/CMakeLists.txt create mode 100644 Tests/FindPNG/Test/main.c diff --git a/Help/release/dev/FindPNG-imported-targets.rst b/Help/release/dev/FindPNG-imported-targets.rst new file mode 100644 index 0000000..e0d0ab1 --- /dev/null +++ b/Help/release/dev/FindPNG-imported-targets.rst @@ -0,0 +1,4 @@ +FindPNG-imported-targets +------------------------ + +* The :module:`FindPNG` module now provides imported targets. diff --git a/Modules/FindPNG.cmake b/Modules/FindPNG.cmake index 7cf3f22..d1d5e67 100644 --- a/Modules/FindPNG.cmake +++ b/Modules/FindPNG.cmake @@ -2,13 +2,20 @@ # FindPNG # ------- # -# Find the native PNG includes and library +# Find libpng, the official reference library for the PNG image format. # +# Imported targets +# ^^^^^^^^^^^^^^^^ # +# This module defines the following :prop_tgt:`IMPORTED` target: # -# This module searches libpng, the library for working with PNG images. +# ``PNG::PNG`` +# The libpng library, if found. # -# It defines the following variables +# Result variables +# ^^^^^^^^^^^^^^^^ +# +# This module will set the following variables in your project: # # ``PNG_INCLUDE_DIRS`` # where to find png.h, etc. @@ -22,19 +29,22 @@ # ``PNG_VERSION_STRING`` # the version of the PNG library found (since CMake 2.8.8) # -# Also defined, but not for general use are +# Obsolete variables +# ^^^^^^^^^^^^^^^ +# +# The following variables may also be set, for backwards compatibility: # # ``PNG_LIBRARY`` # where to find the PNG library. -# -# For backward compatiblity the variable PNG_INCLUDE_DIR is also set. -# It has the same value as PNG_INCLUDE_DIRS. +# ``PNG_INCLUDE_DIR`` +# where to find the PNG headers (same as PNG_INCLUDE_DIRS) # # Since PNG depends on the ZLib compression library, none of the above # will be defined unless ZLib can be found. #============================================================================= # Copyright 2002-2009 Kitware, Inc. +# Copyright 2016 Raumfeld # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. @@ -105,6 +115,32 @@ if(ZLIB_FOUND) endif() endif () + if(NOT TARGET PNG::PNG) + add_library(PNG::PNG UNKNOWN IMPORTED) + set_target_properties(PNG::PNG PROPERTIES + INTERFACE_COMPILE_DEFINITIONS "${PNG_DEFINITIONS}" + INTERFACE_INCLUDE_DIRECTORIES "${PNG_INCLUDE_DIRS}" + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") + if(EXISTS "${PNG_LIBRARY}") + set_target_properties(PNG::PNG PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES "C" + IMPORTED_LOCATION "${PNG_LIBRARY}") + endif() + if(EXISTS "${PNG_LIBRARY_DEBUG}") + set_property(TARGET PNG::PNG APPEND PROPERTY + IMPORTED_CONFIGURATIONS DEBUG) + set_target_properties(PNG::PNG PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C" + IMPORTED_LOCATION_DEBUG "${PNG_LIBRARY_DEBUG}") + endif() + if(EXISTS "${PNG_LIBRARY_RELEASE}") + set_property(TARGET PNG::PNG APPEND PROPERTY + IMPORTED_CONFIGURATIONS RELEASE) + set_target_properties(PNG::PNG PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C" + IMPORTED_LOCATION_RELEASE "${PNG_LIBRARY_RELEASE}") + endif() + endif() endif () if (PNG_PNG_INCLUDE_DIR AND EXISTS "${PNG_PNG_INCLUDE_DIR}/png.h") diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index 043b757..3cca77b 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1375,6 +1375,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release add_subdirectory(FindOpenSSL) endif() + if(CMake_TEST_FindPNG) + add_subdirectory(FindPNG) + endif() + if(CMake_TEST_FindTIFF) add_subdirectory(FindTIFF) endif() diff --git a/Tests/FindPNG/CMakeLists.txt b/Tests/FindPNG/CMakeLists.txt new file mode 100644 index 0000000..c665b67 --- /dev/null +++ b/Tests/FindPNG/CMakeLists.txt @@ -0,0 +1,10 @@ +add_test(NAME FindPNG.Test COMMAND + ${CMAKE_CTEST_COMMAND} -C $ + --build-and-test + "${CMake_SOURCE_DIR}/Tests/FindPNG/Test" + "${CMake_BINARY_DIR}/Tests/FindPNG/Test" + ${build_generator_args} + --build-project TestFindPNG + --build-options ${build_options} + --test-command ${CMAKE_CTEST_COMMAND} -V -C $ + ) diff --git a/Tests/FindPNG/Test/CMakeLists.txt b/Tests/FindPNG/Test/CMakeLists.txt new file mode 100644 index 0000000..ad50011 --- /dev/null +++ b/Tests/FindPNG/Test/CMakeLists.txt @@ -0,0 +1,16 @@ +cmake_minimum_required(VERSION 3.4) +project(TestFindPNG C) +include(CTest) + +find_package(PNG REQUIRED) + +add_definitions(-DCMAKE_EXPECTED_PNG_VERSION="${PNG_VERSION_STRING}") + +add_executable(test_tgt main.c) +target_link_libraries(test_tgt PNG::PNG) +add_test(NAME test_tgt COMMAND test_tgt) + +add_executable(test_var main.c) +target_include_directories(test_var PRIVATE ${PNG_INCLUDE_DIRS}) +target_link_libraries(test_var PRIVATE ${PNG_LIBRARIES}) +add_test(NAME test_var COMMAND test_var) diff --git a/Tests/FindPNG/Test/main.c b/Tests/FindPNG/Test/main.c new file mode 100644 index 0000000..27e1478 --- /dev/null +++ b/Tests/FindPNG/Test/main.c @@ -0,0 +1,20 @@ +#include +#include +#include + +int main() +{ + png_uint_32 png_version; + char png_version_string[16]; + + png_version = png_access_version_number (); + + snprintf (png_version_string, 16, "%i.%i.%i", + png_version / 10000, + (png_version % 10000) / 100, + png_version % 100); + + assert (strcmp(png_version_string, CMAKE_EXPECTED_PNG_VERSION) == 0); + + return 0; +} -- 2.4.3 From brad.king at kitware.com Tue Jan 19 14:14:45 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 14:14:45 -0500 Subject: [cmake-developers] [patch] New find module FindXalanC In-Reply-To: <569E6C2F.4020209@codelibre.net> References: <569E66BA.9020406@codelibre.net> <569E6950.9070006@kitware.com> <569E6C2F.4020209@codelibre.net> Message-ID: <569E8B25.2070105@kitware.com> On 01/19/2016 12:02 PM, Roger Leigh wrote: >>> +find_package(XercesC 3.0.0 REQUIRED) > > I think this is an assumption leaking from my own usage of it. I've > removed the version here. Thanks. The CMakeOnly.AllFindModules and FindModulesExecuteAll tests fail when XercesC is not available. It should be required only if XalanC is required (XalanC_FIND_REQUIRED). -Brad From brad.king at kitware.com Tue Jan 19 14:25:15 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 14:25:15 -0500 Subject: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements In-Reply-To: <55F049C3.4040407@kitware.com> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> <55F049C3.4040407@kitware.com> Message-ID: <569E8D9B.5020800@kitware.com> On 09/09/2015 11:01 AM, Brad King wrote: > FindwxWidgets: allow specifying required version > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5 This introduced a regression reported here: https://cmake.org/Bug/view.php?id=15928 The version extraction from the header is breaking the reported case. > + find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} NO_DEFAULT_PATH) This call is affected by CMAKE_FIND_ROOT_PATH. Please take a look. Thanks, -Brad From brad.king at kitware.com Tue Jan 19 14:27:04 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 14:27:04 -0500 Subject: [cmake-developers] [PATCH] FindALSA: Create an imported ALSA:ASound target In-Reply-To: <1453222235-27596-1-git-send-email-sam.thursfield@codethink.co.uk> References: <1453222235-27596-1-git-send-email-sam.thursfield@codethink.co.uk> Message-ID: <569E8E08.4090500@kitware.com> On 01/19/2016 11:50 AM, Sam Thursfield wrote: > Imported targets are now the recommended way of dealing with external > library dependencies. Thanks! Adding Roger Leigh to Cc because he has implemented several of these for other modules. > + set(ALSA_LIBRARIES ${ALSA_LIBRARY}) > + set(ALSA_INCLUDE_DIRS ${ALSA_INCLUDE_DIR}) > + > + if(NOT TARGET ALSA::ASound) > + add_library(ALSA::ASound UNKNOWN IMPORTED) > + set_target_properties(ALSA::ASound PROPERTIES > + IMPORTED_LINK_INTERFACE_LANGUAGES "C" > + IMPORTED_LOCATION "${ALSA_LIBRARY}" > + INTERFACE_INCLUDE_DIRECTORIES "${ALSA_INCLUDE_DIRS}" > + INTERFACE_LIBRARIES "${ALSA_LIBRARY}" We shouldn't need to use INTERFACE_LIBRARIES here. The IMPORTED_LOCATION of an imported library should be enough to get it linked. -Brad From brad.king at kitware.com Tue Jan 19 14:30:37 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 14:30:37 -0500 Subject: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns In-Reply-To: <8A1F7886-A48A-4ABA-92C3-4636C0CD37D5@codexdigital.com> References: <79534F1B-F1FE-4072-B8F4-86DA211AE617@codexdigital.com> <569E595A.3050205@kitware.com> <8A1F7886-A48A-4ABA-92C3-4636C0CD37D5@codexdigital.com> Message-ID: <569E8EDD.6080907@kitware.com> On 01/19/2016 12:03 PM, Harry Mallon wrote: > I cannot retrieve a version number without linking and interrogating > the library. I could be missing something though. Are you saying that the only API provided by the package in question to get its version number is a runtime call? There is no version number provided by its header files as a preprocessor macro? -Brad From Harry at codexdigital.com Tue Jan 19 14:33:02 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 19 Jan 2016 19:33:02 +0000 Subject: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns Message-ID: Yep. The headers are the same version to version but provide a function to retrieve a filled version struct. H Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF] On 19 Jan 2016 19:30, Brad King wrote: On 01/19/2016 12:03 PM, Harry Mallon wrote: > I cannot retrieve a version number without linking and interrogating > the library. I could be missing something though. Are you saying that the only API provided by the package in question to get its version number is a runtime call? There is no version number provided by its header files as a preprocessor macro? -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Jan 19 15:00:18 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 15:00:18 -0500 Subject: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target In-Reply-To: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> Message-ID: <569E95D2.6040208@kitware.com> On 01/19/2016 12:43 PM, Sam Thursfield wrote: > Imported targets are now the recommended way of dealing with external > library dependencies. Thanks! Applied with minor doc format fixup and merged to 'next' for testing: FindPNG: Create an imported PNG::PNG target (#15911) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9451ea5a > + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") Shouldn't this refer to zlib instead of png libraries again? Thanks, -Brad From robert.maynard at kitware.com Tue Jan 19 15:14:34 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 19 Jan 2016 15:14:34 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.2 available for download Message-ID: We are pleased to announce that CMake 3.4.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.4.2 since 3.4.1: Brad King (6): CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889) VS: Do not select a partial Windows 10 SDK folder (#15831) VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation (#15894) cmSystemTools: Add VersionCompareEqual helper VS: Fix Windows 10 SDK version selection (#15831) CMake 3.4.2 Marc Chevrier (2): FindJava: Fix typos in IdlJ and JarSigner component implementation AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW From eike at sf-mail.de Tue Jan 19 15:44:52 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 19 Jan 2016 21:44:52 +0100 Subject: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements In-Reply-To: <569E8D9B.5020800@kitware.com> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> <55F049C3.4040407@kitware.com> <569E8D9B.5020800@kitware.com> Message-ID: <1826905.YYcfFkEgdD@caliban.sf-tec.de> Am Dienstag, 19. Januar 2016, 14:25:15 schrieb Brad King: > On 09/09/2015 11:01 AM, Brad King wrote: > > FindwxWidgets: allow specifying required version > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5 > > This introduced a regression reported here: > > https://cmake.org/Bug/view.php?id=15928 > > The version extraction from the header is breaking the reported case. > > > + find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} > > NO_DEFAULT_PATH) > This call is affected by CMAKE_FIND_ROOT_PATH. Please take a look. A random collection of thoughts I have on this: -"_filename" is a bad name for something that is find_* set in any module. Really. Since the value is also in the cache with older CMake releases I think this name is also used at another place, so here is not searched at all or so. -reading with file(STRINGS) will put much less stuff in the list that is REGEX REPLACEd later, which is probably much more efficient (depending on how large the file is) -maybe call to find_file can be omitted at all, and instead just FOREACH loop over the include dirs and simply if(EXISTS) check if the header is there Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From taylor at braun-jones.org Tue Jan 19 15:53:03 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Tue, 19 Jan 2016 15:53:03 -0500 Subject: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties? In-Reply-To: References: <568F9BB7.7090604@gmail.com> <568FB358.9060005@gmail.com> <568FC3C1.50803@gmail.com> Message-ID: On Mon, Jan 11, 2016 at 5:16 PM, Stephen Kelly wrote: > Taylor Braun-Jones wrote: > >> Consider library project Foo that uses a header-only project Bar. In >> FooConfig.cmake, it is a important to ensure any projects using Foo also >> use the exact same version of Bar that Foo was originally built with > > COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use > case. > > You would populate an INTERFACE_ property on the INTERFACE target, which is > whitelisted already: > > https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties > > http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 Thanks - that's exactly what I was looking for! Taylor From taylor at braun-jones.org Tue Jan 19 15:54:53 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Tue, 19 Jan 2016 15:54:53 -0500 Subject: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects Message-ID: For ExternalProjects built with a multi-config generator like "Visual Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch: https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1 Otherwise, the test step gives the error "Test not available without configuration." Thanks, Taylor From brad.king at kitware.com Tue Jan 19 16:18:09 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Jan 2016 16:18:09 -0500 Subject: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects In-Reply-To: References: Message-ID: <569EA811.2050703@kitware.com> On 01/19/2016 03:54 PM, Taylor Braun-Jones wrote: > For ExternalProjects built with a multi-config generator like "Visual > Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch: > > https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1 > > Otherwise, the test step gives the error "Test not available without > configuration." Good catch. Please try these changes: ExternalProject: Simplify `cmake --build` configuration passing https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b95be1cf ExternalProject: Fix TEST_BEFORE_INSTALL for multi-config generators https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f565f9fa Thanks, -Brad From taylor at braun-jones.org Tue Jan 19 16:39:36 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Tue, 19 Jan 2016 16:39:36 -0500 Subject: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects In-Reply-To: <569EA811.2050703@kitware.com> References: <569EA811.2050703@kitware.com> Message-ID: On Tue, Jan 19, 2016 at 4:18 PM, Brad King wrote: > On 01/19/2016 03:54 PM, Taylor Braun-Jones wrote: >> For ExternalProjects built with a multi-config generator like "Visual >> Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch: >> >> https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1 >> >> Otherwise, the test step gives the error "Test not available without >> configuration." > > Good catch. Please try these changes: > > ExternalProject: Simplify `cmake --build` configuration passing > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b95be1cf > > ExternalProject: Fix TEST_BEFORE_INSTALL for multi-config generators > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f565f9fa Thanks - works! However, these patches use the deprecated $ generator expression instead of $. The rest of ExternalProject.cmake uses $. Taylor From rleigh at codelibre.net Tue Jan 19 19:04:29 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 20 Jan 2016 00:04:29 +0000 Subject: [cmake-developers] [patch] New find module FindXalanC In-Reply-To: <569E8B25.2070105@kitware.com> References: <569E66BA.9020406@codelibre.net> <569E6950.9070006@kitware.com> <569E6C2F.4020209@codelibre.net> <569E8B25.2070105@kitware.com> Message-ID: <569ECF0D.1010601@codelibre.net> On 19/01/2016 19:14, Brad King wrote: > On 01/19/2016 12:02 PM, Roger Leigh wrote: >>>> +find_package(XercesC 3.0.0 REQUIRED) >> >> I think this is an assumption leaking from my own usage of it. I've >> removed the version here. > > Thanks. The CMakeOnly.AllFindModules and FindModulesExecuteAll > tests fail when XercesC is not available. It should be required > only if XalanC is required (XalanC_FIND_REQUIRED). This should be fixed now. Thanks, Roger From wonder.mice at gmail.com Tue Jan 19 21:20:48 2016 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Tue, 19 Jan 2016 18:20:48 -0800 Subject: [cmake-developers] [PATCH] Fix args handling in cmake -E time Message-ID: >From 7b01d1aed22b16fd81c3ae47dd51311e9a15187a Mon Sep 17 00:00:00 2001 From: wonder-mice Date: Tue, 19 Jan 2016 18:13:10 -0800 Subject: [PATCH] Fix args handling in cmake -E time Previous implementation had two issues: * Quotes in arguments where not escaped * No special treatment for arguments with spaces Because of that, following command line: cmake -E time cmake "-GUnix Makefile" was interpreted as cmake -E time cmake "-GUnix" "Makefile" Proposed patch fixes that by escaping all quotes in arguments and wrapping all arguments in quotes before concatenating them. --- Source/cmAlgorithms.h | 2 +- Source/cmcmd.cxx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Source/cmAlgorithms.h b/Source/cmAlgorithms.h index ef607d2..5b76429 100644 --- a/Source/cmAlgorithms.h +++ b/Source/cmAlgorithms.h @@ -230,7 +230,7 @@ template std::string cmJoin(Range const& r, std::string delimiter) { return cmJoin(r, delimiter.c_str()); -}; +} template typename Range::const_iterator cmRemoveN(Range& r, size_t n) diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx index fb7b1f5..5643cb9 100644 --- a/Source/cmcmd.cxx +++ b/Source/cmcmd.cxx @@ -555,7 +555,7 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args) // Clock command else if (args[1] == "time" && args.size() > 2) { - std::string command = cmJoin(cmMakeRange(args).advance(2), " "); + std::string command = cmWrap('"', cmMakeRange(args).advance(2), '"', " "); clock_t clock_start, clock_finish; time_t time_start, time_finish; -- 2.5.4 (Apple Git-61) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-args-handling-in-cmake-E-time.patch Type: application/octet-stream Size: 1660 bytes Desc: not available URL: From brad.king at kitware.com Wed Jan 20 08:38:32 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 20 Jan 2016 08:38:32 -0500 Subject: [cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects In-Reply-To: References: <569EA811.2050703@kitware.com> Message-ID: <569F8DD8.5070102@kitware.com> On 01/19/2016 04:39 PM, Taylor Braun-Jones wrote: > However, these patches use the deprecated $ generator > expression instead of $. The rest of ExternalProject.cmake > uses $. Oops, old habit. Revised: ExternalProject: Simplify `cmake --build` configuration passing https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d739a3c ExternalProject: Fix TEST_BEFORE_INSTALL for multi-config generators https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec00e89e Thanks, -Brad From ewmailing at gmail.com Wed Jan 20 08:48:59 2016 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 20 Jan 2016 05:48:59 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <569E644B.2020404@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> Message-ID: On 1/19/16, Brad King wrote: > On 01/18/2016 01:51 PM, Eric Wing wrote: >> So the good news is I have a basic add_executable working with Swift >> on Linux via the Makefile generator. >> >> It works with all Swift files, or intermixed C+Swift files. Bridging >> header is also supported. > > Great! > >> - I?m still copying over some CFLAGS to Swift_FLAGS. For example, I >> couldn?t figure out what was providing the ?-I? flag for include >> paths. Rules like this still need to be rewritten for Swift. > > Try adding to CMakeSwiftInformation: > > set(CMAKE_INCLUDE_FLAG_Swift -I) > >> - TODO: I need to look at Swift's DEFINE system. > > Yes. After we get things building correctly the first time then we'll > also need to see about adding needed dependencies to the build system. > >> - Note: The new file is Linux-unknown-Swift.cmake. When I compile >> Swift myself, there is no company or organization identifier (swift >> --version) unlike the one Apple ships with Xcode, and CMake refers to >> the identifier as ?unknown?. I made the file reflect this, but maybe >> we should rename this later (maybe Swift_org). > > In an earlier Swift thread there was discussion about the name of the > compiler id and ``Apple`` was chosen because that is the vendor of > their version. We definitely need to choose an id besides "unknown" > for this. Perhaps ``SwiftOrg``? Also, we need a good way to check > the id. We could use `--version` if necessary but do we know whether > the language provides any kind of identifier for code to use for > conditional compilation? > >> - To answer your question about whether ?swift? instead of ?swiftc? >> can be used for linking, I think the answer is yes, but I have been >> unable to figure out the correct incantation. > > Okay. Let's go with the ``c`` hack until we > know more. I'd prefer not to have to expose a separate setting for > the link driver only to remove it later. > >> - Swift Standard (or Core) Libraries: Swift comes with multiple >> standard libraries. > [snip] >> I think CMake should provide some variables to the full paths to >> these libraries since users like me will want to refer to them. > > Perhaps, but we currently don't do that for any other languages. > We do provide CMAKE_{C,CXX,Fortran}_IMPLICIT_LINK_DIRECTORIES > listing directories that may contain the standard libraries. > This is the same as the information needed to use the C linker > to mix languages that we previously discussed trying to extract > for Swift. > > -Brad Thanks for the response. I looking at version related stuff. I've been trying to get things running on the Raspberry Pi (Raspbian). I uncovered a few issues. First, the CMake Swift compiler version check being run was actually wrong all this time, but somehow got through on my desktop Linux. It was calling swift without proper flags, so interactive (REPL) mode should have run and blocked the process. Not sure how that got through. But on the Pi, the REPL segfaults which made the problem obvious. To answer your other question about getting the version from within Swift, I haven't figured out a way to do this yet. All the examples are about getting the iOS version number or availability of APIs, nothing about the language or compiler. So via command line on Pi: swift -version Swift version 2.2-dev (LLVM cb23059150, Clang f66c5bb67b, Swift 7187741628) Target: armv7-unknown-linux-gnueabihf So to correct this crash (which is a blocking issue on Pi for CMake), I want to pass the -version flag during that CMake check. But this leads to another question. I thought maybe setting the internal CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or CMAKE_${lang}_COMPILER_ID_FLAGS to "-version" would fix this. But this did nothing. I tracked the code to the function definition of CMAKE_DETERMINE_COMPILER_ID. I think there may be a bug: function(CMAKE_DETERMINE_COMPILER_ID lang flagvar src) # Make sure user-specified compiler flags are used. if(CMAKE_${lang}_FLAGS) set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS}) else() set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}}) endif() string(REPLACE " " ";" CMAKE_${lang}_COMPILER_ID_FLAGS_LIST "${CMAKE_${lang}_COMPILER_ID_FLAGS}") The CMAKE_${lang}_COMPILER_ID_FLAGS gets overwritten with generic flags, not the compiler_id_flags and I don't think the compiler_id_flags can ever be used. I think set() in those cases should be list(APPEND ...) Can you confirm? Additionally, there seems to be another Swift/ARM bug where the default target architecture name is slightly wrong. This causes the compile object files phases to always fail. This isn't a CMake problem, but to work around it, I want something like environmental variable CFLAGS or CXXFLAGS to be picked up by CMake. Coincidentally, it looks like somehow I already have $ENV{SWIFTFLAGS} set to CMAKE_Swift_FLAGS_INIT in CMakeSwiftInformation.cmake. (Either you did it, or it was copy/paste/substitute from C.) So I can do this in my shell: export SWIFTFLAGS='-target armv7-unknown-linux-gnueabihf' And CMake picks it up. Is this the correct expected behavior for CMake? Thanks. Eric From brad.king at kitware.com Wed Jan 20 09:01:42 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 20 Jan 2016 09:01:42 -0500 Subject: [cmake-developers] [PATCH] Fix args handling in cmake -E time In-Reply-To: References: Message-ID: <569F9346.8030506@kitware.com> On 01/19/2016 09:20 PM, Andrey Pokrovskiy wrote: > Previous implementation had two issues: > * Quotes in arguments where not escaped > * No special treatment for arguments with spaces Thanks for pointing this out. Please try this alternative fix: cmake: Fix `-E time` argument passing to child https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1787269e Technically this is an incompatibility but I think most uses of this command would be interactive anyway. -Brad From brad.king at kitware.com Wed Jan 20 10:15:39 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 20 Jan 2016 10:15:39 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> Message-ID: <569FA49B.2070005@kitware.com> On 01/20/2016 08:48 AM, Eric Wing wrote: > I thought maybe setting the internal > CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or > CMAKE_${lang}_COMPILER_ID_FLAGS > to "-version" would fix this. > > But this did nothing. Those are internal details of the CMAKE_DETERMINE_COMPILER_ID function and are not meant to be set anywhere else. I think you may be looking for something like this: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.4.2#l122 It is used by the CMAKE_DETERMINE_COMPILER_ID_VENDOR fallback when the compiler id cannot be extracted from the basic compiler output. More work may be needed to also extract a version number through the CMAKE_DETERMINE_COMPILER_ID_VENDOR infrastructure. > it looks like somehow I already have $ENV{SWIFTFLAGS} set to > CMAKE_Swift_FLAGS_INIT in CMakeSwiftInformation.cmake. (Either you did > it, or it was copy/paste/substitute from C.) It looks like it came from your port from CMakeCInformation. The set(CMAKE_Swift_FLAGS_INIT "$ENV{SWIFTFLAGS} ${CMAKE_Swift_FLAGS_INIT}") line looks correct. > So I can do this in my shell: > export SWIFTFLAGS='-target armv7-unknown-linux-gnueabihf' > > And CMake picks it up. Is this the correct expected behavior for CMake? Yes. One remaining question is if there is an established convention already out there for the name of the SWIFTFLAGS environment variable. -Brad From rleigh at codelibre.net Wed Jan 20 11:57:39 2016 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Wed, 20 Jan 2016 16:57:39 -0000 (GMT) Subject: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target In-Reply-To: <569E95D2.6040208@kitware.com> References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> <569E95D2.6040208@kitware.com> Message-ID: <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> > On 01/19/2016 12:43 PM, Sam Thursfield wrote: >> Imported targets are now the recommended way of dealing with external >> library dependencies. > > Thanks! Applied with minor doc format fixup and merged to 'next' > for testing: > > FindPNG: Create an imported PNG::PNG target (#15911) > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9451ea5a > >> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") > > Shouldn't this refer to zlib instead of png libraries again? I would have expected something like set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES ZLIB::ZLIB) after all of the "if(EXISTS... add imported link interface/location" blocks, so you get the appropriate zlib library. Certainly, I don't think PNG_LIBRARIES is appropriate to use for any of the imported targets, otherwise the system-specific zlib library path is going to get embedded in exported configuration when you call install(... EXPORT) to export the library configuration for find_package. I'd just use PNG_LIBRARY here and then add the dependencies as imported targets. As an aside, I've found some limitations in the usability and utility of EXPORT. These are two of the missing pieces for making the exported configuration functional: 1) is the need to manually call find_dependency for each of the interface libraries being exported. I work around this with wrapper scripts, for example: https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/OMEBioFormatsConfig.cmake Here we find our dependencies, then include the generated configuration. The thing is, this is a duplication of our requirements from when we called find_package for each of those dependencies. If cmake could store a mapping from imported name to the FindXXX file which created it, this could also be automatically embedded in the exported file; it could even include the minimum version we need. And it also means the dependencies can never become inconsistent as we change them. 2) the need to create the interface library target. We export a target, not an interface name, and so the internal target name in our project is exposed to the user of the library. It would be nice if we could specify the friendly interface name we expect the user to use when we do the export, and ignore the internal target name for the generated output entirely. Kind regards, Roger From wonder.mice at gmail.com Wed Jan 20 13:55:27 2016 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Wed, 20 Jan 2016 10:55:27 -0800 Subject: [cmake-developers] [PATCH] Fix args handling in cmake -E time In-Reply-To: <569F9346.8030506@kitware.com> References: <569F9346.8030506@kitware.com> Message-ID: Thanks, Brad. Your patch is much better. I also was looking for overload that receives a vector, but for some reason didn't find it... On Wed, Jan 20, 2016 at 6:01 AM, Brad King wrote: > On 01/19/2016 09:20 PM, Andrey Pokrovskiy wrote: >> Previous implementation had two issues: >> * Quotes in arguments where not escaped >> * No special treatment for arguments with spaces > > Thanks for pointing this out. Please try this alternative fix: > > cmake: Fix `-E time` argument passing to child > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1787269e > > Technically this is an incompatibility but I think most uses of > this command would be interactive anyway. > > -Brad > From brad.king at kitware.com Wed Jan 20 14:05:35 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 20 Jan 2016 14:05:35 -0500 Subject: [cmake-developers] EXPORT dependency handling In-Reply-To: <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> <569E95D2.6040208@kitware.com> <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> Message-ID: <569FDA7F.9010400@kitware.com> On 01/20/2016 11:57 AM, rleigh at codelibre.net wrote: > As an aside, I've found some limitations in the usability and utility of > EXPORT. These are two of the missing pieces for making the exported > configuration functional: > > 1) is the need to manually call find_dependency for each of the interface > libraries being exported. I work around this with wrapper scripts, for > example: > > https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/OMEBioFormatsConfig.cmake > > Here we find our dependencies, then include the generated configuration. > The thing is, this is a duplication of our requirements from when we > called find_package for each of those dependencies. If cmake could store > a mapping from imported name to the FindXXX file which created it, this > could also be automatically embedded in the exported file; it could even > include the minimum version we need. And it also means the dependencies > can never become inconsistent as we change them. The difficulty of this problem is why we defer responsibility to project code to provide the imported targets for dependencies of exported targets. There are so many ways of making imported targets available I don't think it can be solved in general, but perhaps it can be made to work in common cases (at least optionally) with some kind of mapping as you propose. > 2) the need to create the interface library target. I don't understand what you're saying here. What interface library target needs to be created in what context? Please provide an example. Thanks, -Brad From brad.king at kitware.com Wed Jan 20 14:05:58 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 20 Jan 2016 14:05:58 -0500 Subject: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target In-Reply-To: <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> <569E95D2.6040208@kitware.com> <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> Message-ID: <569FDA96.2070303@kitware.com> On 01/20/2016 11:57 AM, rleigh at codelibre.net wrote: >>> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") > > I would have expected something like > > set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES ZLIB::ZLIB) Yes. > after all of the "if(EXISTS... add imported link interface/location" > blocks, so you get the appropriate zlib library. Certainly, I don't think > PNG_LIBRARIES is appropriate to use for any of the imported targets, > otherwise the system-specific zlib library path is going to get embedded > in exported configuration when you call install(... EXPORT) to export the > library configuration for find_package. I'd just use PNG_LIBRARY here and > then add the dependencies as imported targets. Thanks for the review, Roger. I've reverted the topic from 'next' awaiting revisions from Sam as discussed here. This PNG -> ZLIB dependency is particularly important to get right because this relationship is commonly used as an example of how find modules should handle dependencies. > As an aside, I've found some limitations I've split the thread with a separate response to this part. -Brad From rleigh at codelibre.net Wed Jan 20 14:42:27 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 20 Jan 2016 19:42:27 +0000 Subject: [cmake-developers] EXPORT dependency handling In-Reply-To: <569FDA7F.9010400@kitware.com> References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> <569E95D2.6040208@kitware.com> <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> <569FDA7F.9010400@kitware.com> Message-ID: <569FE323.5060704@codelibre.net> On 20/01/2016 19:05, Brad King wrote: > On 01/20/2016 11:57 AM, rleigh at codelibre.net wrote: >> As an aside, I've found some limitations in the usability and utility of >> EXPORT. These are two of the missing pieces for making the exported >> configuration functional: >> >> 1) is the need to manually call find_dependency for each of the interface >> libraries being exported. I work around this with wrapper scripts, for >> example: >> >> https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/OMEBioFormatsConfig.cmake >> >> Here we find our dependencies, then include the generated configuration. >> The thing is, this is a duplication of our requirements from when we >> called find_package for each of those dependencies. If cmake could store >> a mapping from imported name to the FindXXX file which created it, this >> could also be automatically embedded in the exported file; it could even >> include the minimum version we need. And it also means the dependencies >> can never become inconsistent as we change them. > > The difficulty of this problem is why we defer responsibility to project > code to provide the imported targets for dependencies of exported targets. > There are so many ways of making imported targets available I don't think > it can be solved in general, but perhaps it can be made to work in common > cases (at least optionally) with some kind of mapping as you propose. Agreed that it's not going to be possible to do the mapping automatically. Maybe allowing it to be specified manually as a target property would be acceptable though. We could have a property for the name to pass to find_dependency/find_package, and another for a minimum version, which EXPORT could use, if set, to automatically add find_dependency statements. We could set these in the Find* modules when we create the imported interfaces, and they could also be set on targets in the source tree as needed. >> 2) the need to create the interface library target. > > I don't understand what you're saying here. What interface library target > needs to be created in what context? Please provide an example. Sorry for not being clear, it was at the end of the URL. I'll copy the whole thing, since it's short (OMEBioFormatsConfig.cmake): include(CMakeFindDependencyMacro) find_dependency(OME REQUIRED COMPONENTS Common XML) find_dependency(Boost 1.46 REQUIRED COMPONENTS boost iostreams filesystem) find_dependency(TIFF REQUIRED) include(${CMAKE_CURRENT_LIST_DIR}/OMEBioFormatsInternal.cmake) add_library(OME::BioFormats INTERFACE IMPORTED) set_target_properties(OME::BioFormats PROPERTIES INTERFACE_LINK_LIBRARIES ome-bioformats) It's the last two lines. Internally, the target name is ome-bioformats, but I actually want it to be OME::BioFormats as the name of the imported interface. I don't have any need for "ome-bioformats" to be exported at all, but EXPORT only allows a real target. Unless I missed a workaround; I tried exporting ALIAS names and interface names, but without success. Ideally, if these two issues can be resolved, it will be possible to emit a fully-functional exported configuration file which will work without the need for custom wrapper code to fix up these things. Regards, Roger From steveire at gmail.com Wed Jan 20 15:07:03 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 20 Jan 2016 21:07:03 +0100 Subject: [cmake-developers] EXPORT dependency handling References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> <569E95D2.6040208@kitware.com> <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> <569FDA7F.9010400@kitware.com> <569FE323.5060704@codelibre.net> Message-ID: Roger Leigh wrote: > add_library(OME::BioFormats INTERFACE IMPORTED) > set_target_properties(OME::BioFormats PROPERTIES > INTERFACE_LINK_LIBRARIES ome-bioformats) > > It's the last two lines. Internally, the target name is ome-bioformats, > but I actually want it to be OME::BioFormats as the name of the imported > interface. I don't have any need for "ome-bioformats" to be exported at > all, but EXPORT only allows a real target. Unless I missed a > workaround; I tried exporting ALIAS names and interface names, but > without success. You might have missed https://cmake.org/cmake/help/v3.4/prop_tgt/EXPORT_NAME.html Thanks, Steve From steveire at gmail.com Wed Jan 20 15:12:52 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 20 Jan 2016 21:12:52 +0100 Subject: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> <569E95D2.6040208@kitware.com> <01ff85a54e75ad2a2e72be1ec0e467fb.squirrel@g.mail.aa.net.uk> Message-ID: rleigh at codelibre.net wrote: >>> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") >> >> Shouldn't this refer to zlib instead of png libraries again? > > I would have expected something like > > set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES > ZLIB::ZLIB) For reference, this is documented here: https://cmake.org/cmake/help/v3.4/manual/cmake-packages.7.html#creating-relocatable-packages but as IMPORTED targets are getting added to find modules now, perhaps the manual cmake-developer(7) could also get a note about this: https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#a-sample-find-module or that section could be extended to generally discuss dependencies. Thanks, Steve. From steveire at gmail.com Wed Jan 20 16:03:22 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 20 Jan 2016 22:03:22 +0100 Subject: [cmake-developers] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <5694166D.90409@kitware.com> <6131379.scgJXYybyB@agathebauer> Message-ID: Milian Wolff wrote: >> I'm concerned that the memory usage of a daemon implementing the proposed >> capabilities may be too large to be practical (at least without a major >> redesign of certain structures that tend to duplicate substrings, or >> some kind of out-of-core approach). > > This sounds like optimizations to that daemon will benefit CMake. FYI I merged a reduce-allocations branch to next for testing. It came from Milian here: https://github.com/steveire/CMake/pull/1 Milian also mentioned the possibility of using something like a sqlite database (probably what you meant by out-of-core above) for definitions for querying by the daemon. I also mentioned some possibile optimization possibilities, such as removing the closure of definitions created for all directories. I wrote a branch which does that some months ago, but it resulted in a slow down. I'll see if I can rebase the commit to master and push it to github, together with a patch for avoiding computing the hash multiple times in cmDefinitions. Thanks, Steve. From steveire at gmail.com Wed Jan 20 17:19:21 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 20 Jan 2016 23:19:21 +0100 Subject: [cmake-developers] Add command line options for deprecation message control References: <56951DA1.2050207@kitware.com> <5695437A.1060703@gmail.com> Message-ID: Michael Scott wrote: > If there are any problems with the proposed changes let me know. Hi Michael, Thanks for working on this topic over such a long time period to get it right. I closed http://public.kitware.com/Bug/view.php?id=15677 and http://public.kitware.com/Bug/view.php?id=14669 on your behalf because I couldn't assign the bugs to you in mantis. Thanks, Steve. From mantis at public.kitware.com Wed Jan 20 21:25:48 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 20 Jan 2016 21:25:48 -0500 Subject: [cmake-developers] [CMake 0015929]: "Could not find an appropriate version of the Windows 10 SDK" Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15929 ====================================================================== Reported By: Bruce Pascoe Assigned To: ====================================================================== Project: CMake Issue ID: 15929 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-20 21:25 EST Last Modified: 2016-01-20 21:25 EST ====================================================================== Summary: "Could not find an appropriate version of the Windows 10 SDK" Description: I just upgraded to CMake 3.4.2, and started getting the above message when attempting to build Allegro 5.1. I was using CMake 3.4.1 previously, and that worked just fine. No other changes have been made to my system other than to update CMake. Steps to Reproduce: * Try to build a CMake project. * Get error "Could not find an appropriate version of the Windows 10 SDK installed on this machine" * Build fails. Additional Information: * Windows 10 Pro 1511 (10.0.10586) x64 * Visual Studio Community 2015 Update 1 * CMakeOutput.log is attached. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-20 21:25 Bruce Pascoe New Issue 2016-01-20 21:25 Bruce Pascoe File Added: CMakeOutput.log ====================================================================== From wonder.mice at gmail.com Wed Jan 20 21:41:21 2016 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Wed, 20 Jan 2016 18:41:21 -0800 Subject: [cmake-developers] [PATCH] Fix crash in cmExportInstallFileGenerator::FindNamespaces() Message-ID: >From 0852339e3ab545af709246c8e767e996cb629707 Mon Sep 17 00:00:00 2001 From: wonder-mice Date: Wed, 20 Jan 2016 18:29:58 -0800 Subject: [PATCH] Fix crash in cmExportInstallFileGenerator::FindNamespaces() Found it when was building poco library: https://github.com/pocoproject/poco.git Steps to reproduce: 1. Clone poco 2. mkdir poco.git/build.make 3. cd poco.git/build.make 4. cmake .. 5. Crash As I understand this place was missed during refactoring performed in this commit: commit 381e7afd363d64c72b83e69fd6c6cad5fc3eefb4 Author: Stephen Kelly Date: Sat Oct 17 13:31:33 2015 +0200 cmExportSet: Store a cmGeneratorTarget. Set the member at compute time from the stored name. --- Source/cmExportInstallFileGenerator.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Source/cmExportInstallFileGenerator.cxx b/Source/cmExportInstallFileGenerator.cxx index b695904..71418e8 100644 --- a/Source/cmExportInstallFileGenerator.cxx +++ b/Source/cmExportInstallFileGenerator.cxx @@ -496,7 +496,7 @@ cmExportInstallFileGenerator bool containsTarget = false; for(unsigned int i=0; isize(); i++) { - if (name == (*targets)[i]->Target->GetName()) + if (name == (*targets)[i]->TargetName) { containsTarget = true; break; -- 2.5.4 (Apple Git-61) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-crash-in-cmExportInstallFileGenerator-FindNamesp.patch Type: application/octet-stream Size: 1395 bytes Desc: not available URL: From brad.king at kitware.com Thu Jan 21 10:21:31 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 21 Jan 2016 10:21:31 -0500 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> <5694166D.90409@kitware.com> <6131379.scgJXYybyB@agathebauer> Message-ID: <56A0F77B.3000007@kitware.com> On 01/20/2016 04:03 PM, Stephen Kelly wrote: > FYI I merged a reduce-allocations branch to next for testing. It came from > Milian here: > > https://github.com/steveire/CMake/pull/1 Very nice! Thanks, -Brad From mantis at public.kitware.com Thu Jan 21 11:36:43 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 21 Jan 2016 11:36:43 -0500 Subject: [cmake-developers] [CMake 0015930]: MSVC project switched to Windows XP toolset won't compile Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15930 ====================================================================== Reported By: Bruce Pascoe Assigned To: ====================================================================== Project: CMake Issue ID: 15930 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-21 11:36 EST Last Modified: 2016-01-21 11:36 EST ====================================================================== Summary: MSVC project switched to Windows XP toolset won't compile Description: MSVC projects created by CMake explicitly add the detected Windows SDK to the include paths. Normally this doesn't cause an issue, however if the project's Platform Toolset is then switched from "Visual Studio 201x" to "Visual Studio 201x - Windows XP" it will no longer compile. The cause of this is that the Windows XP toolchain uses a different SDK version, installed in a different location from the default. The project can be made to compile at this point by removing the Windows SDK from the include paths, which allows the IDE (actually MSBuild) to select the correct SDK on its own. Steps to Reproduce: * Generate a Visual Studio project using CMake * Open Project Properties -> General in MSVC * Change the Platform Toolset to the Windows XP version. * Try to build the project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-21 11:36 Bruce Pascoe New Issue ====================================================================== From sam.thursfield at codethink.co.uk Thu Jan 21 11:46:35 2016 From: sam.thursfield at codethink.co.uk (Sam Thursfield) Date: Thu, 21 Jan 2016 16:46:35 +0000 Subject: [cmake-developers] [PATCH V2] FindPNG: Create an imported PNG::PNG target In-Reply-To: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> References: <1453225385-29248-1-git-send-email-sam.thursfield@codethink.co.uk> Message-ID: <1453394796-11364-1-git-send-email-sam.thursfield@codethink.co.uk> Updated to refer to ZLIB::ZLIB, and with documentation tweak. Sam Thursfield (1): FindPNG: Create an imported PNG::PNG target Help/release/dev/FindPNG-imported-targets.rst | 4 +++ Modules/FindPNG.cmake | 50 +++++++++++++++++++++++---- Tests/CMakeLists.txt | 4 +++ Tests/FindPNG/CMakeLists.txt | 10 ++++++ Tests/FindPNG/Test/CMakeLists.txt | 16 +++++++++ Tests/FindPNG/Test/main.c | 20 +++++++++++ 6 files changed, 97 insertions(+), 7 deletions(-) create mode 100644 Help/release/dev/FindPNG-imported-targets.rst create mode 100644 Tests/FindPNG/CMakeLists.txt create mode 100644 Tests/FindPNG/Test/CMakeLists.txt create mode 100644 Tests/FindPNG/Test/main.c -- 2.4.3 From sam.thursfield at codethink.co.uk Thu Jan 21 11:46:36 2016 From: sam.thursfield at codethink.co.uk (Sam Thursfield) Date: Thu, 21 Jan 2016 16:46:36 +0000 Subject: [cmake-developers] [PATCH V2] FindPNG: Create an imported PNG::PNG target In-Reply-To: <1453394796-11364-1-git-send-email-sam.thursfield@codethink.co.uk> References: <1453394796-11364-1-git-send-email-sam.thursfield@codethink.co.uk> Message-ID: <1453394796-11364-2-git-send-email-sam.thursfield@codethink.co.uk> Imported targets are now the recommended way of dealing with external library dependencies. The documentation for FindPNG is rewritten slightly. This commit also adds a test case, you can run it like this: cmake ... -DCMake_TEST_FindPNG=ON ctest -R FindPNG --output-on-failure The testcase requires the libpng library and headers to be installed. This change is based on the equivalent changes to FindTIFF, found in commit ebaca6290d2c0be7dec22452389632949a700d28. https://cmake.org/Bug/view.php?id=15911 --- Help/release/dev/FindPNG-imported-targets.rst | 4 +++ Modules/FindPNG.cmake | 50 +++++++++++++++++++++++---- Tests/CMakeLists.txt | 4 +++ Tests/FindPNG/CMakeLists.txt | 10 ++++++ Tests/FindPNG/Test/CMakeLists.txt | 16 +++++++++ Tests/FindPNG/Test/main.c | 20 +++++++++++ 6 files changed, 97 insertions(+), 7 deletions(-) create mode 100644 Help/release/dev/FindPNG-imported-targets.rst create mode 100644 Tests/FindPNG/CMakeLists.txt create mode 100644 Tests/FindPNG/Test/CMakeLists.txt create mode 100644 Tests/FindPNG/Test/main.c diff --git a/Help/release/dev/FindPNG-imported-targets.rst b/Help/release/dev/FindPNG-imported-targets.rst new file mode 100644 index 0000000..e0d0ab1 --- /dev/null +++ b/Help/release/dev/FindPNG-imported-targets.rst @@ -0,0 +1,4 @@ +FindPNG-imported-targets +------------------------ + +* The :module:`FindPNG` module now provides imported targets. diff --git a/Modules/FindPNG.cmake b/Modules/FindPNG.cmake index 7cf3f22..cae41ac 100644 --- a/Modules/FindPNG.cmake +++ b/Modules/FindPNG.cmake @@ -2,13 +2,20 @@ # FindPNG # ------- # -# Find the native PNG includes and library +# Find libpng, the official reference library for the PNG image format. # +# Imported targets +# ^^^^^^^^^^^^^^^^ # +# This module defines the following :prop_tgt:`IMPORTED` target: # -# This module searches libpng, the library for working with PNG images. +# ``PNG::PNG`` +# The libpng library, if found. # -# It defines the following variables +# Result variables +# ^^^^^^^^^^^^^^^^ +# +# This module will set the following variables in your project: # # ``PNG_INCLUDE_DIRS`` # where to find png.h, etc. @@ -22,19 +29,22 @@ # ``PNG_VERSION_STRING`` # the version of the PNG library found (since CMake 2.8.8) # -# Also defined, but not for general use are +# Obsolete variables +# ^^^^^^^^^^^^^^^^^^ +# +# The following variables may also be set, for backwards compatibility: # # ``PNG_LIBRARY`` # where to find the PNG library. -# -# For backward compatiblity the variable PNG_INCLUDE_DIR is also set. -# It has the same value as PNG_INCLUDE_DIRS. +# ``PNG_INCLUDE_DIR`` +# where to find the PNG headers (same as PNG_INCLUDE_DIRS) # # Since PNG depends on the ZLib compression library, none of the above # will be defined unless ZLib can be found. #============================================================================= # Copyright 2002-2009 Kitware, Inc. +# Copyright 2016 Raumfeld # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. @@ -105,6 +115,32 @@ if(ZLIB_FOUND) endif() endif () + if(NOT TARGET PNG::PNG) + add_library(PNG::PNG UNKNOWN IMPORTED) + set_target_properties(PNG::PNG PROPERTIES + INTERFACE_COMPILE_DEFINITIONS "${PNG_DEFINITIONS}" + INTERFACE_INCLUDE_DIRECTORIES "${PNG_INCLUDE_DIRS}" + INTERFACE_LINK_LIBRARIES ZLIB::ZLIB) + if(EXISTS "${PNG_LIBRARY}") + set_target_properties(PNG::PNG PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES "C" + IMPORTED_LOCATION "${PNG_LIBRARY}") + endif() + if(EXISTS "${PNG_LIBRARY_DEBUG}") + set_property(TARGET PNG::PNG APPEND PROPERTY + IMPORTED_CONFIGURATIONS DEBUG) + set_target_properties(PNG::PNG PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C" + IMPORTED_LOCATION_DEBUG "${PNG_LIBRARY_DEBUG}") + endif() + if(EXISTS "${PNG_LIBRARY_RELEASE}") + set_property(TARGET PNG::PNG APPEND PROPERTY + IMPORTED_CONFIGURATIONS RELEASE) + set_target_properties(PNG::PNG PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C" + IMPORTED_LOCATION_RELEASE "${PNG_LIBRARY_RELEASE}") + endif() + endif() endif () if (PNG_PNG_INCLUDE_DIR AND EXISTS "${PNG_PNG_INCLUDE_DIR}/png.h") diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index 043b757..3cca77b 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1375,6 +1375,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release add_subdirectory(FindOpenSSL) endif() + if(CMake_TEST_FindPNG) + add_subdirectory(FindPNG) + endif() + if(CMake_TEST_FindTIFF) add_subdirectory(FindTIFF) endif() diff --git a/Tests/FindPNG/CMakeLists.txt b/Tests/FindPNG/CMakeLists.txt new file mode 100644 index 0000000..c665b67 --- /dev/null +++ b/Tests/FindPNG/CMakeLists.txt @@ -0,0 +1,10 @@ +add_test(NAME FindPNG.Test COMMAND + ${CMAKE_CTEST_COMMAND} -C $ + --build-and-test + "${CMake_SOURCE_DIR}/Tests/FindPNG/Test" + "${CMake_BINARY_DIR}/Tests/FindPNG/Test" + ${build_generator_args} + --build-project TestFindPNG + --build-options ${build_options} + --test-command ${CMAKE_CTEST_COMMAND} -V -C $ + ) diff --git a/Tests/FindPNG/Test/CMakeLists.txt b/Tests/FindPNG/Test/CMakeLists.txt new file mode 100644 index 0000000..ad50011 --- /dev/null +++ b/Tests/FindPNG/Test/CMakeLists.txt @@ -0,0 +1,16 @@ +cmake_minimum_required(VERSION 3.4) +project(TestFindPNG C) +include(CTest) + +find_package(PNG REQUIRED) + +add_definitions(-DCMAKE_EXPECTED_PNG_VERSION="${PNG_VERSION_STRING}") + +add_executable(test_tgt main.c) +target_link_libraries(test_tgt PNG::PNG) +add_test(NAME test_tgt COMMAND test_tgt) + +add_executable(test_var main.c) +target_include_directories(test_var PRIVATE ${PNG_INCLUDE_DIRS}) +target_link_libraries(test_var PRIVATE ${PNG_LIBRARIES}) +add_test(NAME test_var COMMAND test_var) diff --git a/Tests/FindPNG/Test/main.c b/Tests/FindPNG/Test/main.c new file mode 100644 index 0000000..27e1478 --- /dev/null +++ b/Tests/FindPNG/Test/main.c @@ -0,0 +1,20 @@ +#include +#include +#include + +int main() +{ + png_uint_32 png_version; + char png_version_string[16]; + + png_version = png_access_version_number (); + + snprintf (png_version_string, 16, "%i.%i.%i", + png_version / 10000, + (png_version % 10000) / 100, + png_version % 100); + + assert (strcmp(png_version_string, CMAKE_EXPECTED_PNG_VERSION) == 0); + + return 0; +} -- 2.4.3 From brad.king at kitware.com Thu Jan 21 12:46:17 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 21 Jan 2016 12:46:17 -0500 Subject: [cmake-developers] [PATCH] Fix crash in cmExportInstallFileGenerator::FindNamespaces() In-Reply-To: References: Message-ID: <56A11969.5040704@kitware.com> On 01/20/2016 09:41 PM, Andrey Pokrovskiy wrote: > Subject: [PATCH] Fix crash in cmExportInstallFileGenerator::FindNamespaces() > > Found it when was building poco library: > https://github.com/pocoproject/poco.git > > Steps to reproduce: > 1. Clone poco > 2. mkdir poco.git/build.make > 3. cd poco.git/build.make > 4. cmake .. > 5. Crash Thanks. From that I was able to produce a simpler test case which I've added to the commit message. Applied: cmExportInstallFileGenerator: Fix crash in FindNamespaces https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dbfdddf -Brad From mantis at public.kitware.com Thu Jan 21 13:26:39 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 21 Jan 2016 13:26:39 -0500 Subject: [cmake-developers] [CMake 0015931]: Change the StartUp-Solution by Value Message-ID: <389ed438ced46dd3209f0934c70709db@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15931 ====================================================================== Reported By: Luis Roalter Assigned To: ====================================================================== Project: CMake Issue ID: 15931 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-21 13:26 EST Last Modified: 2016-01-21 13:26 EST ====================================================================== Summary: Change the StartUp-Solution by Value Description: CMake always tries to set ALL_BUILD in Visual Studio Projects as the first project in the Solution file. This is okay if I want to build all the content. But sometimes it would be great to change this behavior to a custom project as well. The point is: Pressing F5 in Studio (just run the Application) won't work. Sure, you can setup the startup project manually. But it would be gread to set it per-project (means per solution). I've patched it to use CMAKE_STARTUP_SOLUTION. This exchanges the string "ALL_BUILD" in the comparison of the project if possible. It would be even better to make something like set_property(GLOBAL PROPERTY STARTUP_APPLICATION MainWindow). This should only scope till the next project(). Steps to Reproduce: Just press F5 on a Studio-runnable application. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-21 13:26 Luis Roalter New Issue ====================================================================== From brad.king at kitware.com Thu Jan 21 14:00:29 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 21 Jan 2016 14:00:29 -0500 Subject: [cmake-developers] [PATCH V2] FindPNG: Create an imported PNG::PNG target In-Reply-To: <1453394796-11364-2-git-send-email-sam.thursfield@codethink.co.uk> References: <1453394796-11364-1-git-send-email-sam.thursfield@codethink.co.uk> <1453394796-11364-2-git-send-email-sam.thursfield@codethink.co.uk> Message-ID: <56A12ACD.3090408@kitware.com> On 01/21/2016 11:46 AM, Sam Thursfield wrote: > Imported targets are now the recommended way of dealing with external > library dependencies. Thanks, re-applied and merged to 'next' for testing: FindPNG: Create an imported PNG::PNG target (#15911) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b08c623 For reference, the net diff since v1 is just: > - INTERFACE_LIBRARIES "${PNG_LIBRARIES}") > + INTERFACE_LINK_LIBRARIES ZLIB::ZLIB) Thanks, -Brad From daniel at pfeifer-mail.de Thu Jan 21 16:03:23 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 21 Jan 2016 22:03:23 +0100 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> <5694166D.90409@kitware.com> <6131379.scgJXYybyB@agathebauer> Message-ID: On Wed, Jan 20, 2016 at 10:03 PM, Stephen Kelly wrote: > Milian Wolff wrote: > >>> I'm concerned that the memory usage of a daemon implementing the proposed >>> capabilities may be too large to be practical (at least without a major >>> redesign of certain structures that tend to duplicate substrings, or >>> some kind of out-of-core approach). >> >> This sounds like optimizations to that daemon will benefit CMake. > > FYI I merged a reduce-allocations branch to next for testing. It came from > Milian here: > > https://github.com/steveire/CMake/pull/1 Very nice! It is impressive what kind of an impact a simple 'const&' can have. Also, nice work identifying the hotspots. > Milian also mentioned the possibility of using something like a sqlite > database (probably what you meant by out-of-core above) for definitions for > querying by the daemon. > > I also mentioned some possibile optimization possibilities, such as removing > the closure of definitions created for all directories. I wrote a branch > which does that some months ago, but it resulted in a slow down. I'll see if > I can rebase the commit to master and push it to github, together with a > patch for avoiding computing the hash multiple times in cmDefinitions. What do you think about string interning? I started a cmString class [2] that stores short strings inplace and puts long strings into a pool. Copies never allocate extra memory and equality comparison is always O(1). In addition to `operator<` (which is lexicographical) there is a O(1) comparison that can be used where lexicographical ordering is not required (ie. for lookup tables). [1] https://en.wikipedia.org/wiki/String_interning [2] https://github.com/purpleKarrot/CMake/commits/string-pool cheers, Daniel From mail at milianw.de Thu Jan 21 17:30:57 2016 From: mail at milianw.de (Milian Wolff) Date: Thu, 21 Jan 2016 23:30:57 +0100 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: <8917442.8CjU5Q4uo4@agathebauer> On Donnerstag, 21. Januar 2016 22:03:23 CET Daniel Pfeifer wrote: > On Wed, Jan 20, 2016 at 10:03 PM, Stephen Kelly wrote: > > Milian Wolff wrote: > >>> I'm concerned that the memory usage of a daemon implementing the > >>> proposed > >>> capabilities may be too large to be practical (at least without a major > >>> redesign of certain structures that tend to duplicate substrings, or > >>> some kind of out-of-core approach). > >> > >> This sounds like optimizations to that daemon will benefit CMake. > > > > FYI I merged a reduce-allocations branch to next for testing. It came from > > > > Milian here: > > https://github.com/steveire/CMake/pull/1 > > Very nice! It is impressive what kind of an impact a simple 'const&' > can have. Also, nice work identifying the hotspots. > > > Milian also mentioned the possibility of using something like a sqlite > > database (probably what you meant by out-of-core above) for definitions > > for > > querying by the daemon. > > > > I also mentioned some possibile optimization possibilities, such as > > removing the closure of definitions created for all directories. I wrote > > a branch which does that some months ago, but it resulted in a slow down. > > I'll see if I can rebase the commit to master and push it to github, > > together with a patch for avoiding computing the hash multiple times in > > cmDefinitions. > > What do you think about string interning? I started a cmString class > [2] that stores short strings inplace and puts long strings into a > pool. Copies never allocate extra memory and equality comparison is > always O(1). > In addition to `operator<` (which is lexicographical) there is a O(1) > comparison that can be used where lexicographical ordering is not > required (ie. for lookup tables). > > [1] https://en.wikipedia.org/wiki/String_interning > [2] https://github.com/purpleKarrot/CMake/commits/string-pool Imo, you should replace this custom code by a boost::flyweight of std::string. That said, I think this can have a significant impact on the memory footprint of CMake, considering how heavy it relies on strings internally. But it also seems to mutate strings a lot. I've seen places e.g. where a list of compile- time known identifiers is prepended with "CMAKE_" at runtime. This is slow with normal strings (reallocations), but will also be slow with a flyweight or interning, possibly even leading to the pollution of the internal pool with temporary strings. Did you measure any impact on both, runtime speed and memory footprint yet? -- Milian Wolff mail at milianw.de http://milianw.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Thu Jan 21 17:34:23 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 21 Jan 2016 17:34:23 -0500 Subject: [cmake-developers] [CMake 0015932]: Path too long installing from installer Message-ID: <75ba03f35afa15cadcee52f465977a1c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15932 ====================================================================== Reported By: MPowell Assigned To: ====================================================================== Project: CMake Issue ID: 15932 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-21 17:34 EST Last Modified: 2016-01-21 17:34 EST ====================================================================== Summary: Path too long installing from installer Description: Seems like a duplicate of issue 0010257. Steps to Reproduce: Installed, received passive dialog [OK] option. I don't know what I must have done differently than anyone else. I simply installed and received the error. Additional Information: My user path is only 220 characters. My All Users path is substantially longer, but it is still a valid path; 1875 characters. So why can this issue not be fixed? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-21 17:34 MPowell New Issue ====================================================================== From mantis at public.kitware.com Fri Jan 22 10:05:22 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 22 Jan 2016 10:05:22 -0500 Subject: [cmake-developers] [CMake 0015933]: The install command should have an option to only install built targets Message-ID: <74b776a5d7eb6b02e962208a73715f5f@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15933 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15933 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-22 10:05 EST Last Modified: 2016-01-22 10:05 EST ====================================================================== Summary: The install command should have an option to only install built targets Description: For library projects it common to provide different targets for static and shared versions of the library. Often, one only needs either shared or static library. It would be convenient if install command would allow one to only install targets that were built. E.g. if one builds a target via `cmake --build . --target sharedlib` calling `cmake --build . --target install` should install only sharedlib without making static version. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-22 10:05 Ilya New Issue ====================================================================== From nicolas.despres at gmail.com Fri Jan 22 11:34:03 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Fri, 22 Jan 2016 17:34:03 +0100 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: References: <20160106172504.GB6998@megas.kitware.com> <20160106183552.GA29325@megas.kitware.com> Message-ID: Ben, I have pushed a first draft of the patch here: https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b I have tested with a small project and it looks good. I would like to add some regression tests but I don't know from where to start. The principle would be to duplicate and modify existing tests so that CMAKE_NINJA_OUTPUT_PATH_PREFIX is set to "sub/" and the build directory is changed from _build to _build/sub. A dummy build.ninja file containing "subninja sub/build.ninja" should be generated in _build/build.ninja and ninja should be called from _build instead of _build/sub. It would be great if you could point me some existing tests that could serve as a base to do the above. Cheers, Nicolas On Wed, Jan 6, 2016 at 7:46 PM, Nicolas Despr?s wrote: > > > On Wed, Jan 6, 2016 at 7:35 PM, Ben Boeckel > wrote: > >> On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Despr?s wrote: >> > Is that variable already available or a name suggestion? I cannot find >> any >> > reference to it neither in the source nor in the documentation. >> >> It's a suggestion. >> > > Ok, works for me too. > > >> > This is acceptable for me since I have a custom generator that would >> write >> > the top build.ninja containing "subninja sub/build.ninja". The end-user >> is >> > supposed to run ninja from the top directory not from the top/sub/ >> > directory. >> >> It looks like subclassing cmLocalNinjaGenerator to override some >> path-related bits and it should work (though it has changed enough with >> cmState that I can't tell what exactly without doing more digging). >> >> The hardest problem is going to be with testing. Every generate step >> will also have to dump a build.ninja file out so that it can be properly >> tested. >> >> Brad is back later this week and may have other ideas too. >> >> I will try to have a patch working on a helloworld project first and I > will get back to you for the testing part. That would be the hardest part > indeed. > > Thanks for your help. > > -- > Nicolas Despr?s > -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Jan 22 11:50:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 22 Jan 2016 11:50:48 -0500 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: References: <20160106172504.GB6998@megas.kitware.com> <20160106183552.GA29325@megas.kitware.com> Message-ID: <20160122165048.GB26825@megas.kitware.com> On Fri, Jan 22, 2016 at 17:34:03 +0100, Nicolas Despr?s wrote: > I have pushed a first draft of the patch here: > > https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b > > I have tested with a small project and it looks good. Looks like a good start to me as well. I added some comments on the commit. > I would like to add some regression tests but I don't know from where to > start. > > The principle would be to duplicate and modify existing tests so that > CMAKE_NINJA_OUTPUT_PATH_PREFIX is set to "sub/" and the build directory is > changed from _build to _build/sub. A dummy build.ninja file containing > "subninja sub/build.ninja" should be generated in _build/build.ninja and > ninja should be called from _build instead of _build/sub. > > It would be great if you could point me some existing tests that could > serve as a base to do the above. The RunCMake test infrastructure would probably be the best place to start. It could be modified to do some of this work. Thanks, --Ben From JamesJ at motionview3d.com Fri Jan 22 12:55:46 2016 From: JamesJ at motionview3d.com (James Johnston) Date: Fri, 22 Jan 2016 17:55:46 -0000 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: <8917442.8CjU5Q4uo4@agathebauer> References: <56923C33.6030506@gmail.com> <8917442.8CjU5Q4uo4@agathebauer> Message-ID: <032a01d1553e$1fbba6e0$5f32f4a0$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Milian Wolff > Sent: Thursday, January 21, 2016 22:31 > To: Daniel Pfeifer > Cc: CMake Developers; Stephen Kelly > Subject: Re: [cmake-developers] CMake daemon for user tools > > > What do you think about string interning? I started a cmString class > > [2] that stores short strings inplace and puts long strings into a > > pool. Copies never allocate extra memory and equality comparison is > > always O(1). > > In addition to `operator<` (which is lexicographical) there is a O(1) > > comparison that can be used where lexicographical ordering is not > > required (ie. for lookup tables). > > > > [1] https://en.wikipedia.org/wiki/String_interning > > [2] https://github.com/purpleKarrot/CMake/commits/string-pool > > Imo, you should replace this custom code by a boost::flyweight of std::string. > That said, I think this can have a significant impact on the memory footprint > of CMake, considering how heavy it relies on strings internally. But it also > seems to mutate strings a lot. I've seen places e.g. where a list of compile- > time known identifiers is prepended with "CMAKE_" at runtime. This is slow > with normal strings (reallocations), but will also be slow with a flyweight or > interning, possibly even leading to the pollution of the internal pool with > temporary strings. > > Did you measure any impact on both, runtime speed and memory footprint > yet? I was wondering the same. I would guess maybe the biggest impact would be the inplace storage of strings for small sized strings. But to know the inplace buffer size would probably require some profiling and measurement of string sizes... otherwise it is just a wild guess... Maybe for testing, you can swap out the string header file on your system with one that logs allocations/string sizes, and perhaps also profiles the time it takes to make each allocation? The interesting question is: could inplace storage be used for 95% of the cases such that fussing with string interning becomes unnecessary complexity? If so, then you mentioned equality comparison as another issue: the interesting question there is how much time is spent on allocations vs comparisons... In another application I worked on, I was able to get a big improvement in performance by replacing usage of std::vector in one place with a custom vector that stack-allocated the first 10 items (i.e. fixed-size C array as a member variable of the class), and then reverted to a regular vector after that. But to pick the number "10" required some profiling/measurement. The remaining use of the heap was so negligible as to not be worth improving. Best regards, James Johnston From mail at milianw.de Sat Jan 23 10:40:47 2016 From: mail at milianw.de (Milian Wolff) Date: Sat, 23 Jan 2016 16:40:47 +0100 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: <032a01d1553e$1fbba6e0$5f32f4a0$@motionview3d.com> References: <56923C33.6030506@gmail.com> <8917442.8CjU5Q4uo4@agathebauer> <032a01d1553e$1fbba6e0$5f32f4a0$@motionview3d.com> Message-ID: <2205692.RUNk4MiS7L@agathebauer> On Freitag, 22. Januar 2016 17:55:46 CET James Johnston wrote: > > -----Original Message----- > > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > > On Behalf Of Milian Wolff > > Sent: Thursday, January 21, 2016 22:31 > > To: Daniel Pfeifer > > Cc: CMake Developers; Stephen Kelly > > Subject: Re: [cmake-developers] CMake daemon for user tools > > > > > What do you think about string interning? I started a cmString class > > > [2] that stores short strings inplace and puts long strings into a > > > pool. Copies never allocate extra memory and equality comparison is > > > always O(1). > > > In addition to `operator<` (which is lexicographical) there is a O(1) > > > comparison that can be used where lexicographical ordering is not > > > required (ie. for lookup tables). > > > > > > [1] https://en.wikipedia.org/wiki/String_interning > > > [2] https://github.com/purpleKarrot/CMake/commits/string-pool > > > > Imo, you should replace this custom code by a boost::flyweight of > > std::string. > > > That said, I think this can have a significant impact on the memory > > footprint > > > of CMake, considering how heavy it relies on strings internally. But it > > also > > > seems to mutate strings a lot. I've seen places e.g. where a list of > > compile- > > > time known identifiers is prepended with "CMAKE_" at runtime. This is slow > > with normal strings (reallocations), but will also be slow with a > > flyweight or > > > interning, possibly even leading to the pollution of the internal pool > > with > > > temporary strings. > > > > Did you measure any impact on both, runtime speed and memory footprint > > yet? > > I was wondering the same. I would guess maybe the biggest impact would be > the inplace storage of strings for small sized strings. But to know the > inplace buffer size would probably require some profiling and measurement of > string sizes... otherwise it is just a wild guess... You are aware that modern std::string is SSO'ed? I'm running on such a system. Another reason why you should not reinvent the wheel and keep relying on the STL wherever possible. > Maybe for testing, you can swap out the string header file on your system > with one that logs allocations/string sizes, and perhaps also profiles the > time it takes to make each allocation? The data recorded by heaptrack would allow such an analysis post-mortem without modification of any header. Someone just needs to write such an analysis step... > The interesting question is: could inplace storage be used for 95% of the > cases such that fussing with string interning becomes unnecessary > complexity? If so, then you mentioned equality comparison as another issue: > the interesting question there is how much time is spent on allocations vs > comparisons... Just run cmake (or the daemon) through a profiler and check the results. Doing so for the daemon (built with RelWithDebInfo) on the LLVM build dir and recording it with `perf --call-graph lbr` I get these hotspots when looking at the results with `perf report -g graph --no-children`: + 8.67% cmake cmake [.] cmGlobalGenerator::FindGeneratorTargetImpl + 4.21% cmake libc-2.22.so [.] _int_malloc + 2.67% cmake cmake [.] cmCommandArgument_yylex + 2.09% cmake libc-2.22.so [.] _int_free + 2.06% cmake libc-2.22.so [.] __memcmp_sse4_1 + 1.84% cmake libc-2.22.so [.] malloc This already shows you that you can gain a lot by reducing the number of allocations done. Heaptrack is a good tool for that. Similarly, someone should investigate cmGlobalGenerator::FindGeneratorTargetImpl. That does a lot of string comparisons to find targets from my quick glance, so indeed could be sped up with a smarter string class. But potentially you could also get a much quicker lookup by storing a hash map of target name to cmGeneratorTarget. > In another application I worked on, I was able to get a big improvement in > performance by replacing usage of std::vector in one place with a custom > vector that stack-allocated the first 10 items (i.e. fixed-size C array as a > member variable of the class), and then reverted to a regular vector after > that. But to pick the number "10" required some profiling/measurement. > The remaining use of the heap was so negligible as to not be worth > improving. Qt has such a class, it's called QVarLengthArray, and I've also been able to apply it in multiple occasions to good effect. That said, when you look at where time is spent in CMake on allocations (either using perf or heaptrack), you'll come across the following hotspots: + 0.83% cmMakefile::ExecuteCommand + 0.28% cmFunctionHelperCommand::InvokeInitialPass + 0.21% cmMakefile::ExpandArguments + 0.18% cmMakefile::ExpandVariablesInString + 0.12% cmMakefile::ExpandVariablesInStringOld + 0.11% cmCommandArgumentParserHelper::ParseString Note that these numbers are the global fraction of time spent in _int_malloc. You get another chunk of similar size (a bit less) for _int_free again. Also note that removing allocations usually improves cache utilization, which often dramatically increases the performance outside of what the cycle samples reported by perf would indicate. Seems like there's more than enough areas one could (and should) optimize CMake. Cheers -- Milian Wolff mail at milianw.de http://milianw.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From steveire at gmail.com Sun Jan 24 17:44:59 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 24 Jan 2016 23:44:59 +0100 Subject: [cmake-developers] CMake Daemon blog Message-ID: Hi, I just made a blog and video about the advanced features and possibilities that a daemon mode for CMake can bring: https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ I'll make the code available by the end of the week. I still want to clean it up a little bit first :). Thanks, Steve. From tamas.kenez at gmail.com Mon Jan 25 04:50:07 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Mon, 25 Jan 2016 10:50:07 +0100 Subject: [cmake-developers] CMake Daemon blog In-Reply-To: References: Message-ID: That's great and really does open a new world for IDEs! Tamas On Sun, Jan 24, 2016 at 11:44 PM, Stephen Kelly wrote: > Hi, > > I just made a blog and video about the advanced features and possibilities > that a daemon mode for CMake can bring: > > https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ > > I'll make the code available by the end of the week. I still want to clean > it up a little bit first :). > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.barinov at samsung.com Mon Jan 25 08:06:47 2016 From: v.barinov at samsung.com (Vyacheslav Barinov) Date: Mon, 25 Jan 2016 16:06:47 +0300 Subject: [cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set In-Reply-To: <87lh7dlsmz.fsf@samsung.com> References: <87lh7dlsmz.fsf@samsung.com> Message-ID: <87egd5lsew.fsf@samsung.com> Hello, I try to detect paths to some tools using CMake and got the following problem: if the tool I try to check has 611 (-rw--x--x) rights FIND_PROGRAM reports the file does not exists. For instance my /bin/mount in Gentoo has such setup and therefore I can use it from shell but can't detect it from CMakeLists.txt. Is it bug or normal behavior for CMake? Best Regards, Vyacheslav Barinov From ben.boeckel at kitware.com Mon Jan 25 08:27:58 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Jan 2016 08:27:58 -0500 Subject: [cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set In-Reply-To: <87egd5lsew.fsf@samsung.com> References: <87lh7dlsmz.fsf@samsung.com> <87egd5lsew.fsf@samsung.com> Message-ID: <20160125132758.GA16424@megas.kitware.com> On Mon, Jan 25, 2016 at 16:06:47 +0300, Vyacheslav Barinov wrote: > I try to detect paths to some tools using CMake and got the following problem: > if the tool I try to check has 611 (-rw--x--x) rights FIND_PROGRAM reports the > file does not exists. > > For instance my /bin/mount in Gentoo has such setup and therefore I can use it > from shell but can't detect it from CMakeLists.txt. > > Is it bug or normal behavior for CMake? It's both :) . FileExists is implemented using access() rather than something like lstat(), so that would indeed be not a "program" since the file doesn't "exist". It was on my list to fix, but the backwards compatibility argument (IIRC) made it near impossible to change. --Ben From brad.king at kitware.com Mon Jan 25 09:19:56 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 25 Jan 2016 09:19:56 -0500 Subject: [cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set In-Reply-To: <20160125132758.GA16424@megas.kitware.com> References: <87lh7dlsmz.fsf@samsung.com> <87egd5lsew.fsf@samsung.com> <20160125132758.GA16424@megas.kitware.com> Message-ID: <56A62F0C.4070202@kitware.com> On 01/25/2016 08:27 AM, Ben Boeckel wrote: > It's both :) . FileExists is implemented using access() rather than > something like lstat(), so that would indeed be not a "program" since > the file doesn't "exist". > > It was on my list to fix, but the backwards compatibility argument > (IIRC) made it near impossible to change. There are related issues here: https://cmake.org/Bug/view.php?id=14022 https://cmake.org/Bug/view.php?id=10468 The main compatibility concern is not about find_program, but just about other uses of FileExists. Each time this has come up before we've determined the full solution requires a non-trivial audit of all uses of FileExists. That lost sight of the immediate find_program problem, so instead we could look at fixing just that. Since then we've gained the cmSystemTools::TestFileAccess() function. One could look at porting find_program to use it with TEST_FILE_EXECUTE. The Tests/RunCMake/find_program test could be extended to cover this once it is fixed. -Brad From vladimir.prus at gmail.com Mon Jan 25 09:54:36 2016 From: vladimir.prus at gmail.com (Vladimir Prus) Date: Mon, 25 Jan 2016 17:54:36 +0300 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: <56923C33.6030506@gmail.com> References: <56923C33.6030506@gmail.com> Message-ID: On 10-Jan-16 2:10 PM, Stephen Kelly wrote: > > Hello, > > I've been working on adding a daemon mode for cmake to provide > information to user tools - such as IDEs - about the buildsystem. > > Following the discussion about providing metadata for IDEs to consume > I proposed creating a long-running process which would provide a protocol > to access information about the buildsystem, and about the content of the > cmake files themselves: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 Hi Stephen, this sounds very much like what I has proposed for Boost.Build, see: http://vladimirprus.com/talks/boosting-cdt-builds/ > I am scheduled to give a talk at FOSDEM about the feature and how user > tools can interact with it: > > https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code ... > Is anyone interested enough in this potential cmake feature to > join the development effort? You can guess I'm not very interested in cmake, but maybe we can discuss the protocol, so that an IDE can work with different build systems? Think we can have a chat at FOSDEM? -- Vladimir Prus http://vladimirprus.com From brad.king at kitware.com Mon Jan 25 10:14:32 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 25 Jan 2016 10:14:32 -0500 Subject: [cmake-developers] CMake 3.5 feature freeze on 2016-02-01 In-Reply-To: <55F04ADB.1000003@kitware.com> References: <55F04ADB.1000003@kitware.com> Message-ID: <56A63BD8.7000501@kitware.com> Hi Folks, The feature freeze in 'master' for CMake 3.5 will be on Feb 1, 2016. In order to get 'master' ready to branch for 3.5, 'next' is now frozen to new features. After 3.5 is branched I'll announce when post-3.5 development in 'next' is open. Meanwhile the following types of changes are still welcome in 'next': * Documentation updates * Regression fixes * Fixes for bugs in features new to 3.5 Thanks, -Brad From smspillaz at gmail.com Mon Jan 25 11:01:27 2016 From: smspillaz at gmail.com (Sam Spilsbury) Date: Tue, 26 Jan 2016 00:01:27 +0800 Subject: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake Message-ID: Hi all, By way of introduction you might remember me as a maintainer of Compiz between 2009 and 2012, which is the window and compositing manager still used by Ubuntu today. We used CMake quite heavily in Compiz and so I've learned a great deal about it. Over the last two years I've been working on a new unit testing framework for CMake. I started this project because I've been writing some other fairly complex CMake modules and I kept making mistakes which would take me hours to debug weeks down the line. I would have announced the project's existence a lot earlier, though I became hesitant of doing so when I rewrote it earlier last year. Now that I see there are discussions about potentially changing CMake's scripting language, I figure it is probably better later than never. The project is, rather unimaginatively, called cmake-unit. The key difference between this and the RunCMake framework that's used by CMake internally is that cmake-unit more closely resembles an xUnit architecture. It has support for a generic assert_that function and matchers, test-case autodiscovery, coverage report generation and allows you to keep all your tests together in a single file. The only downside so far is that it runs a fair bit slower than RunCMake does. Presumably this is because under the hood it uses a lot of indirection. On the upside, I have been finding optimisations to help speed things up, so hopefully performance won't be a problem in the future. So far I have it hosted as a third party module on GitHub[0] and it can be added as a dependency to biicode projects[1]. I also wrote a blog post which gives a little bit more detail as to how it all works [2]. The project has reached a relatively mature state by this point and I have used it in several of my own projects successfully. I'd like to reach out to a broader audience and get some more feedback to keep things moving forward. One thing I'm not sure about is whether this is an appropriate kind of project to integrate into the CMake mainline. If that were to occur, it'd have the upside of bringing the functionality to many more users. The immediate problems I foresee are dealing with how this framework would interact with RunCMake and also dealing with some of the hacks that cmake-unit uses internally. In particular, calling arbitrary functions is done by abusing variable_watch, which works, but isn't exactly ideal. Feedback and patches definitely appreciated, Best Regards, Sam Spilsbury. [0] http://github.com/polysquare/cmake-unit [1] http://biicode.com/smspillaz/cmake-unit [2] https://smspillaz.wordpress.com/2016/01/25/a-unit-testing-framework-for-cmake/ -- Sam Spilsbury From JamesJ at motionview3d.com Mon Jan 25 11:05:55 2016 From: JamesJ at motionview3d.com (James Johnston) Date: Mon, 25 Jan 2016 16:05:55 -0000 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: <2205692.RUNk4MiS7L@agathebauer> References: <56923C33.6030506@gmail.com> <8917442.8CjU5Q4uo4@agathebauer> <032a01d1553e$1fbba6e0$5f32f4a0$@motionview3d.com> <2205692.RUNk4MiS7L@agathebauer> Message-ID: <049901d1578a$4633ac70$d29b0550$@motionview3d.com> > -----Original Message----- > From: Milian Wolff [mailto:mail at milianw.de] > Sent: Saturday, January 23, 2016 15:41 > To: cmake-developers at cmake.org > Cc: James Johnston > Subject: Re: [cmake-developers] CMake daemon for user tools > > You are aware that modern std::string is SSO'ed? I'm running on such a > system. > Another reason why you should not reinvent the wheel and keep relying on > the STL wherever possible. > > Qt has such a class, it's called QVarLengthArray, and I've also been able to > apply it in multiple occasions to good effect. That said, when you look at Yeah, but std::string is platform dependent, and the size of the buffer is also platform dependent. Maybe it tends to be optimal for CMake. Then again, maybe a larger buffer is needed. I don't know. The flexible option would be something that does exactly like QVarLengthArray. Different variables might have different optimal sizes. Some sample small strings for gcc/clang/VC++: http://stackoverflow.com/a/28003328/562766 Note that none of them are large enough to store an absolute path, which are maybe common (???) in CMake. Also there's a fair bit of variation; if CMake wants consistent performance in a section of code across compilers, it would need a way to explicitly specify the small string size. For example, some are large enough to store typical target sizes - and some maybe are not. There is also boost::container::small_vector in addition to QVarLengthArray: http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.h tml > Just run cmake (or the daemon) through a profiler and check the results. > Doing so for the daemon (built with RelWithDebInfo) on the LLVM build dir > and recording it with `perf --call-graph lbr` I get these hotspots when looking > at the results with `perf report -g graph --no-children`: > > + 8.67% cmake cmake [.] > cmGlobalGenerator::FindGeneratorTargetImpl > + 4.21% cmake libc-2.22.so [.] _int_malloc > + 2.67% cmake cmake [.] cmCommandArgument_yylex > + 2.09% cmake libc-2.22.so [.] _int_free > + 2.06% cmake libc-2.22.so [.] __memcmp_sse4_1 > + 1.84% cmake libc-2.22.so [.] malloc > > This already shows you that you can gain a lot by reducing the number of > allocations done. Heaptrack is a good tool for that. Next question would be: who is calling malloc? Or rather, what % of callers are std::string, std::vector, other STL classes vs custom data structures? Next question would be: what is the size of those mallocs, for each caller? (Sorry I don't currently have an environment set up with a profiler to test this myself at the moment.) > Similarly, someone should > investigate cmGlobalGenerator::FindGeneratorTargetImpl. That does a lot of > string comparisons to find targets from my quick glance, so indeed could be > sped up with a smarter string class. > > But potentially you could also get a much quicker lookup by storing a hash > map of target name to cmGeneratorTarget. Indeed; there has got to be a way to reduce the complexity of that function in number of targets compared, if not the low-level string comparison itself as well. For example, if target names are short-ish, the string class has large enough SSO, and the underlying string class made use of vector CPU instructions for comparison, there is probably very little to be gained without such a hash map. (On the other hand, if some of the previous assumptions are not true on some common CMake platforms....) > Seems like there's more than enough areas one could (and should) optimize > CMake. Indeed. Another idea - probably unrelated to the string allocations issue, but still - that came to mind: what if link-time code generation/optimization is turned on? IIRC this is not default in CMake. Maybe CMake is sufficiently well-organized (e.g. small functions implementations moved to header files) such that what needs to be inlined across units, is already being inlined. Then again, maybe it's not. I've seen other projects rely on this feature to keep clean organization by keeping implementations in .CPP files without sacrificing performance, and when you turn off LTCG performance takes a major hit... Also IIRC there are still a few optimizations that are turned off when CMake is built with RelWithDebInfo instead of Release. I forget the exact specifics at the moment but e.g. on Visual C++ when you ask it to turn on debug symbols, it will change the default values of some optimization flags. So a cursory examination of the flags wouldn't reveal all cases. However, one of my bigger performance gripes, being a primarily Windows developer right now, is the process creation overhead, especially during configuration. I think that is completely dominating over any CMake code being run internally. It would be nice if that could be parallelized on my 6-core hyper-threaded CPU, but doing so properly probably isn't so easy... Best regards, James Johnston From robert.maynard at kitware.com Mon Jan 25 14:36:38 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 25 Jan 2016 14:36:38 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.3 available for download Message-ID: We are pleased to announce that CMake 3.4.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.4.3 since 3.4.2: Brad King (2): VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929) CMake 3.4.3 From steveire at gmail.com Mon Jan 25 16:14:02 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 25 Jan 2016 22:14:02 +0100 Subject: [cmake-developers] CMake daemon for user tools References: <56923C33.6030506@gmail.com> Message-ID: Vladimir Prus wrote: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 > > Hi Stephen, > > this sounds very much like what I has proposed for Boost.Build, see: > > http://vladimirprus.com/talks/boosting-cdt-builds/ Yes, I'm familiar with that. It is listed as prior art in the gmane link you quoted :) >> I am scheduled to give a talk at FOSDEM about the feature and how user >> tools can interact with it: >> >> https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code > ... >> Is anyone interested enough in this potential cmake feature to >> join the development effort? > > You can guess I'm not very interested in cmake, but maybe we can discuss > the protocol, so that an IDE can work with different build systems? Think > we can have a chat at FOSDEM? Yep, sounds good to me. I don't have a schedule decided yet for which talks I'll attend, but I should be reachable by email to arrange to meet. I assume you've seen https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ Thanks, Steve. From steveire at gmail.com Mon Jan 25 16:16:22 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 25 Jan 2016 22:16:22 +0100 Subject: [cmake-developers] Anyone going to FOSDEM? References: <5683DD14.2040300@googlemail.com> <2310101.S9Z750qJPX@horus> Message-ID: Benjamin Eikel wrote: > Hi Gregor, > > Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake- > developers: >> Hello, >> >> I wonder if any of you CMake Developers go to FOSDEM [1] this year? > > I am not a CMake developer, but, more or less, an advanced user, but I > will go to FOSDEM next year. ;-) > At least Stephen Kelly [2] will be there, too. Yep. Maybe we could arrange to meet in the Sunday evening. I leave on the Monday. Thanks, Steve. From mantis at public.kitware.com Tue Jan 26 02:58:12 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 26 Jan 2016 02:58:12 -0500 Subject: [cmake-developers] [CMake 0015934]: There's no way to test whether a given *linker* flag works Message-ID: <0e9074ec0468c4d0ebba51b3c9bfd180@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15934 ====================================================================== Reported By: Guy Harris Assigned To: ====================================================================== Project: CMake Issue ID: 15934 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-26 02:58 EST Last Modified: 2016-01-26 02:58 EST ====================================================================== Summary: There's no way to test whether a given *linker* flag works Description: There are macros to test whether a given *compiler* flag works, such as CHECK_C_COMPILER_FLAG and CHECK_CXX_COMPILER_FLAG. There is no macro to test whether a given *linker* flag works. Furthermore, there does not appear to be a way to do a CHECK_C_SOURCE_RUNS with a given *linker* flag, so there does not appear to be a way to *write* a macro to test whether a given linker flag works. Setting CMAKE_REQUIRED_FLAGS does *not* affect what flags are used with, for example, the Xcode generator; it works with the Unix makefile generator, but that's not sufficient to support multiple build systems. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-26 02:58 Guy Harris New Issue ====================================================================== From mantis at public.kitware.com Tue Jan 26 05:32:40 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 26 Jan 2016 05:32:40 -0500 Subject: [cmake-developers] [CMake 0015935]: Empty generator expression in COMMAND leads to "" Message-ID: <09f036c1b393b15d683983f7dc8e8f15@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15935 ====================================================================== Reported By: Kiron Assigned To: ====================================================================== Project: CMake Issue ID: 15935 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-26 05:32 EST Last Modified: 2016-01-26 05:32 EST ====================================================================== Summary: Empty generator expression in COMMAND leads to "" Description: When an $<0:...> generator expression in a COMMAND argument of add_custom_command (and add_custom_target) the Visual Studio generator generates an invalid command "". When using a normal variable which is empty or not set, the COMMAND argument is just ignored. Steps to Reproduce: Create a file called CMakeLists.txt with the following content in an empty directory: cmake_minimum_required(VERSION 3.0 FATAL_ERROR) cmake_policy(VERSION 3.0) project(EmptyGenExCommand LANGUAGES CXX VERSION 0.0.1.0) set(_stamp ${CMAKE_BINARY_DIR}/foo.stamp) add_custom_command(OUTPUT ${_stamp} COMMAND $<$>:$> COMMAND ${CMAKE_COMMAND} -E echo foo is done WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" ) add_custom_target(foo ALL DEPENDS ${_stamp}) #set_property(TARGET foo PROPERTY FOOCMD ${CMAKE_COMMAND} -E sleep 1) Additional Information: Tested with cmake version 3.4.3 under Windows 7 64 bit. When using the Visual Studio generator the vcxproj contains: [...] setlocal cd S:\abc if %errorlevel% neq 0 goto :cmEnd S: if %errorlevel% neq 0 goto :cmEnd "" if %errorlevel% neq 0 goto :cmEnd When trying to execute "" the following error from cmd.exe is generated: '""' is not recognized as an internal or external command, operable program or batch file. Also when setting the FOOCMD property to an actual command (e.g.: set_property(TARGET foo PROPERTY FOOCMD ${CMAKE_COMMAND} -E sleep 1)) it will not work, since it evaluates to "C:\Program Files (x86)\CMake\bin\cmake.exe";"-E";"sleep";"1" or with quotes in the set_property command it evaluates to "C:\Program Files (x86)\CMake\bin\cmake.exe -E sleep 1". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-26 05:32 Kiron New Issue ====================================================================== From mantis at public.kitware.com Tue Jan 26 06:50:20 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 26 Jan 2016 06:50:20 -0500 Subject: [cmake-developers] [CMake 0015936]: UseJava add_jar incorrect documentation for target property Message-ID: <4bfb7c57ac8fe274be9f0367534a14a9@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15936 ====================================================================== Reported By: Erik Hanspers Assigned To: ====================================================================== Project: CMake Issue ID: 15936 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-26 06:50 EST Last Modified: 2016-01-26 06:50 EST ====================================================================== Summary: UseJava add_jar incorrect documentation for target property Description: The UseJava module documents a CLASS_DIR target property being set. The code actually sets a property CLASSDIR, without the underscore. Steps to Reproduce: add_jar(foo SOURCES blah.java) get_target_property(foo_classdir foo CLASS_DIR) -> not set get_target_property(foo_classdir foo CLASSIER) -> we got the path! Additional Information: Suggest revising documentation not to break currently successful use of the CLASSDIR property. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-26 06:50 Erik Hanspers New Issue ====================================================================== From cmake at eikel.org Tue Jan 26 10:19:43 2016 From: cmake at eikel.org (Benjamin Eikel) Date: Tue, 26 Jan 2016 15:19:43 +0000 Subject: [cmake-developers] Anyone going to FOSDEM? In-Reply-To: References: <5683DD14.2040300@googlemail.com> <2310101.S9Z750qJPX@horus> Message-ID: <20160126151943.Horde.5goDYTA6rDranyyBqqyuwS0@webmail.eikel.org> Hi Steve, Zitat von Stephen Kelly : > Benjamin Eikel wrote: > >> Hi Gregor, >> >> Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake- >> developers: >>> Hello, >>> >>> I wonder if any of you CMake Developers go to FOSDEM [1] this year? >> >> I am not a CMake developer, but, more or less, an advanced user, but I >> will go to FOSDEM next year. ;-) >> At least Stephen Kelly [2] will be there, too. > > Yep. Maybe we could arrange to meet in the Sunday evening. I leave on the > Monday. unfortunately, I will leave already on Sunday. But we can have a chat directly after your talk. Cheers Benjamin > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From vladimir.prus at gmail.com Tue Jan 26 14:21:31 2016 From: vladimir.prus at gmail.com (Vladimir Prus) Date: Tue, 26 Jan 2016 22:21:31 +0300 Subject: [cmake-developers] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: On 26-Jan-16 12:14 AM, Stephen Kelly wrote: > Vladimir Prus wrote: >> > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 >> >> Hi Stephen, >> >> this sounds very much like what I has proposed for Boost.Build, see: >> >> http://vladimirprus.com/talks/boosting-cdt-builds/ > > Yes, I'm familiar with that. It is listed as prior art in the gmane link you > quoted :) :-) >>> I am scheduled to give a talk at FOSDEM about the feature and how user >>> tools can interact with it: >>> >>> > https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code >> ... >>> Is anyone interested enough in this potential cmake feature to >>> join the development effort? >> >> You can guess I'm not very interested in cmake, but maybe we can discuss >> the protocol, so that an IDE can work with different build systems? Think >> we can have a chat at FOSDEM? > > Yep, sounds good to me. I don't have a schedule decided yet for which talks > I'll attend, but I should be reachable by email to arrange to meet. I assume > you've seen > > https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ Yes, that is quite impressive. I don't have a schedule yet either, but I am going to attend your talk, so we can sync there. -- Vladimir Prus http://vladimirprus.com From foss at grueninger.de Tue Jan 26 16:16:13 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Tue, 26 Jan 2016 22:16:13 +0100 Subject: [cmake-developers] Improve FindGit.cmake Message-ID: <56A7E21D.6010609@grueninger.de> Dear CMake devs, please find attached a patch to slightly improve FindGit.cmake. I did test it, but did not understand why GIT_FOUND was set in the first place. Bye Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindGit-Document-Git_FOUND-unset-helper-variable-cap.patch Type: text/x-patch Size: 2121 bytes Desc: not available URL: From brad.king at kitware.com Wed Jan 27 09:29:53 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 27 Jan 2016 09:29:53 -0500 Subject: [cmake-developers] Improve FindGit.cmake In-Reply-To: <56A7E21D.6010609@grueninger.de> References: <56A7E21D.6010609@grueninger.de> Message-ID: <56A8D461.3060402@kitware.com> On 01/26/2016 04:16 PM, Christoph Gr?ninger wrote: > Dear CMake devs, > please find attached a patch to slightly improve FindGit.cmake. > > I did test it, but did not understand why GIT_FOUND was set in the first > place. The FPHSA helper sets both for historical reasons. We once had a convention of UPPERCASE names for find module results instead of ExactCase. Thanks for the patch. Applied: FindGit: Document Git_FOUND, unset internal var https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=facfb52c I followed it up with some documentation formatting improvements: FindGit: Improve documentation formatting https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa78ee97 Thanks, -Brad From konstantin at podsvirov.pro Wed Jan 27 14:26:12 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 27 Jan 2016 22:26:12 +0300 Subject: [cmake-developers] [DaD] New and Updated Modules and New Installers Message-ID: <816171453922772@web20m.yandex.ru> Hello, dear developers! Once again, I apologize for using your lists, but my project still don't have your list :-) Time passes and Dad's Project develops. I have over 2 years building and share a few, I think interesting modules. Let me remind you that the official Dad's House on the Internet: http://dad.podsvirov.pro I have prepared and laid out the releases for 2014 and 2015. Here are the special installers: http://download.podsvirov.pro/installers/dad-0.2.0-windows-vc12x86-2014.exe http://download.podsvirov.pro/installers/dad-0.2.0-windows-vc12x64-2014.exe and http://download.podsvirov.pro/installers/dad-0.3.0-windows-vc12x86-2015.exe http://download.podsvirov.pro/installers/dad-0.3.0-windows-vc12x64-2015.exe Versions of modules in these installers frozen and will not change if not necessary. On the website you can compare the components and the versions of relevant modules for installers (links Details). Installers stable/testing/unstable continue to evolve. As always, questions and suggestions are welcome. The project is in Beta stage. For errors I would be grateful. If you use my installers and proved to be helpful in your project, then write about their experiences. (sorry for possible mistakes in text) -- Regards, Konstantin Podsvirov From mantis at public.kitware.com Thu Jan 28 02:29:34 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 28 Jan 2016 02:29:34 -0500 Subject: [cmake-developers] [CMake 0015937]: ccmake no longer permits setting CMAKE_CXX_COMPILER and no longer finds ccache Message-ID: <6115be2ecdec150ffcbcb9e866ecf8fe@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15937 ====================================================================== Reported By: Michi Henning Assigned To: ====================================================================== Project: CMake Issue ID: 15937 Category: CCMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-28 02:29 EST Last Modified: 2016-01-28 02:29 EST ====================================================================== Summary: ccmake no longer permits setting CMAKE_CXX_COMPILER and no longer finds ccache Description: I have ccache in my path as the first directory. With older versions of cmake, I could run "ccmake .." and it would find and set the C and C++ compiler according to what was in my path, meaning that the ccache version of the compiler was found automatically. With the current version of cmake/ccmake, this no longer works. /usr/lib/ccache/cc and /usr/lib/ccache/c++ are no longer detected as the compilers, and it appears to be impossible to change which compiler is used from ccmake. This is also annoying because, previously, I could easily switch between gcc and clang via ccmake, by simply changing the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER settings. But now, these settings are no longer shown. Could you restore the previous functionality please? Having to endlessly change this from the command line is really tedious. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-28 02:29 Michi Henning New Issue ====================================================================== From mantis at public.kitware.com Thu Jan 28 04:30:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 28 Jan 2016 09:30:15 +0000 Subject: [cmake-developers] [CMake 0015938]: RPATHs missing on link line for versioned libraries (.so.MAJOR.MINOR.PATCH) Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15938 ====================================================================== Reported By: Florian Rathgeber Assigned To: ====================================================================== Project: CMake Issue ID: 15938 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-28 09:30 GMT Last Modified: 2016-01-28 09:30 GMT ====================================================================== Summary: RPATHs missing on link line for versioned libraries (.so.MAJOR.MINOR.PATCH) Description: When linking against a library using the *full path* to a *versioned* .so file, the RPATH (-Wl,-rpath,/full/path or equivalent) is missing from the link line. It *does* work when using the non-versioned library ending in .so Steps to Reproduce: Build CGAL 4.7, which exports libCGAL.so.11.0.1 as CGAL_LIBRARY in its CGALExports.cmake Use in your CMake project similar to the following: ... find_package( CGAL REQUIRED ) ... target_link_libraries( my_exe ${CGAL_LIBRARY} ) Additional Information: Looks like a "parser error" to me, potentially regex too narrow? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-28 09:30 Florian RathgeberNew Issue ====================================================================== From mantis at public.kitware.com Thu Jan 28 07:40:29 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 28 Jan 2016 07:40:29 -0500 Subject: [cmake-developers] [CMake 0015939]: Support for link time optimization for recent GCC compilers Message-ID: <7e53130684f41ac3d0f172351ea967fc@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15939 ====================================================================== Reported By: pavel.odintsov Assigned To: ====================================================================== Project: CMake Issue ID: 15939 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-01-28 07:40 EST Last Modified: 2016-01-28 07:40 EST ====================================================================== Summary: Support for link time optimization for recent GCC compilers Description: Hello! I tried to play with INTERPROCEDURAL_OPTIMIZATION on cmake 3.4.2 but found it's not working really well. After short grep'ing over source I have found there are not support for this option for non Intel compilers. So I could like to ask for LTO support for cmake for GCC compiler. Recent GCC compilers do very-very big amount of code optimization and it's very important to have this option in project build system. Thanks a lot! ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-28 07:40 pavel.odintsov New Issue ====================================================================== From taylor at braun-jones.org Thu Jan 28 11:04:17 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Thu, 28 Jan 2016 11:04:17 -0500 Subject: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects In-Reply-To: References: Message-ID: On Sat, Mar 28, 2015 at 10:38 AM, Taylor Braun-Jones wrote: > > See htop screenshot below for an example of what I mean. Note that `ninja` in the original command line invocation is just a bash alias for ninja-build (the name of the ninja binary on Fedora-based systems) > > Should I expect to see the -l3 option to be propagated automatically to the sub projects of my superbuild? Or do I need to do some special cmake configuration to make this happen? Or is this just a known issue? I'm still seeing this behavior with CMake 3.4.1. Here's a friendlier plaintext representation of the previous htop screenshot snippet: ninja -l3 ??? /usr/bin/ninja-build ??? /usr/bin/ninja-build ??? /usr/bin/ninja-build Is this expected behavior, a known bug, or a new bug that I should file? Note that this example shows the -l option not being propagated, but I think all of the following Ninja options should be propagated: -l N do not start new jobs if the load average is greater than N -n dry run (don't run commands but act like they succeeded) -v show all command lines while building -d stats print operation counts/timing info -d explain explain what caused a command to execute -t clean clean built files -t commands list all commands required to rebuild given targets Thanks, Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jan 28 11:18:04 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 28 Jan 2016 11:18:04 -0500 Subject: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects In-Reply-To: References: Message-ID: <56AA3F3C.7080506@kitware.com> On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote: > Is this expected behavior, a known bug, or a new bug that I should file? Currently it is expected, but I don't think anyone has thoroughly investigated it or tried to implement it. IIRC it works in Makefile generators only because the make tool does it under the hood when one uses $(MAKE) in a makefile to run another make. It is a feature of the build tool itself, not of CMake. Unless Ninja offers some equivalent it may not be possible. -Brad From nicolas.despres at gmail.com Thu Jan 28 11:28:51 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Thu, 28 Jan 2016 17:28:51 +0100 Subject: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects In-Reply-To: <56AA3F3C.7080506@kitware.com> References: <56AA3F3C.7080506@kitware.com> Message-ID: On Thu, Jan 28, 2016 at 5:18 PM, Brad King wrote: > On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote: > > Is this expected behavior, a known bug, or a new bug that I should file? > > Currently it is expected, but I don't think anyone has thoroughly > investigated it or tried to implement it. IIRC it works in Makefile > generators only because the make tool does it under the hood when > one uses $(MAKE) in a makefile to run another make. It is a feature > of the build tool itself, not of CMake. Unless Ninja offers some > equivalent it may not be possible. > > Unfortunately, Ninja won't offer it: https://github.com/ninja-build/ninja/pull/1079 -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Thu Jan 28 12:47:48 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Thu, 28 Jan 2016 18:47:48 +0100 Subject: [cmake-developers] Namespaces Message-ID: Hello, I am adding several third-party projects as static libraries in my project. This is what I do: CMakeLists.txt | \-- 3rdparty | \---- pugixml | \---- QtZeroConf | \---- QtDropBox | \---- websocketpp In the root CMakeLists.txt, I have: add_subdirectory(3rdparty) And in 3rdparty/CMakeLists.txt: add_subdirectory(pugixml/scripts) add_subdirectory(QtZeroConf) add_subdirectory(QtDropBox) add_subdirectory(websocketpp) This is an easy way to work with third-party dependences. My problem comes from the fact several of these third-party libraries use common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc). Has some kind of namespacing been considered for add_subdirectory? E. g. add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) Which would lead to all the variables defined QtZeroConf/CMakeLists.txt having a QTZEROCONF_ prefix, e. g. instead of BUILD_SHARED it would now be QTZEROCONF_BUILD_SHARED. Or, as an alternative: add_subdirectory QtZeroConf NAMESPACE QtZeroConf) and variables would be prefixed by QtZeroConf::, e. g. BUILD_SHARED would now be QtZeroConf::BUILD_SHARED. Does that sound sensible? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Jan 28 13:05:29 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 28 Jan 2016 10:05:29 -0800 (PST) Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: On 2016-01-28 18:47+0100 Pau Garcia i Quiles wrote: [...] > In the root CMakeLists.txt, I have: > > add_subdirectory(3rdparty) > > And in 3rdparty/CMakeLists.txt: > > add_subdirectory(pugixml/scripts) > add_subdirectory(QtZeroConf) > add_subdirectory(QtDropBox) > add_subdirectory(websocketpp) > > This is an easy way to work with third-party dependences. > > My problem comes from the fact several of these third-party libraries use > common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc). > > Has some kind of namespacing been considered for add_subdirectory? I cannot answer that question, but I suggest instead that the proper way to deal with third-party libraries with no name contamination from the parent project is simply to build and install them using the ExternalProject approach. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From steveire at gmail.com Thu Jan 28 13:17:11 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 28 Jan 2016 19:17:11 +0100 Subject: [cmake-developers] Namespaces References: Message-ID: Pau Garcia i Quiles wrote: > add_subdirectory(pugixml/scripts) > add_subdirectory(QtZeroConf) > add_subdirectory(QtDropBox) > add_subdirectory(websocketpp) > > This is an easy way to work with third-party dependences. Unfortunately this is 'easy, obvious and wrong'. > My problem comes from the fact several of these third-party libraries use > common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc). And indeed this is why. > Has some kind of namespacing been considered for add_subdirectory? > > E. g. > > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) And what if someone builds your project with -DBUILD_SHARED=ON? Are you going to use set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED}) add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) for every variable you're wrapping? Or do you want cmake to do that for every variable in scope when the directory is added? How would cmake decide which variables to namespace? You should use ExternalProject instead, or fork the buildsystem of those projects to integrate them into your project. Not that I recommend the latter for you though :). That's what cmake does when integrating 3rd party code. Thanks, Steve. From pgquiles at elpauer.org Thu Jan 28 13:58:22 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Thu, 28 Jan 2016 19:58:22 +0100 Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: On Thu, Jan 28, 2016 at 7:17 PM, Stephen Kelly wrote: > > Has some kind of namespacing been considered for add_subdirectory? > > > > E. g. > > > > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > And what if someone builds your project with -DBUILD_SHARED=ON? Are you > going to use > > set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED}) > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > for every variable you're wrapping? Or do you want cmake to do that for > every variable in scope when the directory is added? How would cmake decide > which variables to namespace? > > CMake should wrap every variable defined under the directory added with add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF), no need for me to manually wrap anything. > You should use ExternalProject instead, or fork the buildsystem of those > projects to integrate them into your project. Not that I recommend the > latter for you though :). That's what cmake does when integrating 3rd party > code. > > Unfortunately ExternalProject does not work well with find_package, e. g. this fill fail: CMakeLists.txt | \--- 3rdparty/CMakeLists.txt \--- server/CMakeLists.txt Where: 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...) and server/CMakeLists.txt contains find_package(QtZeroConf) This can be alleviated by using Hunter ( https://github.com/ruslo/hunter ), by modifying the third-party CMakeLists.txt ( https://coderwall.com/p/y3zzbq ) or by manually setting the imported library location ( http://mirkokiefer.com/blog/2013/03/cmake-by-example/) but it's cumbersome. My solution is much, much easier and requires no modification at all to the third-party. In fact, I think in addition to add_subdirectory( ... NAMESPACE ... ), there should be something like find_package( QtZeroConf EXTERNAL_PROJECT QtZeroConf), indicating the package is built by means of ExternalProject and therefore, finding the package should be delayed until after that external project has been built. That would make the tricks above unnecessary. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Thu Jan 28 14:21:24 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 28 Jan 2016 20:21:24 +0100 Subject: [cmake-developers] Namespaces References: Message-ID: Pau Garcia i Quiles wrote: > CMake should wrap every variable defined under the directory added with > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) So, CMake needs to first determine what variables are used in the QtZeroConf directory (presumably without executing the cmake code there) and then wrap the variables, then execute the cmake code? I must be missing something. I don't think that's possible. > 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...) > > and > > server/CMakeLists.txt contains find_package(QtZeroConf) I think you need: ExternalProject_Add(3rdparty/Whatever ...) ExternalProject_Add(3rdparty/QtZeroConf ...) ExternalProject_Add(server ...) and pass appropriate args to the latter, including where to look for dependencies etc (and dependencies among the ExternalProjects). You might not like this solution, but as far as I know it is the only correct solution built into CMake. Thanks, Steve. From ruslan_baratov at yahoo.com Thu Jan 28 14:25:34 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 29 Jan 2016 02:25:34 +0700 Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: <56AA6B2E.8030600@yahoo.com> On 29-Jan-16 01:17, Stephen Kelly wrote: > Pau Garcia i Quiles wrote: > >> add_subdirectory(pugixml/scripts) >> add_subdirectory(QtZeroConf) >> add_subdirectory(QtDropBox) >> add_subdirectory(websocketpp) >> >> This is an easy way to work with third-party dependences. > Unfortunately this is 'easy, obvious and wrong'. This is wrong because of CMake limitations. Actually I was thinking about "namespacing" subdirectories too. From my point of view we can add namespace prefix every time when command 'project' called. Project Foo: == standalone == project(Foo) add_library(foo ...) # add target foo == as a subdirectory == project(Boo) add_subdirectory(Foo) # target Foo::foo Since regular variables has different scope there is no need to do any updates for them, we need only to do something with globals: targets, cache variables, global properties (?). >> My problem comes from the fact several of these third-party libraries use >> common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc). > And indeed this is why. > >> Has some kind of namespacing been considered for add_subdirectory? >> >> E. g. >> >> add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > And what if someone builds your project with -DBUILD_SHARED=ON? Are you > going to use > > set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED}) > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > for every variable you're wrapping? Or do you want cmake to do that for > every variable in scope when the directory is added? How would cmake decide > which variables to namespace? I think this can be solved by adding extra suboptions to add_subdirectory command. > > You should use ExternalProject instead, or fork the buildsystem of those > projects to integrate them into your project. Not that I recommend the > latter for you though :). That's what cmake does when integrating 3rd party > code. As far as I understand `add_subdirectory(3rdParty/package)` approach used in CMake sources: * zlib: https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L306 * curl: https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L337 * bzip2: https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L355 Ruslo From pgquiles at elpauer.org Thu Jan 28 15:07:13 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Thu, 28 Jan 2016 21:07:13 +0100 Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly wrote: Pau Garcia i Quiles wrote: > > > CMake should wrap every variable defined under the directory added with > > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > So, CMake needs to first determine what variables are used in the > QtZeroConf > directory (presumably without executing the cmake code there) and then wrap > the variables, then execute the cmake code? > I must be missing something. I don't think that's possible. > > I think it's just a matter of adding an "internal note" saying "OK, I'm going to namespace variables from now on" in cmAddSubdirectoryCommand when add_subdirectory contains NAMESPACE, and then modifying the literal of the variable in cmSetCommand.cxx (first argument to AddDefinition here in line 165): this->Makefile->AddDefinition(variable, value.c_str()); https://github.com/Kitware/CMake/blob/master/Source/cmSetCommand.cxx#L165 > 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...) > > > > and > > > > server/CMakeLists.txt contains find_package(QtZeroConf) > > I think you need: > > ExternalProject_Add(3rdparty/Whatever ...) > ExternalProject_Add(3rdparty/QtZeroConf ...) > ExternalProject_Add(server ...) > > and pass appropriate args to the latter, including where to look for > dependencies etc (and dependencies among the ExternalProjects). > > You might not like this solution, but as far as I know it is the only > correct solution built into CMake. > > The only thing I like about that solution is it's doable today with CMake. But I think my approach would prove much easier and direct for developers using CMake: add_subdirectory(dir NAMESPACE blah) and find_package(whatever EXTERNAL_PROJECT epwhatever). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Thu Jan 28 15:13:37 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 28 Jan 2016 21:13:37 +0100 Subject: [cmake-developers] Namespaces References: Message-ID: Pau Garcia i Quiles wrote: > On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly > wrote: > > > Pau Garcia i Quiles wrote: >> >> > CMake should wrap every variable defined under the directory added with >> > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) >> >> So, CMake needs to first determine what variables are used in the >> QtZeroConf >> directory (presumably without executing the cmake code there) and then >> wrap the variables, then execute the cmake code? >> > I must be missing something. I don't think that's possible. >> >> > I think it's just a matter of adding an "internal note" saying "OK, I'm > going to namespace variables from now on" in cmAddSubdirectoryCommand when > add_subdirectory contains NAMESPACE, and then modifying the literal of the > variable in cmSetCommand.cxx (first argument to AddDefinition here in line > 165): > > this->Makefile->AddDefinition(variable, value.c_str()); > > https://github.com/Kitware/CMake/blob/master/Source/cmSetCommand.cxx#L165 I'm happy to provide guidance if you start writing a patch and find that it is a realistic approach, but I still don't think this is possible. What do you do when third party code contains set(SOMETHING foo bar) foreach(thing ${SOMETHING}) ... endforeach() ? Are you going to change every read of a variable to prefix it with a namespace? Thanks, Steve. From taylor at braun-jones.org Thu Jan 28 15:15:58 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Thu, 28 Jan 2016 15:15:58 -0500 Subject: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects In-Reply-To: References: <56AA3F3C.7080506@kitware.com> Message-ID: On Thu, Jan 28, 2016 at 11:28 AM, Nicolas Despr?s wrote: > Unfortunately, Ninja won't offer it: > https://github.com/ninja-build/ninja/pull/1079 That's too bad. I understand the perspective of the Ninja developers, but it's not clear to me what the proposed alternative should be. Should CMake be using the subninja[1] keyword to include the build.ninja of External Projects? [1] https://ninja-build.org/manual.html#ref_scope From ben.boeckel at kitware.com Thu Jan 28 15:19:46 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 28 Jan 2016 15:19:46 -0500 Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: <20160128201946.GA2354@megas.kitware.com> On Thu, Jan 28, 2016 at 21:07:13 +0100, Pau Garcia i Quiles wrote: > I think it's just a matter of adding an "internal note" saying "OK, I'm > going to namespace variables from now on" in cmAddSubdirectoryCommand when > add_subdirectory contains NAMESPACE, and then modifying the literal of the > variable in cmSetCommand.cxx (first argument to AddDefinition here in line > 165): > > this->Makefile->AddDefinition(variable, value.c_str()); This is not the only place variables are created. > The only thing I like about that solution is it's doable today with CMake. > But I think my approach would prove much easier and direct for developers > using CMake: add_subdirectory(dir NAMESPACE blah) and find_package(whatever > EXTERNAL_PROJECT epwhatever). As mentioned elsewhere, what about things like find_package() in the subdirectory? Do they get namespaced as well? Is a cache overflowing with png_ZLIB_LIBRARY, sqlite3_ZLIB_LIBRARY, and so on sensible? Is having to set all of them if the library is in a weird place something you want users to have to do? What about custom properties (be it on targets, directories, global)? Do they also get namespaced? Functions are globally scoped, so what namespace do they apply? What if they have controlling variables from their module which is now namespaced, but called from a non-namespaced location? I think the solution to your problem is to use INTERNAL cache variables (for cache variables created by the third party project) or local variables to override the cache variables in scope (which would likely work for BUILD_SHARED_LIBS or ENABLE_TESTING). --Ben From pgquiles at elpauer.org Thu Jan 28 15:32:17 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Thu, 28 Jan 2016 21:32:17 +0100 Subject: [cmake-developers] Namespaces In-Reply-To: <20160128201946.GA2354@megas.kitware.com> References: <20160128201946.GA2354@megas.kitware.com> Message-ID: On Thu, Jan 28, 2016 at 9:19 PM, Ben Boeckel wrote: > I think the solution to your problem is to use INTERNAL cache variables > (for cache variables created by the third party project) or local > variables to override the cache variables in scope (which would likely > work for BUILD_SHARED_LIBS or ENABLE_TESTING). > > Unfortunately, using INTERNAL cache variables requires me to modify the third-party library, which is exactly what I do not want to do. I want to be able to drop the third-party in a folder, add_subdirectory and form then on, use it. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Jan 28 15:36:35 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 28 Jan 2016 15:36:35 -0500 Subject: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects In-Reply-To: References: <56AA3F3C.7080506@kitware.com> Message-ID: <20160128203635.GA11605@megas.kitware.com> On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote: > That's too bad. I understand the perspective of the Ninja developers, > but it's not clear to me what the proposed alternative should be. > Should CMake be using the subninja[1] keyword to include the > build.ninja of External Projects? That would be possible with the work that's been done here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364 --Ben From ben.boeckel at kitware.com Thu Jan 28 15:46:10 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 28 Jan 2016 15:46:10 -0500 Subject: [cmake-developers] Namespaces In-Reply-To: References: <20160128201946.GA2354@megas.kitware.com> Message-ID: <20160128204610.GA24363@megas.kitware.com> On Thu, Jan 28, 2016 at 21:32:17 +0100, Pau Garcia i Quiles wrote: > Unfortunately, using INTERNAL cache variables requires me to modify the > third-party library, which is exactly what I do not want to do. How so? set(THIRD_PARTY_FLAG MY_VALUE CACHE INTERNAL "Setting for ${parent_project}") add_subdirectory(thirdparty) > I want to be able to drop the third-party in a folder, > add_subdirectory and form then on, use it. You really should mangle the symbols in the library if you're also distributing libraries yourself. If it's an application, you're fine, but not mangling symbols means you need to install the headers for that project properly and also the library file itself should be installed under a mangled name unless it never intends to live under /usr beside other system software (look at how VTK mangles its third party libraries to play nice with other tools which might have *their* own zlib and friends). --Ben From irwin at beluga.phys.uvic.ca Thu Jan 28 15:58:42 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 28 Jan 2016 12:58:42 -0800 (PST) Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: On 2016-01-28 19:58+0100 Pau Garcia i Quiles wrote: > Unfortunately ExternalProject does not work well with find_package, e. g. > this fill fail: > > CMakeLists.txt > | > \--- 3rdparty/CMakeLists.txt > \--- server/CMakeLists.txt > > Where: > > 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...) > > and > > server/CMakeLists.txt contains find_package(QtZeroConf) Hi Pau: Your experience is contrary to mine. For example, in my epa_build project (where I build all the many prerequisites of PLplot) I build a lot of different libraries (such as Qt5 and the GTK+ stack of libraries) using ExternalProject_Add, and I don't experience any difficulties using find_package to find the installed results. I assume find_package should work well with ExternalProject_Add for you as well so long as (a) all your ExternalProject(s) are configured to do both a build and install (not just a build), and (b) you are being careful in server/CMakeLists.txt to set PATH, CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH consistently with the install prefix used for the ExternalProject(s). By the way, some versions of CMake-3.x.y have been plagued by substantial find issues, and your bad experience with find_package might be related to those issues. However, I haven't experienced any major find issues with CMake-3.3.2 so you might want to shift to that version if you aren't using it already. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From ashley at awhetter.co.uk Thu Jan 28 16:29:10 2016 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Thu, 28 Jan 2016 21:29:10 +0000 Subject: [cmake-developers] [PATCH] Added FILTER subcommand to list command In-Reply-To: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> References: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <1454016550-4646-1-git-send-email-ashley@awhetter.co.uk> --- Taking the previous comments into consideration, the filter subcommand is now of the format: list(FILTER REGEX ) so that the user can choose to include or exclude matches, and so that it's easier to add future modes of operation to the subcommand. I opted for list(FILTER REGEX ) rather than list(FILTER REGEX ) because I think that it reads more nicely this way around. Ashley Help/command/list.rst | 13 ++- Source/cmListCommand.cxx | 109 +++++++++++++++++++++ Source/cmListCommand.h | 6 ++ Tests/RunCMake/list/EmptyFilterRegex-result.txt | 1 + Tests/RunCMake/list/EmptyFilterRegex-stderr.txt | 0 Tests/RunCMake/list/EmptyFilterRegex.cmake | 2 + Tests/RunCMake/list/FILTER-NotList-result.txt | 1 + Tests/RunCMake/list/FILTER-NotList-stderr.txt | 4 + Tests/RunCMake/list/FILTER-NotList.cmake | 2 + .../list/FILTER-REGEX-InvalidMode-result.txt | 1 + .../list/FILTER-REGEX-InvalidMode-stderr.txt | 4 + Tests/RunCMake/list/FILTER-REGEX-InvalidMode.cmake | 2 + .../list/FILTER-REGEX-InvalidOperator-result.txt | 1 + .../list/FILTER-REGEX-InvalidOperator-stderr.txt | 4 + .../list/FILTER-REGEX-InvalidOperator.cmake | 2 + .../list/FILTER-REGEX-InvalidRegex-result.txt | 1 + .../list/FILTER-REGEX-InvalidRegex-stderr.txt | 4 + .../RunCMake/list/FILTER-REGEX-InvalidRegex.cmake | 2 + .../list/FILTER-REGEX-TooManyArguments-result.txt | 1 + .../list/FILTER-REGEX-TooManyArguments-stderr.txt | 4 + .../list/FILTER-REGEX-TooManyArguments.cmake | 2 + Tests/RunCMake/list/FILTER-REGEX-Valid0-result.txt | 1 + Tests/RunCMake/list/FILTER-REGEX-Valid0-stderr.txt | 2 + Tests/RunCMake/list/FILTER-REGEX-Valid0.cmake | 4 + Tests/RunCMake/list/FILTER-REGEX-Valid1-result.txt | 1 + Tests/RunCMake/list/FILTER-REGEX-Valid1-stderr.txt | 2 + Tests/RunCMake/list/FILTER-REGEX-Valid1.cmake | 4 + Tests/RunCMake/list/RunCMakeTest.cmake | 9 ++ 28 files changed, 186 insertions(+), 3 deletions(-) create mode 100644 Tests/RunCMake/list/EmptyFilterRegex-result.txt create mode 100644 Tests/RunCMake/list/EmptyFilterRegex-stderr.txt create mode 100644 Tests/RunCMake/list/EmptyFilterRegex.cmake create mode 100644 Tests/RunCMake/list/FILTER-NotList-result.txt create mode 100644 Tests/RunCMake/list/FILTER-NotList-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-NotList.cmake create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidMode-result.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidMode-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidMode.cmake create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-result.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidOperator.cmake create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-result.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-InvalidRegex.cmake create mode 100644 Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-result.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-TooManyArguments.cmake create mode 100644 Tests/RunCMake/list/FILTER-REGEX-Valid0-result.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-Valid0-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-Valid0.cmake create mode 100644 Tests/RunCMake/list/FILTER-REGEX-Valid1-result.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-Valid1-stderr.txt create mode 100644 Tests/RunCMake/list/FILTER-REGEX-Valid1.cmake diff --git a/Help/command/list.rst b/Help/command/list.rst index a7a05c7..f6b75bc 100644 --- a/Help/command/list.rst +++ b/Help/command/list.rst @@ -9,6 +9,7 @@ List operations. list(GET [ ...] ) list(APPEND [ ...]) + list(FILTER REGEX ) list(FIND ) list(INSERT [ ...]) list(REMOVE_ITEM [ ...]) @@ -23,6 +24,12 @@ List operations. ``APPEND`` will append elements to the list. +``FILTER`` will include or remove items from the list that match the +mode's pattern. +In ``REGEX`` mode, items will be matched against the given regular expression. +For more information on regular expressions see also the :command:`string` +command. + ``FIND`` will return the index of the element specified in the list or -1 if it wasn't found. @@ -38,9 +45,9 @@ difference is that ``REMOVE_ITEM`` will remove the given items, while ``SORT`` sorts the list in-place alphabetically. -The list subcommands ``APPEND``, ``INSERT``, ``REMOVE_AT``, ``REMOVE_ITEM``, -``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new values for -the list within the current CMake variable scope. Similar to the +The list subcommands ``APPEND``, ``INSERT``, ``FILTER``, ``REMOVE_AT``, +``REMOVE_ITEM``, ``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create new +values for the list within the current CMake variable scope. Similar to the :command:`set` command, the LIST command creates new variable values in the current scope, even if the list itself is actually defined in a parent scope. To propagate the results of these operations upwards, use diff --git a/Source/cmListCommand.cxx b/Source/cmListCommand.cxx index 6041fb7..15a1af5 100644 --- a/Source/cmListCommand.cxx +++ b/Source/cmListCommand.cxx @@ -14,6 +14,7 @@ #include #include "cmAlgorithms.h" +#include #include // required for atoi #include #include @@ -68,6 +69,10 @@ bool cmListCommand { return this->HandleReverseCommand(args); } + if(subCommand == "FILTER") + { + return this->HandleFilterCommand(args); + } std::string e = "does not recognize sub-command "+subCommand; this->SetError(e); @@ -517,3 +522,107 @@ bool cmListCommand::HandleRemoveAtCommand( return true; } +//---------------------------------------------------------------------------- +bool cmListCommand::HandleFilterCommand( + std::vector const& args) +{ + if(args.size() < 2) + { + this->SetError("sub-command FILTER requires a list to be specified."); + return false; + } + + if(args.size() < 3) + { + this->SetError("sub-command FILTER requires an operator to be specified."); + return false; + } + + if(args.size() < 4) + { + this->SetError("sub-command FILTER requires a mode to be specified."); + return false; + } + + const std::string& listName = args[1]; + // expand the variable + std::vector varArgsExpanded; + if ( !this->GetList(varArgsExpanded, listName) ) + { + this->SetError("sub-command FILTER requires list to be present."); + return false; + } + + const std::string& op = args[2]; + bool includeMatches; + if(op == "INCLUDE") + { + includeMatches = true; + } + else if(op == "EXCLUDE") + { + includeMatches = false; + } + else + { + this->SetError("sub-command FILTER does not recognize operator " + op); + return false; + } + + const std::string& mode = args[3]; + if(mode == "REGEX") + { + if(args.size() != 5) + { + this->SetError("sub-command FILTER, mode REGEX " + "requires five arguments."); + return false; + } + return this->FilterRegex(args, includeMatches, listName, varArgsExpanded); + } + + this->SetError("sub-command FILTER does not recognize mode " + mode); + return false; +} + +//---------------------------------------------------------------------------- +class MatchesRegex { +public: + MatchesRegex(cmsys::RegularExpression& in_regex, bool in_includeMatches) + : regex(in_regex), includeMatches(in_includeMatches) {} + + bool operator()(const std::string& target) { + return regex.find(target) ^ includeMatches; + } + +private: + cmsys::RegularExpression& regex; + const bool includeMatches; +}; + +bool cmListCommand::FilterRegex(std::vector const& args, + bool includeMatches, + std::string const& listName, + std::vector& varArgsExpanded) +{ + const std::string& pattern = args[4]; + cmsys::RegularExpression regex(pattern); + if(!regex.is_valid()) + { + std::string error = "sub-command FILTER, mode REGEX "; + error += "failed to compile regex \""; + error += pattern; + error += "\"."; + this->SetError(error); + return false; + } + + std::vector::iterator argsBegin = varArgsExpanded.begin(); + std::vector::iterator argsEnd = varArgsExpanded.end(); + std::vector::iterator newArgsEnd = + std::remove_if(argsBegin, argsEnd, MatchesRegex(regex, includeMatches)); + + std::string value = cmJoin(cmMakeRange(argsBegin, newArgsEnd), ";"); + this->Makefile->AddDefinition(listName, value.c_str()); + return true; +} diff --git a/Source/cmListCommand.h b/Source/cmListCommand.h index 5ea1d9f..25edee8 100644 --- a/Source/cmListCommand.h +++ b/Source/cmListCommand.h @@ -58,6 +58,12 @@ protected: bool HandleRemoveDuplicatesCommand(std::vector const& args); bool HandleSortCommand(std::vector const& args); bool HandleReverseCommand(std::vector const& args); + bool HandleFilterCommand(std::vector const& args); + bool FilterRegex(std::vector const& args, + bool includeMatches, + std::string const& listName, + std::vector& varArgsExpanded + ); bool GetList(std::vector& list, const std::string& var); diff --git a/Tests/RunCMake/list/EmptyFilterRegex-result.txt b/Tests/RunCMake/list/EmptyFilterRegex-result.txt new file mode 100644 index 0000000..573541a --- /dev/null +++ b/Tests/RunCMake/list/EmptyFilterRegex-result.txt @@ -0,0 +1 @@ +0 diff --git a/Tests/RunCMake/list/EmptyFilterRegex-stderr.txt b/Tests/RunCMake/list/EmptyFilterRegex-stderr.txt new file mode 100644 index 0000000..e69de29 diff --git a/Tests/RunCMake/list/EmptyFilterRegex.cmake b/Tests/RunCMake/list/EmptyFilterRegex.cmake new file mode 100644 index 0000000..33849cd --- /dev/null +++ b/Tests/RunCMake/list/EmptyFilterRegex.cmake @@ -0,0 +1,2 @@ +set(mylist "") +list(FILTER mylist INCLUDE REGEX "^FILTER_THIS_.+") diff --git a/Tests/RunCMake/list/FILTER-NotList-result.txt b/Tests/RunCMake/list/FILTER-NotList-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-NotList-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-NotList-stderr.txt b/Tests/RunCMake/list/FILTER-NotList-stderr.txt new file mode 100644 index 0000000..159c28d --- /dev/null +++ b/Tests/RunCMake/list/FILTER-NotList-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-NotList.cmake:2 \(list\): + list sub-command FILTER requires list to be present. +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-NotList.cmake b/Tests/RunCMake/list/FILTER-NotList.cmake new file mode 100644 index 0000000..1e15635 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-NotList.cmake @@ -0,0 +1,2 @@ +unset(nosuchlist) +list(FILTER nosuchlist EXCLUDE REGEX "^FILTER_THIS_.+") diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidMode-result.txt b/Tests/RunCMake/list/FILTER-REGEX-InvalidMode-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidMode-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidMode-stderr.txt b/Tests/RunCMake/list/FILTER-REGEX-InvalidMode-stderr.txt new file mode 100644 index 0000000..7f783fa --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidMode-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-REGEX-InvalidMode.cmake:2 \(list\): + list sub-command FILTER does not recognize mode NOOP +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidMode.cmake b/Tests/RunCMake/list/FILTER-REGEX-InvalidMode.cmake new file mode 100644 index 0000000..e02b929 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidMode.cmake @@ -0,0 +1,2 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +list(FILTER mylist EXCLUDE NOOP "^FILTER_THIS_.+") diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-result.txt b/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-stderr.txt b/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-stderr.txt new file mode 100644 index 0000000..94f2427 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-REGEX-InvalidOperator.cmake:2 \(list\): + list sub-command FILTER does not recognize operator RM +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator.cmake b/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator.cmake new file mode 100644 index 0000000..9624622 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidOperator.cmake @@ -0,0 +1,2 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +list(FILTER mylist RM REGEX "^FILTER_THIS_.+") diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-result.txt b/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-stderr.txt b/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-stderr.txt new file mode 100644 index 0000000..9e98cbf --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-REGEX-InvalidRegex.cmake:2 \(list\): + list sub-command FILTER, mode REGEX failed to compile regex "UHOH!\)\(". +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex.cmake b/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex.cmake new file mode 100644 index 0000000..0641062 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-InvalidRegex.cmake @@ -0,0 +1,2 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +list(FILTER mylist EXCLUDE REGEX "UHOH!)(") diff --git a/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-result.txt b/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-stderr.txt b/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-stderr.txt new file mode 100644 index 0000000..ec7f41c --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments-stderr.txt @@ -0,0 +1,4 @@ +^CMake Error at FILTER-REGEX-TooManyArguments.cmake:2 \(list\): + list sub-command FILTER, mode REGEX requires five arguments. +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\)$ diff --git a/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments.cmake b/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments.cmake new file mode 100644 index 0000000..d9cd8eb --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-TooManyArguments.cmake @@ -0,0 +1,2 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +list(FILTER mylist EXCLUDE REGEX "^FILTER_THIS_.+" one_too_many) diff --git a/Tests/RunCMake/list/FILTER-REGEX-Valid0-result.txt b/Tests/RunCMake/list/FILTER-REGEX-Valid0-result.txt new file mode 100644 index 0000000..573541a --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-Valid0-result.txt @@ -0,0 +1 @@ +0 diff --git a/Tests/RunCMake/list/FILTER-REGEX-Valid0-stderr.txt b/Tests/RunCMake/list/FILTER-REGEX-Valid0-stderr.txt new file mode 100644 index 0000000..d9ba38d --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-Valid0-stderr.txt @@ -0,0 +1,2 @@ +^mylist was: FILTER_THIS_BIT;DO_NOT_FILTER_THIS;thisisanitem;FILTER_THIS_THING +mylist is: DO_NOT_FILTER_THIS;thisisanitem$ diff --git a/Tests/RunCMake/list/FILTER-REGEX-Valid0.cmake b/Tests/RunCMake/list/FILTER-REGEX-Valid0.cmake new file mode 100644 index 0000000..f395e61 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-Valid0.cmake @@ -0,0 +1,4 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +message("mylist was: ${mylist}") +list(FILTER mylist EXCLUDE REGEX "^FILTER_THIS_.+") +message("mylist is: ${mylist}") diff --git a/Tests/RunCMake/list/FILTER-REGEX-Valid1-result.txt b/Tests/RunCMake/list/FILTER-REGEX-Valid1-result.txt new file mode 100644 index 0000000..573541a --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-Valid1-result.txt @@ -0,0 +1 @@ +0 diff --git a/Tests/RunCMake/list/FILTER-REGEX-Valid1-stderr.txt b/Tests/RunCMake/list/FILTER-REGEX-Valid1-stderr.txt new file mode 100644 index 0000000..5e5280d --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-Valid1-stderr.txt @@ -0,0 +1,2 @@ +^mylist was: FILTER_THIS_BIT;DO_NOT_FILTER_THIS;thisisanitem;FILTER_THIS_THING +mylist is: FILTER_THIS_BIT;FILTER_THIS_THING$ diff --git a/Tests/RunCMake/list/FILTER-REGEX-Valid1.cmake b/Tests/RunCMake/list/FILTER-REGEX-Valid1.cmake new file mode 100644 index 0000000..e659281 --- /dev/null +++ b/Tests/RunCMake/list/FILTER-REGEX-Valid1.cmake @@ -0,0 +1,4 @@ +set(mylist FILTER_THIS_BIT DO_NOT_FILTER_THIS thisisanitem FILTER_THIS_THING) +message("mylist was: ${mylist}") +list(FILTER mylist INCLUDE REGEX "^FILTER_THIS_.+") +message("mylist is: ${mylist}") diff --git a/Tests/RunCMake/list/RunCMakeTest.cmake b/Tests/RunCMake/list/RunCMakeTest.cmake index 25d6a03..b002ab3 100644 --- a/Tests/RunCMake/list/RunCMakeTest.cmake +++ b/Tests/RunCMake/list/RunCMakeTest.cmake @@ -1,5 +1,6 @@ include(RunCMake) +run_cmake(EmptyFilterRegex) run_cmake(EmptyGet0) run_cmake(EmptyRemoveAt0) run_cmake(EmptyInsert-1) @@ -8,17 +9,25 @@ run_cmake(NoArguments) run_cmake(InvalidSubcommand) run_cmake(GET-CMP0007-WARN) +run_cmake(FILTER-REGEX-InvalidRegex) run_cmake(GET-InvalidIndex) run_cmake(INSERT-InvalidIndex) run_cmake(REMOVE_AT-InvalidIndex) +run_cmake(FILTER-REGEX-TooManyArguments) run_cmake(LENGTH-TooManyArguments) run_cmake(REMOVE_DUPLICATES-TooManyArguments) run_cmake(REVERSE-TooManyArguments) run_cmake(SORT-TooManyArguments) +run_cmake(FILTER-NotList) run_cmake(REMOVE_AT-NotList) run_cmake(REMOVE_DUPLICATES-NotList) run_cmake(REMOVE_ITEM-NotList) run_cmake(REVERSE-NotList) run_cmake(SORT-NotList) + +run_cmake(FILTER-REGEX-InvalidMode) +run_cmake(FILTER-REGEX-InvalidOperator) +run_cmake(FILTER-REGEX-Valid0) +run_cmake(FILTER-REGEX-Valid1) -- 2.7.0 From steveire at gmail.com Thu Jan 28 16:42:09 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 28 Jan 2016 22:42:09 +0100 Subject: [cmake-developers] Review request: extract-cmMessenger branch Message-ID: <56AA8B31.2010209@gmail.com> Hi, I have pushed a extract-cmMessenger branch to my clone: https://github.com/steveire/CMake/commits/extract-cmMessenger The motivations are: * Decrease responsibilities of the cmake class. CMake uses too few classes for too many things * Make it possible to make add first-class handling of messages about missing packages (for example) to cmake-gui by making methods on cmMessenger virtual and subclassing * Make it possible to emit messages through the daemon (also by subclassing) together with backtrace and message type, relieving clients from having to parse the text. I'm interested in what you think of the approach. Thanks, Steve. From pgquiles at elpauer.org Thu Jan 28 17:25:58 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Thu, 28 Jan 2016 23:25:58 +0100 Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin wrote: > Your experience is contrary to mine. For example, in my epa_build > project (where I build all the many prerequisites of PLplot) I build a lot > of > different libraries (such as Qt5 and the GTK+ stack of libraries) using > ExternalProject_Add, and I don't experience any difficulties using > find_package to find the installed results. > > I assume find_package should work well with ExternalProject_Add for > you as well so long as (a) all your ExternalProject(s) are configured > to do both a build and install (not just a build), and (b) you are > being careful in server/CMakeLists.txt to set PATH, > CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH > consistently with the install prefix used for the ExternalProject(s). > > It works well for you because you actually have two things there: - PlPlot - A superbuild that builds the dependencies required to build PlPlot, and then, PlPlot itself by way of ExternalProject_Add (using download_command = copy the source code from some directory to another) But what I would like to do with ExternalProject_Add (and please note this is a different topic than what I started the thread for) is to avoid that superbuild: CMakeLists.txt | \--- 3rdparty | \--- server | \--- client | \--- app Where the root CMakeLists.txt is something like this: --8<--- project(myapp) # ExternalProject used here to build dependencies add_subdirectory(3rdparty) # My software is built directly, not through a superbuild add_subdirectory(server) add_subdirectory(client) add_subdirectory(app) --8<--- and 3rdparty/CMakeLists.txt would be something like this: --8<--- include(ExternalProject) # websocketpp ExternalProject_Add(websocketpp SOURCE_DIR ${CMAKE_BINARY_DIR}/websocketpp DOWNLOAD_DIR ${MYAPP_DOWNLOADS_DIR} INSTALL_DIR ${MYAPP_INSTALL_DIR} URL ${websocketpp_URL} URL_MD5 ${websocketpp_MD5} CONFIGURE_COMMAND ${CMAKE_COMMAND} -DCMAKE_INSTALL_PREFIX=${MYAPP_INSTALL_DIR} ${CMAKE_BINARY_DIR}/websocketpp LOG_DOWNLOAD 1 LOG_UPDATE 1 LOG_CONFIGURE 1 LOG_BUILD 1 LOG_TEST 1 LOG_INSTALL 1 ) # QtZeroConf ExternalProject_Add(QtZeroConf SOURCE_DIR ${CMAKE_BINARY_DIR}/QtZeroConf DOWNLOAD_DIR ${MYAPP_DOWNLOADS_DIR} INSTALL_DIR ${MYAPP_INSTALL_DIR} GIT_REPOSITORY ${QtZeroConf_URL} CONFIGURE_COMMAND ${QT_QMAKE_EXECUTABLE} PREFIX=${MYAPP_INSTALL_DIR} ${CMAKE_BINARY_DIR}/QtZeroConf LOG_DOWNLOAD 1 LOG_UPDATE 1 LOG_CONFIGURE 1 LOG_BUILD 1 LOG_TEST 1 LOG_INSTALL 1 ) --8<--- Now I should be able to do: server/CMakeLists.txt --8<--- project(server) find_package(websocketpp REQUIRED) find_package(Boost REQUIRED COMPONENTS date_time system thread) set(server_SOURCES main.cpp server.cpp) add_executable(server ${server_SOURCES}) target_link_libraries(server ${WEBSOCKETPP_LIBRARY} ${Boost_LIBRARIES}) --8<--- That would feel natural, wouldn't it? But that does not work unless I juggle with add_library(... IMPORTED) or I use Hunter or alike. In the end, neither the current behavior of add_subdirectory nor the current behavior of ExternalProject_Add let me work in the seemingly most natural way: tell CMake to build my dependencies, then immediately work on my applications/libraries :-( I would love to work on this, as Stephen suggested, but I just don't have the time :-/ -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From taylor at braun-jones.org Thu Jan 28 17:28:11 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Thu, 28 Jan 2016 17:28:11 -0500 Subject: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects In-Reply-To: <20160128203635.GA11605@megas.kitware.com> References: <56AA3F3C.7080506@kitware.com> <20160128203635.GA11605@megas.kitware.com> Message-ID: On Thu, Jan 28, 2016 at 3:36 PM, Ben Boeckel wrote: > On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote: >> That's too bad. I understand the perspective of the Ninja developers, >> but it's not clear to me what the proposed alternative should be. >> Should CMake be using the subninja[1] keyword to include the >> build.ninja of External Projects? > > That would be possible with the work that's been done here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364 Awesome. Nothing left to be said in this thread. I'll start following that one. Taylor From mantis at public.kitware.com Thu Jan 28 18:32:05 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 28 Jan 2016 18:32:05 -0500 Subject: [cmake-developers] [CMake 0015940]: There doesn't appear to be a cross-platform way to set flags to be used at compile time but not at link time Message-ID: <56249010bf75e8e149d4e4319e23dc42@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15940 ====================================================================== Reported By: Guy Harris Assigned To: ====================================================================== Project: CMake Issue ID: 15940 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-28 18:32 EST Last Modified: 2016-01-28 18:32 EST ====================================================================== Summary: There doesn't appear to be a cross-platform way to set flags to be used at compile time but not at link time Description: It appears that if a flag is added to CMAKE_C_FLAGS, it will be used not only at compile time but also at link time, at least for some platform/compiler combinations. Many such flags are, at best, not helpful at link time, and clutter the command line used for linking. Some might also not work at link time. Unix make, and autotools, keep compiler flags (CFLAGS/CXXFLAGS/etc.) and linker flags (LDFLAGS) separate. CMake should provide a way to do the same. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-28 18:32 Guy Harris New Issue ====================================================================== From irwin at beluga.phys.uvic.ca Thu Jan 28 19:01:09 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 28 Jan 2016 16:01:09 -0800 (PST) Subject: [cmake-developers] Namespaces In-Reply-To: References: Message-ID: On 2016-01-28 23:25+0100 Pau Garcia i Quiles wrote: > On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin > wrote: > > > >> Your experience is contrary to mine. For example, in my epa_build >> project (where I build all the many prerequisites of PLplot) I build a lot >> of >> different libraries (such as Qt5 and the GTK+ stack of libraries) using >> ExternalProject_Add, and I don't experience any difficulties using >> find_package to find the installed results. >> >> I assume find_package should work well with ExternalProject_Add for >> you as well so long as (a) all your ExternalProject(s) are configured >> to do both a build and install (not just a build), and (b) you are >> being careful in server/CMakeLists.txt to set PATH, >> CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH >> consistently with the install prefix used for the ExternalProject(s). >> >> > It works well for you because you actually have two things there: > > > - PlPlot > - A superbuild that builds the dependencies required to build PlPlot, > and then, PlPlot itself by way of ExternalProject_Add (using > download_command = copy the source code from some directory to another) Hi Pau: Yes, that is a good summary, although I would add that all the dependencies are handled properly. So the result is you can epa_build any library (such as PLplot) within the epa_build project and the subset of the epa_builds corresponding to its dependencies automatically occur first, but only once (unless some change is made in one of the dependent epa_builds). The dependency handling for a given project is a bit complex, but, as you might expect, the dependency logic is essentially identical for each project so I could implement it using a CMake function. So the net result is the CMakeLists.txt file for each epa_build project is quite short consisting of establishing the list of dependencies, calling the dependency-handling function, setting up ExternalProject_Add for a given project, and then calling that routine. > But what I would like to do with ExternalProject_Add (and please note this > is a different topic than what I started the thread for) is to avoid that > superbuild: You do have to build and install the external software once in any case so I suspect your motivation to avoid the "superbuild" is it keeps getting unnecessarily repeated in your case. But that should not be an issue if you deal with the dependencies correctly, see remarks above. I do take your point this is a different topic than your original one so if you want to continue this discussion, we should probably do it off list. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From michael.scott250 at gmail.com Fri Jan 29 03:37:29 2016 From: michael.scott250 at gmail.com (Michael Scott) Date: Fri, 29 Jan 2016 08:37:29 +0000 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <56AA8B31.2010209@gmail.com> References: <56AA8B31.2010209@gmail.com> Message-ID: <56AB24C9.3070809@gmail.com> > * Decrease responsibilities of the cmake class. CMake uses too few > classes for too many things I certainly agree with that, the cmake class is very large at this point. > * Make it possible to make add first-class handling of messages about > missing packages (for example) to cmake-gui by making methods on > cmMessenger virtual and subclassing This sounds like a good idea and makes a lot of sense. While working on the message functionality previously it felt like it was tacked on as an afterthought, I think moving in this direction will help lead to message functionality that can be expanded and improved upon much more easily in the future. This may be a stupid question, but I previously wondered why CMake doesn't use (or at least obviously use) a standard logging library, similar to log4j, for some of this stuff? Cheers, Michael From mantis at public.kitware.com Fri Jan 29 05:05:48 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 29 Jan 2016 05:05:48 -0500 Subject: [cmake-developers] [CMake 0015941]: file glob case sensitivity depends on platform Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15941 ====================================================================== Reported By: hegewald Assigned To: ====================================================================== Project: CMake Issue ID: 15941 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-29 05:05 EST Last Modified: 2016-01-29 05:05 EST ====================================================================== Summary: file glob case sensitivity depends on platform Description: [The OS did not fit in the above field, so here is the full version: Mac OS 10.11.3 / SUSE Linux Enterprise Server 11 (x86_64)] Cmakes file glob returns files regardless of the case used in the glob expression on Mac OS (even on a case sensitive filesystem). On Linux glob returns the files which match the case being used in the expression, as would be returned by the ls terminal command. Steps to Reproduce: Have two files where the suffix differs in case, use cmake file glob with on of the cases used in a suffix. Example: # directory src/ foo.f90 bar.F90 # ls on Mac ls src/*.F* bar.F90 # cmake on Mac file(GLOB all_sources ${src}/*.F* message(STATUS "all_sources: ${all_sources}") -- all_sources: /.../src/bar.F90;/.../src/foo.f90 # ls on Linux ls src/*.F* bar.F90 # cmake on Linus file(GLOB all_sources ${src}/*.F* message(STATUS "all_sources: ${all_sources}") -- all_sources: /.../src/bar.F90 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-29 05:05 hegewald New Issue 2016-01-29 05:05 hegewald File Added: CMakeLists.txt ====================================================================== From brad.king at kitware.com Fri Jan 29 09:49:39 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 29 Jan 2016 09:49:39 -0500 Subject: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake In-Reply-To: References: Message-ID: <56AB7C03.9020306@kitware.com> On 01/25/2016 11:01 AM, Sam Spilsbury wrote: > Over the last two years I've been working on a new unit testing > framework for CMake. I started this project because I've been writing > some other fairly complex CMake modules and I kept making mistakes > which would take me hours to debug weeks down the line. > > The project is, rather unimaginatively, called cmake-unit. The key > difference between this and the RunCMake framework that's used by > CMake internally is that cmake-unit more closely resembles an xUnit > architecture. It has support for a generic assert_that function and > matchers, test-case autodiscovery, coverage report generation and > allows you to keep all your tests together in a single file. The only > downside so far is that it runs a fair bit slower than RunCMake does. Nice. I think if something like this were to be provided by upstream CMake it would be better to implement it directly in C++, at least for the test execution and output matching parts. That would be much faster than a pure CMake language implementation and also would not need hacks to execute CMake language functions. One of the weaknesses of RunCMake infrastructure is that the CMake regex engine is not meant for large expressions. For example, the number of ()-groups is limited to 10 or so. It is also not as expressive as modern regex implementations offer. There has been discussion about replacing the regex engine previously: https://cmake.org/pipermail/cmake-developers/2011-November/014249.html but there are major compatibility challenges: https://cmake.org/pipermail/cmake-developers/2011-November/014376.html OTOH in a brand new interface we could use an alternate regex engine from the beginning. -Brad From mantis at public.kitware.com Fri Jan 29 10:34:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 29 Jan 2016 10:34:42 -0500 Subject: [cmake-developers] [CMake 0015942]: regexpr in FindMPI.cmake filtering MPI_COMPILE_FLAGS fails for Intel-flag "-fp-model" Message-ID: <04b084149dfbac1e737dfc6df92700d6@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15942 ====================================================================== Reported By: Jens Henrik Goebbert Assigned To: ====================================================================== Project: CMake Issue ID: 15942 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-29 10:34 EST Last Modified: 2016-01-29 10:34 EST ====================================================================== Summary: regexpr in FindMPI.cmake filtering MPI_COMPILE_FLAGS fails for Intel-flag "-fp-model" Description: FindMPI.cmake fails to filter the keyword required for Intel?s compile flags "-fp-model". example: icpc -O2 -xHost -ftz -fp-speculation=safe -fp-model source -Wl,-rpath-link=/usr/local/software/jureca/Stage1/software/Core/pscom/5.0.45-1/lib returns -ftz -fp-speculation=safe -fp-model instead of -ftz -fp-speculation=safe -fp-model source reason: any word not starting with -D or -f is skipped by regexpression in line 294 string(REGEX MATCHALL "(^| )-[Df]([^\" ]+|\"[^\"]+\")" MPI_ALL_COMPILE_FLAGS "${MPI_COMPILE_CMDLINE}") Steps to Reproduce: configure mpi, that mpicxx -showme:compile (for openmpi and openmpi derivatives) or mpi -compile-info (for mpich and mpich derivatives) includes the flag "-fp-model source" include find_package(MPI) and check MPI_CXX_COMPILE_FLAGS ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-29 10:34 Jens Henrik GoebbertNew Issue ====================================================================== From mantis at public.kitware.com Fri Jan 29 12:24:24 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 29 Jan 2016 12:24:24 -0500 Subject: [cmake-developers] [CMake 0015943]: CMAKE_CXX_STANDARD not working on non-apple clang++ Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15943 ====================================================================== Reported By: senz Assigned To: ====================================================================== Project: CMake Issue ID: 15943 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-01-29 12:24 EST Last Modified: 2016-01-29 12:24 EST ====================================================================== Summary: CMAKE_CXX_STANDARD not working on non-apple clang++ Description: cmake does not set standard related flags on non-apple clang++ ignoring CMAKE_CXX_STANDARD var or/and CXX_STANDARD propery. Steps to Reproduce: # brew install llvm --with-clang --with-libcxx --with-rtti # export PATH=/usr/local/opt/llvm/bin:$PATH # export CXX=/usr/local/opt/llvm/bin/clang++ # export CC=/usr/local/opt/llvm/bin/clang cmake project with set (CMAKE_CXX_STANDARD 14) set (CMAKE_CXX_STANDARD_REQUIRED ON) # make VERBOSE=1 no -std=c++14 flag ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-29 12:24 senz New Issue ====================================================================== From mantis at public.kitware.com Fri Jan 29 13:10:41 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 29 Jan 2016 13:10:41 -0500 Subject: [cmake-developers] [CMake 0015944]: Use after free in regexp functionality Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15944 ====================================================================== Reported By: hanno Assigned To: ====================================================================== Project: CMake Issue ID: 15944 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-29 13:10 EST Last Modified: 2016-01-29 13:10 EST ====================================================================== Summary: Use after free in regexp functionality Description: The attached file will cause a use after free error in cmake. This is a reduced example, I originally discovered this by using a version of cmake built with address sanitizer. This bug can also be seen by using cmake with valgrind (but the asan output is more detailed). Steps to Reproduce: 1. run "cmake ." in a directory with the attached file. cmake must either be compiled with address sanitizer or run with valgrind. Additional Information: Here's the significant part of the asan error: ==10481==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000014998 at pc 0x7f7f52711590 bp 0x7ffedc5d4690 sp 0x7ffedc5d4660 READ of size 2 at 0x603000014998 thread T0 https://public.kitware.com/Bug/view.php?id=0 0x7f7f5271158f in __interceptor_strchr (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x3458f) https://public.kitware.com/Bug/view.php?id=1 0x564b27c3891b in strchr /usr/include/string.h:226 https://public.kitware.com/Bug/view.php?id=2 0x564b27c3891b in cmsys::RegularExpression::find(char const*) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/kwsys/RegularExpression.cxx:928 https://public.kitware.com/Bug/view.php?id=3 0x564b278c9f7e in cmConditionEvaluator::HandleLevel2(std::list >&, std::string&, cmake::MessageType&) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmConditionEvaluator.cxx:608 https://public.kitware.com/Bug/view.php?id=4 0x564b278decd8 in cmConditionEvaluator::IsTrue(std::vector > const&, std::string&, cmake::MessageType&) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmConditionEvaluator.cxx:78 https://public.kitware.com/Bug/view.php?id=5 0x564b278df3a0 in cmIfCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmIfCommand.cxx:217 https://public.kitware.com/Bug/view.php?id=6 0x564b276bb068 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmMakefile.cxx:305 https://public.kitware.com/Bug/view.php?id=7 0x564b276bb7d2 in cmMakefile::ReadListFile(cmListFile const&, std::string const&) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmMakefile.cxx:611 https://public.kitware.com/Bug/view.php?id=8 0x564b276bd3a6 in cmMakefile::Configure() /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmMakefile.cxx:1663 https://public.kitware.com/Bug/view.php?id=9 0x564b27aa5ec3 in cmGlobalGenerator::Configure() /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmGlobalGenerator.cxx:1126 https://public.kitware.com/Bug/view.php?id=10 0x564b27ac9241 in cmGlobalUnixMakefileGenerator3::Configure() /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmGlobalUnixMakefileGenerator3.cxx:133 https://public.kitware.com/Bug/view.php?id=11 0x564b2779ed6b in cmake::ActualConfigure() /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmake.cxx:1422 https://public.kitware.com/Bug/view.php?id=12 0x564b277a0248 in cmake::Configure() /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmake.cxx:1205 https://public.kitware.com/Bug/view.php?id=13 0x564b277a51f7 in cmake::Run(std::vector > const&, bool) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmake.cxx:1579 https://public.kitware.com/Bug/view.php?id=14 0x564b2763f2f9 in do_cmake(int, char const* const*) /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmakemain.cxx:330 https://public.kitware.com/Bug/view.php?id=15 0x564b2763751a in main /var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmakemain.cxx:190 https://public.kitware.com/Bug/view.php?id=16 0x7f7f511b062f in __libc_start_main (/lib64/libc.so.6+0x2062f) https://public.kitware.com/Bug/view.php?id=17 0x564b2763ce78 in _start (/usr/bin/cmake+0x163e78) 0x603000014998 is located 24 bytes inside of 26-byte region [0x603000014980,0x60300001499a) freed by thread T0 here: https://public.kitware.com/Bug/view.php?id=0 0x7f7f5273561f in operator delete(void*) (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x5861f) https://public.kitware.com/Bug/view.php?id=1 0x7f7f51b08c37 in std::string::assign(std::string const&) (/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6+0xcec37) https://public.kitware.com/Bug/view.php?id=2 0x61c00000f87f (+0xf87f) https://public.kitware.com/Bug/view.php?id=3 0x7f7f51b09485 in std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6+0xcf485) previously allocated by thread T0 here: https://public.kitware.com/Bug/view.php?id=0 0x7f7f5273511f in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x5811f) https://public.kitware.com/Bug/view.php?id=1 0x7f7f51b076c8 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6+0xcd6c8) https://public.kitware.com/Bug/view.php?id=2 0x7f7f51b076c8 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6+0xcd6c8) https://public.kitware.com/Bug/view.php?id=3 0x564b28040147 in matchVariables (/usr/bin/cmake+0xb67147) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-29 13:10 hanno New Issue 2016-01-29 13:10 hanno File Added: CMakeLists.txt ====================================================================== From mantis at public.kitware.com Fri Jan 29 13:51:38 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 29 Jan 2016 13:51:38 -0500 Subject: [cmake-developers] [CMake 0015945]: "Target Platform Version" Option in Visual Sutio 2015 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15945 ====================================================================== Reported By: Gehua Yang Assigned To: ====================================================================== Project: CMake Issue ID: 15945 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-29 13:51 EST Last Modified: 2016-01-29 13:51 EST ====================================================================== Summary: "Target Platform Version" Option in Visual Sutio 2015 Description: I am trying to compile code and generate binaries that's compatible with Windows 7/8/8.1. Following MSDN's suggestion, I can set "Target Platform Version" under the General tag to use SDK 8.1, which works fine for me (see screenshot). The real problem is this change is not preserved after a CMake run. This issue is very similar to Issue https://cmake.org/Bug/view.php?id=15686 and Issue https://cmake.org/Bug/view.php?id=15670. I read through the report under both and learned that one can use CMAKE_SYSTEM_VERSION to change the "Target Platform Version" value across all projects in a VS solution. Perhaps it is not a bug and simply caused by not doing things right. But I cannot find any more documentation related to this on web. My apology in advance! However, I tried to do that with CMake 3.4.3 (latest release from cmake.org), but the projects generated does not contain this TargetPlatformVersion tag and hence its value is still defaulted to 10.0.10240.0. Steps to Reproduce: 1. In CMake GUI, set CMAKE_SYSTEM_VERSION to "8.1". Finish Cmake. 2. Open Visual Studio 2015 and open the property page of any project. 3. Go to "General" tab. Additional Information: Related to Issue https://cmake.org/Bug/view.php?id=15686 and Issue https://cmake.org/Bug/view.php?id=15670 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-29 13:51 Gehua Yang New Issue 2016-01-29 13:51 Gehua Yang File Added: t.png ====================================================================== From ewmailing at gmail.com Fri Jan 29 15:16:26 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 29 Jan 2016 12:16:26 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <569FA49B.2070005@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> <569FA49B.2070005@kitware.com> Message-ID: On 1/20/16, Brad King wrote: > On 01/20/2016 08:48 AM, Eric Wing wrote: >> I thought maybe setting the internal >> CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or >> CMAKE_${lang}_COMPILER_ID_FLAGS >> to "-version" would fix this. >> >> But this did nothing. > > Those are internal details of the CMAKE_DETERMINE_COMPILER_ID > function and are not meant to be set anywhere else. I think you > may be looking for something like this: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.4.2#l122 > > It is used by the CMAKE_DETERMINE_COMPILER_ID_VENDOR fallback when > the compiler id cannot be extracted from the basic compiler output. > More work may be needed to also extract a version number through > the CMAKE_DETERMINE_COMPILER_ID_VENDOR infrastructure. I need more guidance here. I'm not connecting the dots. My problem seems to be that the execute_process() in CMakeDetermineCompilerId.cmake is trying to invoke the command: 'swift CompilerId/main.swift' This will cause swift to run in REPL mode which won't return. It is not passing any of the flags I taught CMake to use when trying to compile a Swift program. Looking at the execute_process() that gets invoked (final one in the big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS. But there is a block at the top of the file which overwrites the variables. I was suggesting list(APPEND) instead of set() would fix that problem, and in fact look suspicious to me since there is no way to access those values passed to execute_process(). if(CMAKE_${lang}_FLAGS) #set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS}) list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS}) else() # set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}}) list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}}) endif() > > Yes. One remaining question is if there is an established convention > already out there for the name of the SWIFTFLAGS environment variable. > I haven't spotted anything so far. Remember that Xcode and anything GUI based on Mac doesn't use environmental variables. So this isn't a feature that the existing Apple community would be using. Thanks, Eric From mantis at public.kitware.com Fri Jan 29 15:56:09 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 29 Jan 2016 15:56:09 -0500 Subject: [cmake-developers] [CMake 0015946]: "xcodebuild -target foo install" should do something sensible Message-ID: <708f486c90a4ef577a0ed3e8a9e5f57e@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15946 ====================================================================== Reported By: Dan Kegel Assigned To: ====================================================================== Project: CMake Issue ID: 15946 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-29 15:56 EST Last Modified: 2016-01-29 15:56 EST ====================================================================== Summary: "xcodebuild -target foo install" should do something sensible Description: xcode users expect to be able to use the 'install' buildaction with their targets, but cmake's xcode generator makes install a target rather than a buildaction. It might make casual users happier if the xcode generator arranged for xcodebuild -target foo install to the same thing as xcodebuild -target install even if it were a bit of a kludge, as it would reduce need to RTFM in the common case. Additional Information: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/xcodebuild.1.html ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-29 15:56 Dan Kegel New Issue ====================================================================== From ewmailing at gmail.com Fri Jan 29 16:11:23 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 29 Jan 2016 13:11:23 -0800 Subject: [cmake-developers] CMake alternative language In-Reply-To: <5697C1BE.4010503@kitware.com> References: <568FE440.5090009@kitware.com> <5694165B.5040803@kitware.com> <1452691654.2609.47.camel@atmarama.com> <5697C1BE.4010503@kitware.com> Message-ID: Just to answer some of your questions on this... > > I think the first step is design brainstorming and discussion to see if > we can find something acceptable. > > IIRC one problem with earlier attempts at introducing Lua was that CMake's > dynamic scoping is difficult to reconcile with Lua's lexical scoping. Lua > cannot be given direct access to CMake variable scopes because Lua data > structures may outlive the CMake dynamic scopes, leading to dangling > references. I don't have a good solution for this. I think the original CMake/Lua bridge was basically a 1-to-1 API mapping with the CMake API. So the idea was anything you do in native Lua lives in your Lua state following the standard Lua lifecycles of things, but communicating with CMake required going through the CMake public API (via functions/macros via Lua bindings to the API). For global variables, I think there was a special Lua table for CMake globals which had a metamethod which did something similar to set the CMake values. Thus, I can't remember if there were any dangling data structures. I think about ADD_LIBRARY or ADD_EXECUTABLE which essentially returns a TARGET object which has a lifecycle. When returned to Lua, we wrap it in a userdata. The wrapper could lose its scope and the wrapper could get garbage collected. But the backend doesn't need to actually collect or destroy the object so CMake can still manage the resource itself. An aside though, I do find the scoping and lifetime rules of CMake very difficult to work with. I feel like I still don't have a good intuition or understanding of when many things happen in CMake. Since we use CMake to compile C/C++/etc which are lexical scoping, I find this to be challenging, especially since I don't really want to be focusing on details like this when I'm just trying to get my program compiled. So figuring out how to better embrace (Lua's) lexical scoping moving forward might be a win. > I'd also prefer an approach that allows us to offer newer versions of Lua > as they come out while still processing old scripts unchanged. This means > that all Lua code must lie in a context where CMake knows the version of > Lua for which it was written. I'd like to retain the possibility of > supporting multiple Lua versions to allow future such version transitions. > (Implementation symbols can be mangled to support multiple versions linked > in one program.) This should be possible, though it's not a topic I've carefully followed myself. I think simply mangling all the API functions differently should prevent any conflicts. (I don't think Lua has any global/static shared state internally which avoids those problems.) I should also point out though that if you are going to support multiple simultaneous versions of Lua, things could get messy if the user needs Lua state preserved across multiple calls (i.e. not a purely functional design). So what happens if the user starts in Lua 5.3 and creates some data, but then calls a script that only works in Lua 5.1. The VMs can't be mixed. > > cmake_lua( [LOCAL ...] CODE ...) > > The must be "5.2", the Lua language version. One thing to keep in mind is that for at least Lua 5, most of the scripting side changes have been pretty minor. Most of the time, script authors figure out how to write a script that runs across all versions of Lua 5. So specifying a list of supported versions may be desirable. > number: value is interpreted as a decimal representation of > a floating point value to be stored in a Lua number. One interesting introduction to Lua 5.3 (already out) is integer subtypes in Lua, so it now has separate float and integer types if useful. > > set(deg 90) > cmake_lua(5.2 LOCAL number{deg} CODE [[ > return { sin = math.sin(deg*math.pi) }]]) > message("sin(${deg}') = ${sin}') > So I personally imagined writing much bigger chunks in Lua directly and directly invoking CMake APIs (via bindings, sort of like the prototype). Not that I disagree with anything here. But I think for my use case, the time I need Lua the most is for complicated code that is really unwieldily in the native CMake language, not for little things. For example, one of the worst parts of CMake code I have right now in my current project is I need to track all the resource files (separated into types like images, scripts, dynamic libraries, plugins) in my project and retain the relative directory hierarchy for everything so I can reconstruct them in the application packaging/bundling process (a custom step I have as part of the build) preserving the layout (but with platform aware adjustments as needed). Basically, I wanted multi-dimensioned tables, but I don't get those in CMake, so I'm doing really painful things with global strings and appending key names to strings to make new unique string lists. It is a beast of a system right now because so many things have to use it and the key names are often done with variables there are a lot of nested variable expansions which make the code hard to read. And this data has to persist so I can set and get at different parts of the build cycle. > I'm raising the declarative approach here because it is an important > consideration. See the "CMake daemon for user tools" thread for > discussion of how a declarative spec would greatly improve integration > with IDEs and other tools: > > https://cmake.org/pipermail/cmake-developers/2016-January/027413.html > > A declarative spec allows tools to load and work with it easily. > A JSON document with a schema is easy to load, edit, validate, and > save, for example. A procedural specification must be executed to be > interpreted, and only humans can really edit it. > Yes, I agree that IDE interoperability would be great and declarative data is much nicer. I have no problem with JSON, though consider the pure Lua table too. It is basically the same thing (discovered before JSON), but if Lua is going to be the native language, then certain things become very trivial, fast, and efficient if you use Lua tables (since you can just call dostring/dofile). My historic difficulty with declarative build systems has been that they break down for things that are conceptually very simple, like your very first conditional. For example, I need to include FileA for Platforms X, Y, but FileB for Z. I remember in Ant, just trying to write the XML for this was really painful. Then the conditionals change over time and get fancier because you introduce Platform W which might need FileC+FileA or B or have some other precondition. Assuming you could have some kind of control flow, you are still ultimately explicitly writing every permutation which becomes unwieldily for other reasons (maybe Lua nested tables and references could help not make this as bad). Maybe the answer is that the user never writes the declarative parts, but CMake then generates the flattened/evaluated declarative spec. But that prevents the two-way IDE interoperability which sucks and we're back to where we started. From ewmailing at gmail.com Fri Jan 29 16:47:47 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 29 Jan 2016 13:47:47 -0800 Subject: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake In-Reply-To: <56AB7C03.9020306@kitware.com> References: <56AB7C03.9020306@kitware.com> Message-ID: On 1/29/16, Brad King wrote: > On 01/25/2016 11:01 AM, Sam Spilsbury wrote: >> Over the last two years I've been working on a new unit testing >> framework for CMake. I started this project because I've been writing >> some other fairly complex CMake modules and I kept making mistakes >> which would take me hours to debug weeks down the line. >> >> The project is, rather unimaginatively, called cmake-unit. The key >> difference between this and the RunCMake framework that's used by >> CMake internally is that cmake-unit more closely resembles an xUnit >> architecture. It has support for a generic assert_that function and >> matchers, test-case autodiscovery, coverage report generation and >> allows you to keep all your tests together in a single file. The only >> downside so far is that it runs a fair bit slower than RunCMake does. > > Nice. I think if something like this were to be provided by upstream > CMake it would be better to implement it directly in C++, at least for > the test execution and output matching parts. That would be much faster > than a pure CMake language implementation and also would not need hacks > to execute CMake language functions. > > One of the weaknesses of RunCMake infrastructure is that the CMake regex > engine is not meant for large expressions. For example, the number of > ()-groups is limited to 10 or so. It is also not as expressive as > modern regex implementations offer. There has been discussion about > replacing the regex engine previously: > > https://cmake.org/pipermail/cmake-developers/2011-November/014249.html > > but there are major compatibility challenges: > > https://cmake.org/pipermail/cmake-developers/2011-November/014376.html > > OTOH in a brand new interface we could use an alternate regex engine > from the beginning. > > -Brad > Just a random thought on the regex issue since we were talking about Lua in the other thread. Not saying this is the way to go, but something worth knowing about. Lua has a library called LPeg, which was created by the Lua authors themselves. It is basically academically rigorous rethink of the regex problem. There is a good presentation of it here: https://vimeo.com/1485123 But in a nutshell, "RegEx" (distinct for Computer Science notion of regular expressions) are a hack because they leave the domain of CS and what can be understood/proven about computability. This results in implementation dependent, unpredictable performance costs for RegEx with no mathematical grounding. And a lot of the features bolted on to RegEx have odd behaviors and limitations that can be surprising/frustrating. Lua thought about this problem not only because the lack of elegance, but also because PCRE implementations are huge...much larger than Lua itself. So they turned to old research on something called PEGs (Parseable Expression Grammars). They are akin to Context Free Grammars...drawing the analogy that CFGs are one up the computability ladder from regular expressions. This allows PEGs to capture more complicated/expressive things that RegEx has been abused to try to handle. (Some examples are in the video.) I'm by no means an LPeg expert, but I had one project where I had to do Android package name validation, which follows the rules of Java language package names. LPeg comes with a convenience layer called "re" (which might stand for regular expression...haven't thought if they mean in the 'pure' sense), which allows you to write your patterns in something that resembles BNF grammars. It was a real delight because suddenly everything was really clear and readable. (I have a Perl background so I'm very used to crazy RegEx.) Anyway, I figure one reason CMake doesn't already have a full blown PCRE engine is because of the size and complexity. (I know SWIG doesn't include PCRE for some reason and encourages you to download it separately and conditionally compiles (disabling features) based on whether you have it or not.) So this might be another be another angle to look at if a Lua effort is serious. (Timing will be a problem because I suspect the Lua thing is pretty far off. But this is another angle to consider about what we would want a Lua engine to do for CMake.) Last I checked, my built LPeg binary was under 50k. From foss at grueninger.de Fri Jan 29 17:43:59 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Fri, 29 Jan 2016 23:43:59 +0100 Subject: [cmake-developers] Patch: Remove superfluous semicolon after method Message-ID: <56ABEB2F.2000904@grueninger.de> Dear CMake devs, please find attached a minimal patch to fix a GCC 6 pedantic warning concerning a superfluous semicolon after a method. Additional I got the following warning: > CMake/Source/cmGeneratorTarget.cxx:4835:52: warning: format ?%u? expects argument of type ?unsigned int*?, but argument 3 has type ?int*? [-Wformat=] > sscanf(config_reps, "%u", &iface.Multiplicity); Same on 4840:45, 5543:51, 5548:44 in the same file. It is not obvious to me whether you want to change the types in cmOptionalLinkInterface, change the type in sscanf or cast the types. Bye Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmAlgorithms.h-remove-superfluous-semicolon-after-me.patch Type: text/x-patch Size: 734 bytes Desc: not available URL: From steveire at gmail.com Sat Jan 30 02:06:47 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 30 Jan 2016 08:06:47 +0100 Subject: [cmake-developers] CMake Daemon blog References: Message-ID: Tam?s Ken?z wrote: > That's great and really does open a new world for IDEs! Thanks! Let's see if the interest grows. I've just pushed the daemon code here: https://github.com/steveire/cmake/tree/cmake-daemon The Kate plugin should soon appear here I think: https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git Thanks, Steve. From steveire at gmail.com Sat Jan 30 06:02:11 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 30 Jan 2016 12:02:11 +0100 Subject: [cmake-developers] Namespaces References: Message-ID: Pau Garcia i Quiles wrote: > But that does not work unless I juggle with add_library(... IMPORTED) or I > use Hunter or alike. I did something like that a few months ago: https://github.com/Ableton/aqt-cassowary/blob/master/src/CMakeLists.txt However, that's not a pattern which scales I think. It requires the host to know too much about the hosted, and could stop working in the future (cmake should maybe emit an error if the LOCATION specified in an IMPORTED target does not exist). Thanks, Steve. From steveire at gmail.com Sat Jan 30 07:39:55 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 30 Jan 2016 13:39:55 +0100 Subject: [cmake-developers] Review request: extract-cmMessenger branch References: <56AA8B31.2010209@gmail.com> <56AB24C9.3070809@gmail.com> Message-ID: Michael Scott wrote: >> * Make it possible to make add first-class handling of messages about >> missing packages (for example) to cmake-gui by making methods on >> cmMessenger virtual and subclassing > > This sounds like a good idea and makes a lot of sense. > > While working on the message functionality previously it felt like it > was tacked on as an afterthought, I think moving in this direction will > help lead to message functionality that can be expanded and improved > upon much more easily in the future. Yes. Did you have a close look at the commits? I'm not really sure they are correct, and I wonder if you have any thoughts on the first one which discusses interface? > This may be a stupid question, but I previously wondered why CMake > doesn't use (or at least obviously use) a standard logging library, > similar to log4j, for some of this stuff? I don't know the answer to this. Thanks, Steve. From mikedld at mikedld.com Sat Jan 30 13:48:36 2016 From: mikedld at mikedld.com (Mike Gelfand) Date: Sat, 30 Jan 2016 21:48:36 +0300 Subject: [cmake-developers] "Inconsistent sizeofcmds" on Mac In-Reply-To: <5E4C47CE-4313-4335-A765-C2971F715CAB@mikedld.com> References: <1775000.LlafreRZIQ@stryke> <5E4C47CE-4313-4335-A765-C2971F715CAB@mikedld.com> Message-ID: <10991339-B41B-4E8E-B327-C5F5D9374612@mikedld.com> >>> Hello everyone, >>> >>> I?m using cmake 3.3.1 on Mac 10.10.4. I?m building an executable target on >>> Mac with the following settings: >>> >>> CMAKE_OSX_ARCHITECTURES = i386;x86_64 >>> CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 >>> CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk >>> >>> Right after build, executable is runnable (from inside the binary dir) and >>> everything?s fine. But once I do `make install`, the executable in the >>> install prefix starts giving out errors: >>> >>> % otool -L /install/prefix/myexecutable >>> ... >>> Inconsistent sizeofcmds >>> >>> Adding INSTALL_RPATH target property (the executable depends on a number of >>> shared libraries) results in another error during `make install`, although >>> the command isn?t failing: >>> >>> % make install >>> ... >>> -- Installing: /tmp/prefix/usr/local/rmmagent/rmmagentd >>> .../install_name_tool: for architecture x86_64 object: >>> /install/prefix/myexecutable malformed object (inconsistent sizeofcmds >>> field in mach header) ... >>> >>> What helps is either a) setting BUILD_WITH_INSTALL_RPATH target property to >>> ON (with obvious inconvenience while debugging) or b) making the executable >>> non-fat (i.e. setting architecture to either i386 or x86_64, but not both; >>> which is not what I want in the end). >>> >>> Is this a defect in cmake? Is there anything I can do to work this around? >> >> I'm not sure where the defect is, or how to work around it, without getting >> more details. >> >> I've seen problems similar to this, but not exactly the same as what you are >> seeing. What I have seen before was discussed here: >> http://public.kitware.com/pipermail/cmake/2014-October/058868.html >> >> Perhaps you can go over that and see if it applies to you. >> In that case, the bug was in install_name_tool, and there was a simple test >> case to demonstrate the bug. Apple reported that it was fixed in Xcode 6.3. > > With Clint?s help it became clear that it is a bug in install_name_tool after all. I reproduced the issue with Xcode 6.4 and 7.0, using the same commands as at link above except adding `-arch i386 -arch x86_64` to gcc command line. Bug reported to Apple and awaits their reply. FYI, Apple replied a couple days ago and I could confirm that the issue is now fixed in Xcode 7.3 beta (7D129n). Thanks again for your help Clint. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mantis at public.kitware.com Sat Jan 30 14:43:09 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 30 Jan 2016 14:43:09 -0500 Subject: [cmake-developers] [CMake 0015947]: CodeBlocks project with full paths Message-ID: <86813d47e79d7986999cbff28c8f07ac@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15947 ====================================================================== Reported By: Tyler Ryan Assigned To: ====================================================================== Project: CMake Issue ID: 15947 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-30 14:43 EST Last Modified: 2016-01-30 14:43 EST ====================================================================== Summary: CodeBlocks project with full paths Description: Generating a CodeBlocks project results in absolute paths (from /) in the source tree rather than relative paths. Steps to Reproduce: Run cmake-gui and select "CodeBlocks - Unix Makefiles" generator. The resulting project will have absolute paths. Additional Information: This appears to be the same as 0012110 (https://cmake.org/Bug/view.php?id=12110) which was closed in 2.8.6. Saving the generated project (via CodeBlocks interface) resets the paths to relative, but that breaks next time cmake has to generate the project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-30 14:43 Tyler Ryan New Issue ====================================================================== From mantis at public.kitware.com Sat Jan 30 15:21:46 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 30 Jan 2016 15:21:46 -0500 Subject: [cmake-developers] [CMake 0015948]: CMake GUI crashes generating FLTK 1.3.3 project files on Windows 10 Message-ID: <90ed00fe016ebc786c96dcfaee79de5b@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15948 ====================================================================== Reported By: Brian Raderman Assigned To: ====================================================================== Project: CMake Issue ID: 15948 Category: CMake Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-30 15:21 EST Last Modified: 2016-01-30 15:21 EST ====================================================================== Summary: CMake GUI crashes generating FLTK 1.3.3 project files on Windows 10 Description: CMake GUI crashes with "CMake Internal Error: Missing cmGeneratorTarget Instance!" on Windows 10. This happens when trying to generate 32 bit and 64 bit project files for Visual Studio 2015. The crash happens towards the end of the first configure operation. Steps to Reproduce: Download latest FLTK stable sources (1.3.3) from www.fltk.org. Use latest CMake to configure a build on Windows 10 (it might happen on earlier versions as well, but I am unable to test this) for 32-bit or 64-bit Visual Studio 2015. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-30 15:21 Brian Raderman New Issue ====================================================================== From mantis at public.kitware.com Sat Jan 30 17:25:04 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 30 Jan 2016 17:25:04 -0500 Subject: [cmake-developers] [CMake 0015949]: CMake 3.4.3 installer bug Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15949 ====================================================================== Reported By: Srikanth Anantharam Assigned To: ====================================================================== Project: CMake Issue ID: 15949 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-01-30 17:25 EST Last Modified: 2016-01-30 17:25 EST ====================================================================== Summary: CMake 3.4.3 installer bug Description: CMake 3.4.3 does not prompt to uninstall an already installed version and instead overwrites. Steps to Reproduce: 1. Install CMake version<3.4.3 2. Install CMake 3.4.3 Additional Information: Start Menu displays entry both the versions but only 3.4.3 works Solution: (Prompt for) Uninstall of a previously installed version of CMake. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-01-30 17:25 Srikanth AnantharamNew Issue ====================================================================== From gjasny at googlemail.com Sat Jan 30 17:30:59 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 30 Jan 2016 23:30:59 +0100 Subject: [cmake-developers] [PATCH] Proposed fix for bug 15183 In-Reply-To: References: Message-ID: <56AD39A3.3050906@googlemail.com> Hello, On 13/01/16 12:13, Marko Kylm?maa wrote: > I would like to propose the following fix for bug 15183 ( > https://cmake.org/Bug/view.php?id=15183) > > For some reason the XcodeGenerator seemed to be setting the INSTALL_PATH > variable regardless of if it was initialized or not (which is done only for > shared libraries). This seems almost certainly undesirable so I've moved > the code inside the shared library check. Thank you for the patch. It improves the situation but does not fix it completely. Nevertheless I will push it to -next as soon as unit test are green locally. The case where it does not work is the following: > cmake_minimum_required(VERSION 3.4 FATAL_ERROR) > > add_library(mystatic STATIC main.c) > add_library(myshared SHARED main.c) The myshared library has "@rpath" in the install dir attribute. I guess the MACOSX_RPATH target property interferes here. I will have a look at this but certainly the second part of the fix will miss the CMake 3.5 freeze. Thanks, Gregor From ewmailing at gmail.com Sun Jan 31 18:09:28 2016 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 31 Jan 2016 15:09:28 -0800 Subject: [cmake-developers] Is there a way to disable soname versioning? Message-ID: This has been an ongoing nuisance for me, so I thought I would finally ask. Is there a way I can force soname versioning without modifying everybody's CMake build scripts? The main problem is Android. Using soname versioning on Android will basically cause things to break at runtime. It would be nice if the CMake commands that set the version would be ignored in the Android case. (I know Android is not officially supported by CMake and cross-compile toolchains are being used, but if I knew how to put this in the toolchain, that would be a big help.) My secondary problem is I am trying to ship self-contained binary apps on Linux. This means I ship my own copies of libraries. The soname versioning in this case just gets in the way (the build and packaging scripts get harder since file names are variable). I would love a way to just globally tell CMake to not apply versioning as some top-level option. (My complaints probably extend to Darwin versioning too, though it hasn't come up as often for me.) Thanks, Eric