[cmake-developers] Automoc same source name fix (proposal)
Hi, I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir subdirectory. For the attached test case you end up with foo_automoc.cpp -- As before but includes sources below foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/item.cpp This solves the same output moc problem. What remains though is that including "moc_foo.cpp" does not work because of missing INCLUDE_DIRECTORIES. Kind regards, Sebastian Holtermann >From cf51dcf0af4744fbb40e3bb5ad253d2514325148 Mon Sep 17 00:00:00 2001 From: Sebastian Holtermann Date: Tue, 12 Apr 2016 10:47:49 +0200 Subject: [PATCH] Automoc: Create moc files below foo_automoc.dir with respect to the source header project relative path --- Source/cmQtAutoGenerators.cxx | 90 --- Source/cmQtAutoGenerators.h | 3 ++ 2 files changed, 80 insertions(+), 13 deletions(-) diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx index ebe08b0..69b1e3d 100644 --- a/Source/cmQtAutoGenerators.cxx +++ b/Source/cmQtAutoGenerators.cxx @@ -414,6 +414,9 @@ void cmQtAutoGenerators::Init() this->OutMocCppFilename += this->TargetName; this->OutMocCppFilename += ".cpp"; + this->OutMocDirname += this->TargetName; + this->OutMocDirname += ".dir"; + std::vector cdefList; cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList); for(std::vector::const_iterator it = cdefList.begin(); @@ -637,7 +640,7 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile) { automocCppChanged = true; } - outStream << "#include \"" << it->second << "\"\n"; + outStream << "#include \"" << MocPathBuildRel ( it->second ) << "\"\n"; } } @@ -749,7 +752,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename, if (!headerToMoc.empty()) { - includedMocs[headerToMoc] = currentMoc; + includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc ); if (basename == scannedFileBasename) { mocUnderscoreIncluded = true; @@ -826,7 +829,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename, dotMocIncluded = true; ownDotMocFile = currentMoc; } -includedMocs[fileToMoc] = currentMoc; +includedMocs[fileToMoc] = MocPathIncluderRel ( absFilename, currentMoc ); } matchOffset += mocIncludeRegExp.end(); } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset)); @@ -851,7 +854,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename, << scannedFileBasename << ".moc\" for compatibility with " "strict mode (see CMAKE_AUTOMOC_RELAXED_MODE).\n" << std::endl; - includedMocs[absFilename] = ownMocUnderscoreFile; + includedMocs[absFilename] = MocPathIncluderRel ( absFilename, ownMocUnderscoreFile ); includedMocs.erase(ownMocHeaderFile); } else @@ -930,7 +933,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename, if (!headerToMoc.empty()) { - includedMocs[headerToMoc] = currentMoc; + includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc ); } else { @@ -964,7 +967,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename, ::exit(EXIT_FAILURE); } dotMocIncluded = true; -includedMocs[absFilename] = currentMoc; +includedMocs[absFilename] = MocPathIncluderRel ( absFilename, currentMoc ); } matchOffset += mocIncludeRegExp.end(); } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset)); @@ -1104,15 +1107,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders, std::cout << "AUTOGEN: Checking " << headerName << std::endl; } - const std::string basename = cmsys::SystemTools:: - GetFilenameWithoutLastExtension(headerName); - - const std::string currentMoc = "moc_" + basename + ".cpp"; std::string macroName; if (requiresMocing(contents, macroName)) { //std::cout << "header contains Q_OBJECT macro"; -notIncludedMocs[headerName] = currentMoc; +const std::string basename = cmsys::SystemTools:: + GetFilenameWithoutLastExtension(headerName); +const std::string currentMoc = "moc_" + basename + ".cpp"; +notIncludedMocs[headerName] = MocPathIncluderRel ( headerName, currentMoc ); } } this->ParseForUic(headerName, contents, includedUis); @@ -1122,7 +1124,11 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& a
Re: [cmake-developers] Automoc same source name fix (proposal)
Am 12.04.2016 um 11:57 schrieb Sebastian Holtermann: Oops, moc_item.cpp it is. For the attached test case you end up with foo_automoc.cpp -- As before but includes sources below foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/moc_item.cpp -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc same source name fix (proposal)
Sorry for the noise. I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir subdirectory. Here is an improved patch that calculates header relative paths in the following parent directory lookup order - CMAKE_CURRENT_SOURCE_DIR - CMAKE_CURRENT_BINARY_DIR - CMAKE_SOURCE_DIR - CMAKE_BINARY_DIR Also std::cout debugging was removed ;) Kind regards, Sebastian Holtermann >From 7d8191f70232a89453be127f64603970a08c96d8 Mon Sep 17 00:00:00 2001 From: Sebastian Holtermann Date: Tue, 12 Apr 2016 13:33:21 +0200 Subject: [PATCH] Automoc: Create moc files below foo_automoc.dir with respect to the source header project relative path --- Source/cmQtAutoGenerators.cxx | 102 -- Source/cmQtAutoGenerators.h | 3 ++ 2 files changed, 92 insertions(+), 13 deletions(-) diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx index ebe08b0..1c02411 100644 --- a/Source/cmQtAutoGenerators.cxx +++ b/Source/cmQtAutoGenerators.cxx @@ -414,6 +414,9 @@ void cmQtAutoGenerators::Init() this->OutMocCppFilename += this->TargetName; this->OutMocCppFilename += ".cpp"; + this->OutMocDirname += this->TargetName; + this->OutMocDirname += ".dir"; + std::vector cdefList; cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList); for(std::vector::const_iterator it = cdefList.begin(); @@ -637,7 +640,7 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile) { automocCppChanged = true; } - outStream << "#include \"" << it->second << "\"\n"; + outStream << "#include \"" << MocPathBuildRel ( it->second ) << "\"\n"; } } @@ -749,7 +752,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename, if (!headerToMoc.empty()) { - includedMocs[headerToMoc] = currentMoc; + includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc ); if (basename == scannedFileBasename) { mocUnderscoreIncluded = true; @@ -826,7 +829,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename, dotMocIncluded = true; ownDotMocFile = currentMoc; } -includedMocs[fileToMoc] = currentMoc; +includedMocs[fileToMoc] = MocPathIncluderRel ( absFilename, currentMoc ); } matchOffset += mocIncludeRegExp.end(); } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset)); @@ -851,7 +854,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename, << scannedFileBasename << ".moc\" for compatibility with " "strict mode (see CMAKE_AUTOMOC_RELAXED_MODE).\n" << std::endl; - includedMocs[absFilename] = ownMocUnderscoreFile; + includedMocs[absFilename] = MocPathIncluderRel ( absFilename, ownMocUnderscoreFile ); includedMocs.erase(ownMocHeaderFile); } else @@ -930,7 +933,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename, if (!headerToMoc.empty()) { - includedMocs[headerToMoc] = currentMoc; + includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc ); } else { @@ -964,7 +967,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename, ::exit(EXIT_FAILURE); } dotMocIncluded = true; -includedMocs[absFilename] = currentMoc; +includedMocs[absFilename] = MocPathIncluderRel ( absFilename, currentMoc ); } matchOffset += mocIncludeRegExp.end(); } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset)); @@ -1104,15 +1107,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders, std::cout << "AUTOGEN: Checking " << headerName << std::endl; } - const std::string basename = cmsys::SystemTools:: - GetFilenameWithoutLastExtension(headerName); - - const std::string currentMoc = "moc_" + basename + ".cpp"; std::string macroName; if (requiresMocing(contents, macroName)) { //std::cout << "header contains Q_OBJECT macro"; -notIncludedMocs[headerName] = currentMoc; +const std::string basename = cmsys::SystemTools:: + GetFilenameWithoutLastExtension(headerName); +const std::string currentMoc = "moc_" + basename + ".cpp"; +notIncludedMocs[headerName] = MocPathIncluderRel ( headerName, currentMoc ); } } this->ParseForUic(headerName, contents, includedUis); @@ -1122,7 +1124,10 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders, bool cmQtAutoGenerators::GenerateMoc(const std::string& sourceF
Re: [cmake-developers] Automoc same source - More thoughts
Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann: Sorry for the noise. I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir subdirectory. I had some more thoughts about this. CMAKE_CURRENT_BINARY_DIR / foo_automoc.cpp foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/moc_item.cpp With directory based moc file generation it is complicated to allow "#include " (I've never included mocs btw.). Putting every moc directory into the target INCLUDE_DIRECTORIES won't help because then there would be multiple moc_item.cpp files that match "include ". If per source INCLUDE_DIRECTORIES were possible it might work though. My proposal is this: - Moc files that are "#include<>"d get generated in CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with name collision test. - Moc files not included but detected from headers get generated in CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/ with subdirectory support. Since they're not included it doesn't matter where they are as long as they don't overwrite each other. I'll prepare another patch for this... Kind regards, Sebastian -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=16059 == Reported By:Antonio Assigned To: == Project:CMake Issue ID: 16059 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2016-04-12 12:00 EDT Last Modified: 2016-04-12 12:00 EDT == Summary:It is not possible to specify a linker different from the compiler to link a shared library Description: In some situations, it might be convenient to specify a different linker than the compiler. For example, for llvm combined with mingw, compiling with clang and linking with gcc would work. The workaround proposed here https://cmake.org/pipermail/cmake/2014-August/058268.html does not seem to work. Steps to Reproduce: Requires 2 compilers to be there. In the attached project, Configuring with D:\dummyProj\build> cmake ..\src -G "Eclipse CDT4 - Ninja" -DCMAKE_TOOLCHAIN_FILE=..\src\Toolchain-LLVM.cmake -DCMAKE_LINKER=C:/Programs/mingw32_493_posix_dwarf/bin/g++.exe -DCMAKE_CXX_LINK_EXECUTABLE=" -o " -DCMAKE_CXX_CREATE_SHARED_LIBRARY=" -o " Building will anyway lead to the following commands to be generated: [1/2] C:\Programs\LLVM\bin\clang++.exe -Ddummy_EXPORTS -MMD -MT CMakeFiles/dummy.dir/dummy.cpp.obj -MF CMakeFiles/dummy.dir/dummy.cpp.obj.d -o CMakeFiles/dummy.dir/dummy.cpp.obj -c D:/dummyProj/src/dummy.cpp [2/2] cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe -shared -o libdummy.dll -Wl,--out-implib,libdummy.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles/dummy.dir/dummy.cpp.obj -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." FAILED: cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe -shared -o libdummy.dll -Wl,--out-implib,libdummy.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles/dummy.dir/dummy.cpp.obj -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." C:\Programs\mingw32_493_posix_dwarf\i686-w64-mingw32\lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x1d6): undefined reference to `__chkstk_ms' clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. The first command is correct, the second doesn't use g++ to link as desired. Linking succeeds if g++ is replaced in the command line. == Issue History Date ModifiedUsername FieldChange == 2016-04-12 12:00 AntonioNew Issue 2016-04-12 12:00 AntonioFile Added: dummyProj.zip == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake API for warnings
Hi Ruslo, Sorry for taking so long to respond here. I've been hoping to find time to think through the design deeply but I don't know when that may happen. Here is some more feedback. I invite others to jump in here. Without more interest I'm hesitant to proceed. On 04/05/2016 02:03 PM, Ruslan Baratov wrote: > Report an error in case of any type of conflicts. Yes. > new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this. I'd prefer to avoid extra knobs if possible. > You mean this: > > compatibility-c++98=off > inline=off > special-members=off > catch-semantic-changed=off > covered-switch-default=off > inherits-via-dominance=off > name-length-exceeded=off > padded=off > this-used-in-init=off > EVERYTHING=on > EVERYTHING=error > > versus this one: > > DISABLE >compatibility-c++98 >inline >special-members >catch-semantic-changed >covered-switch-default >inherits-via-dominance >name-length-exceeded >padded >this-used-in-init > ENABLE >EVERYTHING > TREAT_AS_ERROR >EVERYTHING Consider examples where we don't have the full list ahead of time and are instead appending. Or, what if we want to check the current property value to see if some setting is already present? Compilers use flags like -Wxyz -Wno-abc -Whjk=error and not -WDISABLE $w1 $w2 -WENABLE $w3 $w4 so IMO the individual values are easier to reason about. Also one could imagine having the value come from a generator expression, e.g. foo=$ >> I'd like to find another name that captures the idea of enabling most >> warnings. > > Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET? I don't think "everything" or "all" has a meaningful implementation available on all compilers. I was actually saying the opposite. We should not try to provide such an abstraction and instead have one called "most" or "high" or something like that. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS
I have the following CMake code: get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER ) set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) if( BUILD_TESTING ) set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) endif() However this fails stating those targets do not exist. Is there a way I can make this work? I'd like to organize these CMake targets in my own way in the Visual Studio solution. There have been topics regarding this on the mailing list in the past, but they have gone unanswered. Specifically, why are these targets treated as if they do not exist? Does CMake only allow you to set properties on targets created directly by the scripts themselves (i.e. no built-in targets can be affected)? I'm happy to contribute a patch to this if needed. Thanks in advance. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS
On 04/12/2016 02:54 PM, Robert Dailey wrote: > set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) > > if( BUILD_TESTING ) > set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) > endif() > > However this fails stating those targets do not exist. They don't exist because they are not created until generate-time. FYI recent changes in 'master' move ALL_BUILD into the predefined targets folder. > Does CMake only allow you to set properties on targets created > directly by the scripts themselves (i.e. no built-in targets can be > affected)? Correct. See above. This is not trivial to change because the ALL_BUILD, INSTALL, etc. targets are not normal targets. Internally they have type GLOBAL_TARGET. There can be *multiple* such targets of the same name created by the generators. Each directory whose CMakeLists.txt file calls project(SomeName) gets a SomeName.sln in VS, for example. Each such .sln has a different ALL_BUILD target with its own dependencies. The generators can get away with this because nothing ever looks up these targets by name. Therefore trying to present such targets to CMake project code is not well-defined. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc same source - More thoughts
Am 12.04.2016 um 17:40 schrieb Sebastian Holtermann: Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann: Sorry for the noise. I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir subdirectory. I had some more thoughts about this. CMAKE_CURRENT_BINARY_DIR / foo_automoc.cpp foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/moc_item.cpp With directory based moc file generation it is complicated to allow "#include " (I've never included mocs btw.). Putting every moc directory into the target INCLUDE_DIRECTORIES won't help because then there would be multiple moc_item.cpp files that match "include ". If per source INCLUDE_DIRECTORIES were possible it might work though. My proposal is this: - Moc files that are "#include<>"d get generated in CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with name collision test. - Moc files not included but detected from headers get generated in CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/ with subdirectory support. Since they're not included it doesn't matter where they are as long as they don't overwrite each other. I'll prepare another patch for this... Here it is. Please review/commit. To test it insert #include "moc_item.cpp" in any or many of the item.cpp files of the attached test project. Kind regards, Sebastian Holtermann >From cbc41b51685a4a35ceaa0763ba3f14e1ae425ad4 Mon Sep 17 00:00:00 2001 From: Sebastian Holtermann Date: Tue, 12 Apr 2016 20:49:50 +0200 Subject: [PATCH] Automoc generates non included mocs in dedicated directory with source directory tree reflection --- Source/cmQtAutoGenerators.cxx | 107 +++--- Source/cmQtAutoGenerators.h | 4 ++ 2 files changed, 104 insertions(+), 7 deletions(-) diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx index ebe08b0..1faab2d 100644 --- a/Source/cmQtAutoGenerators.cxx +++ b/Source/cmQtAutoGenerators.cxx @@ -93,8 +93,19 @@ static std::string extractSubDir(const std::string& absPath, std::string subDir; if (currentMoc.find_first_of('/') != std::string::npos) { -subDir = absPath - + cmsys::SystemTools::GetFilenamePath(currentMoc) + '/'; +std::string fileNamePath = cmsys::SystemTools::GetFilenamePath(currentMoc); +if ( fileNamePath.find ( ".." ) == std::string::npos ) + { +subDir = absPath + fileNamePath + '/'; + } +else + { + // We can't handle parent directories + std::cerr << "AUTOGEN: error: moc include \"" << currentMoc +<< "\" contains parent directory reference \"..\"" +<< std::endl; + ::exit(EXIT_FAILURE); + } } return subDir; } @@ -414,6 +425,9 @@ void cmQtAutoGenerators::Init() this->OutMocCppFilename += this->TargetName; this->OutMocCppFilename += ".cpp"; + this->OutMocDirname += this->TargetName; + this->OutMocDirname += ".dir"; + std::vector cdefList; cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList); for(std::vector::const_iterator it = cdefList.begin(); @@ -589,6 +603,26 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile) std::map notIncludedMocs; this->ParseHeaders(headerFiles, includedMocs, notIncludedMocs, includedUis); + // Check: Look for name collisions +{ +typedef std::map::const_iterator Iter; +for ( Iter ita = includedMocs.begin(); ita != includedMocs.end(); ++ita ) + { + Iter itb = ita; + ++itb; + for ( ; itb != includedMocs.end(); ++itb ) +{ +if ( ita->second == itb->second ) + { + std::cerr << "AUTOGEN: error: moc name collision" << std::endl +<< ita->first << " -> " << ita->second << std::endl +<< itb->first << " -> " << itb->second << std::endl; + ::exit(EXIT_FAILURE); + } +} + } +} + // run moc on all the moc's that are #included in source files for(std::map::const_iterator it = includedMocs.begin(); @@ -1104,15 +1138,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders, std::cout << "AUTOGEN: Checking " << headerName << std::endl; } - const std::string basename = cmsys::SystemTools:: - GetFilenameWithoutLastExtension(headerName); - - const std::string currentMoc = "moc_" + basename + ".cpp"; std::string macroName; if (requiresMocing(contents, macroName)) { //std::cout << "header contains Q_OBJECT macro"; -notIncludedMocs[headerName] = currentMoc; +const std::string basename = cmsys::SystemTools:: + GetFilenameWithoutLastExtension(headerName); +cons
Re: [cmake-developers] Automoc same source - More thoughts
On 04/12/2016 03:12 PM, Sebastian Holtermann wrote: > Here it is. Please review/commit. > > To test it insert #include "moc_item.cpp" in any or many > of the item.cpp files of the attached test project. Thanks for working on this! As requested in the issue tracker entry you linked, in this comment: https://cmake.org/Bug/view.php?id=12873#c40513 please extend the CMake test suite with a case covering this. We need to test both the conflicting source name use case and the #include "moc_..." use case. Please revise the patch to include such tests. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0016060]: Chrome warns cmake installer is harmful program
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=16060 == Reported By:raysatiro Assigned To: == Project:CMake Issue ID: 16060 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2016-04-12 17:52 EDT Last Modified: 2016-04-12 17:52 EDT == Summary:Chrome warns cmake installer is harmful program Description: Using Chrome Version 49.0.2623.112 m I'm trying to download the cmake installer: "The site ahead contains harmful programs Attackers on cmake.org might attempt to trick you into installing programs that harm your browsing experience (for example, by changing your homepage or showing extra ads on sites you visit)." Steps to Reproduce: https://cmake.org/download/ and click on cmake-3.5.1-win32-x86.msi Additional Information: https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html?hl=en-US#url=https://cmake.org/files/v3.5/cmake-3.5.1-win32-x86.msi == Issue History Date ModifiedUsername FieldChange == 2016-04-12 17:52 raysatiro New Issue 2016-04-12 17:52 raysatiro File Added: cmake chrome says harmful programs.PNG == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake API for warnings
On 13-Apr-16 01:00, Brad King wrote: Hi Ruslo, Sorry for taking so long to respond here. I've been hoping to find time to think through the design deeply but I don't know when that may happen. Here is some more feedback. I invite others to jump in here. Without more interest I'm hesitant to proceed. On 04/05/2016 02:03 PM, Ruslan Baratov wrote: Report an error in case of any type of conflicts. Yes. new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this. I'd prefer to avoid extra knobs if possible. Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev) You mean this: compatibility-c++98=off inline=off special-members=off catch-semantic-changed=off covered-switch-default=off inherits-via-dominance=off name-length-exceeded=off padded=off this-used-in-init=off EVERYTHING=on EVERYTHING=error versus this one: DISABLE compatibility-c++98 inline special-members catch-semantic-changed covered-switch-default inherits-via-dominance name-length-exceeded padded this-used-in-init ENABLE EVERYTHING TREAT_AS_ERROR EVERYTHING Consider examples where we don't have the full list ahead of time and are instead appending. - Or, what if we want to check the current property value to see if some setting is already present? What do you mean? Compilers use flags like -Wxyz -Wno-abc -Whjk=error and not -WDISABLE $w1 $w2 -WENABLE $w3 $w4 I don't think the reason of approach used in compilers is about been convenient for user to analyze command line flags. CMake can do much better job here. All I'm trying to say about ENABLE/DISABLE lists is that if user will have N warnings to enable and M warnings to disable he will not write N times *=on and M times *=off and probably will just create helper functions: function(enable_warnings_list ...) foreach(warning ...) list(APPEND result ${warning}=on) endforeach() endif() So instead of writing extra different modules by a lot of developers why not support this from the box? so IMO the individual values are easier to reason about. Also one could imagine having the value come from a generator expression, e.g. foo=$ As far as I understand we should allow on/off/error, so effectively it will be: foo=$<$:off>$<$>:error> so how about this: compile_warnings(DISABLE foo CONFIGURATION Debug) compile_warnings(ERROR foo CONFIGURATION NOT Debug) ? I'd like to find another name that captures the idea of enabling most warnings. Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET? I don't think "everything" or "all" has a meaningful implementation available on all compilers. I was actually saying the opposite. We should not try to provide such an abstraction and instead have one called "most" or "high" or something like that. I'm pretty sure all compilers have flag to enable all kind of available warnings (it may not call "All", e.g. -Weverything for Clang). Even if there is such compiler we can use maximum level + adding extra warnings explicitly. There must be abstracted group that allow to enable everything. Also I think that LEVEL/MOST/ALL groups doesn't make a lot of practical sense since every compiler have different kind of warnings enabled by such groups, so it's not cross-platformic friendly. Ruslo -- 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