From seblist at xwmw.org Thu Sep 1 07:22:49 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 1 Sep 2016 13:22:49 +0200 Subject: [cmake-developers] QtAutogen: Use Base32 instead of Base64 for file names In-Reply-To: References: Message-ID: Am 30.08.2016 um 16:53 schrieb Brad King: > On 08/28/2016 10:00 AM, Sebastian Holtermann wrote: >> Base32 is a better choice IMO because it is single case and does not >> generate disruptive characters like '_', '-' or '/'. >> >> Here are two patches that replace Base64 with Base32. > > Thanks. Please revise the Base32 infrastructure to simply be > in CMake instead of KWSys. > The patches. -Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_3-6-1_autogen_patches_base32_v002.tar.gz Type: application/gzip Size: 2739 bytes Desc: not available URL: From brad.king at kitware.com Thu Sep 1 10:58:47 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 1 Sep 2016 10:58:47 -0400 Subject: [cmake-developers] QtAutogen: Use Base32 instead of Base64 for file names In-Reply-To: References: Message-ID: <9b6de89d-a30b-d524-bdfe-0c999f7b875e@kitware.com> On 09/01/2016 07:22 AM, Sebastian Holtermann wrote: > The patches. Thanks, applied with minor tweaks: Add cmBase32Encoder class https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67dba415 cmFilePathUuid: Use Base32 string instead of Base64 string https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46de2f5b -Brad From steve.lorimer at gmail.com Thu Sep 1 19:32:45 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Fri, 2 Sep 2016 09:32:45 +1000 Subject: [cmake-developers] Feature request: file globbing in ADDITIONAL_MAKE_CLEAN_FILES Message-ID: As part of our build process we tag certain binary files with version information such as git branch, number of commits, build variant etc. Eg, for a binary called "app" we could install a file in the local source directory with the name "app.branch_foo.91.debug" The shell globbing pattern that matches is "app.*[0-9]*" I need a globbing pattern because the tag can change without the makefiles changing, so the tag can't be hardcoded into the makefile. If I specify a globbing pattern for ADDITIONAL_MAKE_CLEAN_FILES it specifies this as an actual file set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES app.*[0-9]*) This results in file(REMOVE_RECURSE "../../../app/app.*[0-9]*" ... ) That doesn't work, because it's not a real file, it's a globbing pattern I've tried adding a nested file(GLOB ...) into the set_directory_properties but that doesn't work either. Is this a feature worthy of addition? - the ability to specify a globbing pattern in set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ...)? - the ability to specify a globbing pattern in file(REMOVE_RECURSE ...)? TIA Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Fri Sep 2 03:13:41 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 2 Sep 2016 07:13:41 +0000 Subject: [cmake-developers] Feature request: file globbing in ADDITIONAL_MAKE_CLEAN_FILES In-Reply-To: References: Message-ID: A more generic approach for cleanup actions is to add a new property which enables to specify a cmake script. And, in the script, everyone is free to do what he wants? Example: set_directory_properties (PROPERTIES ADDITIONAL_MAKE_CLEAN_SCRIPT "my_clean_script.cmake") From: cmake-developers on behalf of Steve Lorimer Date: Friday 2 September 2016 at 01:32 To: "cmake-developers at cmake.org" Subject: [cmake-developers] Feature request: file globbing in ADDITIONAL_MAKE_CLEAN_FILES As part of our build process we tag certain binary files with version information such as git branch, number of commits, build variant etc. Eg, for a binary called "app" we could install a file in the local source directory with the name "app.branch_foo.91.debug" The shell globbing pattern that matches is "app.*[0-9]*" I need a globbing pattern because the tag can change without the makefiles changing, so the tag can't be hardcoded into the makefile. If I specify a globbing pattern for ADDITIONAL_MAKE_CLEAN_FILES it specifies this as an actual file set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES app.*[0-9]*) This results in file(REMOVE_RECURSE "../../../app/app.*[0-9]*" ... ) That doesn't work, because it's not a real file, it's a globbing pattern I've tried adding a nested file(GLOB ...) into the set_directory_properties but that doesn't work either. Is this a feature worthy of addition? - the ability to specify a globbing pattern in set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ...)? - the ability to specify a globbing pattern in file(REMOVE_RECURSE ...)? TIA Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lorimer at gmail.com Sun Sep 4 03:06:15 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Sun, 4 Sep 2016 17:06:15 +1000 Subject: [cmake-developers] Feature request: file globbing in ADDITIONAL_MAKE_CLEAN_FILES In-Reply-To: References: Message-ID: Thanks Marc, I'll try that out! On 2 September 2016 at 17:13, CHEVRIER, Marc wrote: > A more generic approach for cleanup actions is to add a new property which > enables to specify a cmake script. And, in the script, everyone is free to > do what he wants? > > Example: set_directory_properties (PROPERTIES ADDITIONAL_MAKE_CLEAN_SCRIPT > "my_clean_script.cmake") > > > > *From: *cmake-developers on behalf > of Steve Lorimer > *Date: *Friday 2 September 2016 at 01:32 > *To: *"cmake-developers at cmake.org" > *Subject: *[cmake-developers] Feature request: file globbing in > ADDITIONAL_MAKE_CLEAN_FILES > > > > As part of our build process we tag certain binary files with version > information such as git branch, number of commits, build variant etc. > > > > Eg, for a binary called "app" we could install a file in the local source > directory with the name "app.branch_foo.91.debug" > > > > The shell globbing pattern that matches is "app.*[0-9]*" > > > > I need a globbing pattern because the tag can change without the makefiles > changing, so the tag can't be hardcoded into the makefile. > > > > If I specify a globbing pattern for ADDITIONAL_MAKE_CLEAN_FILES it > specifies this as an actual file > > > > set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES > app.*[0-9]*) > > > > This results in > > > > file(REMOVE_RECURSE > > "../../../app/app.*[0-9]*" > > ... > > ) > > > > That doesn't work, because it's not a real file, it's a globbing pattern > > > > I've tried adding a nested file(GLOB ...) into the > set_directory_properties but that doesn't work either. > > > > Is this a feature worthy of addition? > > > > - the ability to specify a globbing pattern in set_directory_properties(PROPERTIES > ADDITIONAL_MAKE_CLEAN_FILES ...)? > > - the ability to specify a globbing pattern in file(REMOVE_RECURSE ...)? > > > > TIA > > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lorimer at gmail.com Mon Sep 5 04:22:38 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Mon, 5 Sep 2016 18:22:38 +1000 Subject: [cmake-developers] targets with the same name as their enclosing directory can't be built when in that directory. Message-ID: I have the following directory structure: src/ +---- foo/ | +--- foobar/ +---- bar/ src/CMakeLists adds the foo and bar subdirectories src/foo/CMakeLists adds the foobar subdirectory src/foobar/CMakeLists and src/bar/CMakeLists create 2 executables (foobar and bar) $ cat src/CMakeLists.txt cmake_minimum_required (VERSION 3.2.2) project (cmake_test CXX) add_subdirectory (foo) add_subdirectory (bar) $ cat src/foo/CMakeLists.txt add_subdirectory (foobar) $ cat src/foo/foobar/CMakeLists.txt add_executable(foobar main.cpp) $ cat src/bar/CMakeLists.txt add_executable(bar main.cpp) I generate the makefiles: $ mkdir build && cd build $ cmake .. I can build foobar and bar by specifying "make foobar" and "make bar" from the build root directory ~src/build/ $ make foobar [100%] Built target foobar ~src/build/ $ make bar [100%] Built target bar However, if I am in the build/foo directory, then nothing happens if I "make foobar". ~src/build/foo/ $ make foobar I believe this is because make considers foobar to be a directory it needs to create, and since it exists, there is nothing to do. This is different behaviour to when I'm in the build root directory and "make bar". In this instance "bar" is also a directory, but make behaves differently in this instance, and builds the bar target. I'm guessing because in the root makefile "bar" is a phony target, but in the foo makefile, "foobar" isn't. If I just type "make" in the foo subdirectory, then all targets defined in this part of the tree are built correctly. It is just specifying a target with the same name as a subdirectory from a location that is deeper than the built root that doesn't work. How can I enable building from somewhere *inside* the build tree of targets that have the same name as their enclosing directory? A github repo with the code presented here is at: https://github.com/skebanga/nested_cmake TIA Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Sep 5 08:42:27 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 5 Sep 2016 08:42:27 -0400 Subject: [cmake-developers] targets with the same name as their enclosing directory can't be built when in that directory. In-Reply-To: References: Message-ID: On 09/05/2016 04:22 AM, Steve Lorimer wrote: > $ cat src/foo/foobar/CMakeLists.txt > add_executable(foobar main.cpp) > However, if I am in the build/foo directory, then nothing happens > if I "make foobar". That's because the foobar target is defined in build/foo/foobar. The target names are only buildable in the top level or in the subdirectory that defines a given target. -Brad From cristian.adam at gmail.com Mon Sep 5 16:01:28 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Mon, 5 Sep 2016 22:01:28 +0200 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie Message-ID: Hi, Compiling CMake for Raspberri Pi (Raspbian Jessie) used to work simply as: ./bootstrap make sudo make install with CMake 3.6.1, build fails with: make [ 3%] Built target cmsys [ 3%] Built target cmsysTestDynload [ 4%] Built target cmsys_c [ 4%] Built target cmsysTestProcess [ 5%] Built target cmsysTestSharedForward [ 5%] Built target cmsysTestsC [ 7%] Built target cmsysTestsCxx [ 9%] Built target kwiml_test [ 11%] Built target cmzlib [ 30%] Built target cmcurl [ 30%] Built target LIBCURL [ 30%] Built target cmcompress [ 31%] Built target cmbzip2 [ 42%] Built target cmliblzma [ 60%] Built target cmlibarchive [ 61%] Built target cmexpat *[ 62%] Built target cmjsoncpp* [ 82%] Built target CMakeLib [ 85%] Built target CPackLib [ 93%] Built target CTestLib [ 93%] Linking CXX executable ../bin/cmake libCMakeLib.a(cmGlobalGenerator.cxx.o): In function `cmGlobalGenerator::WriteSummary(cmGeneratorTarget*)': cmGlobalGenerator.cxx:(.text+0x117a8): undefined reference to `Json::Value::Value(Json::ValueType)' cmGlobalGenerator.cxx:(.text+0x117b8): undefined reference to `Json::Value::operator[](char const*)' cmGlobalGenerator.cxx:(.text+0x117cc): undefined reference to `Json::Value::Value(Json::ValueType)' cmGlobalGenerator.cxx:(.text+0x117dc): undefined reference to `Json::Value::operator=(Json::Value)' cmGlobalGenerator.cxx:(.text+0x117f0): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x117fc): undefined reference to `Json::Value::operator[](char const*)' cmGlobalGenerator.cxx:(.text+0x1181c): undefined reference to `Json::Value::Value(std::string const&)' cmGlobalGenerator.cxx:(.text+0x1182c): undefined reference to `Json::Value::operator=(Json::Value)' cmGlobalGenerator.cxx:(.text+0x11838): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11844): undefined reference to `Json::Value::operator[](char const*)' cmGlobalGenerator.cxx:(.text+0x11858): undefined reference to `Json::Value::Value(Json::ValueType)' cmGlobalGenerator.cxx:(.text+0x11868): undefined reference to `Json::Value::operator=(Json::Value)' cmGlobalGenerator.cxx:(.text+0x1187c): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x1188c): undefined reference to `Json::Value::operator[](char const*)' cmGlobalGenerator.cxx:(.text+0x118a0): undefined reference to `Json::Value::Value(Json::ValueType)' cmGlobalGenerator.cxx:(.text+0x118b0): undefined reference to `Json::Value::operator=(Json::Value)' cmGlobalGenerator.cxx:(.text+0x118c4): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11a1c): undefined reference to `Json::Value::Value(std::string const&)' cmGlobalGenerator.cxx:(.text+0x11a2c): undefined reference to `Json::Value::append(Json::Value const&)' cmGlobalGenerator.cxx:(.text+0x11a38): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11c1c): undefined reference to `Json::Value::Value(Json::ValueType)' cmGlobalGenerator.cxx:(.text+0x11c2c): undefined reference to `Json::Value::append(Json::Value const&)' cmGlobalGenerator.cxx:(.text+0x11c40): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11c98): undefined reference to `Json::Value::operator[](char const*)' cmGlobalGenerator.cxx:(.text+0x11cac): undefined reference to `Json::Value::Value(std::string const&)' cmGlobalGenerator.cxx:(.text+0x11cbc): undefined reference to `Json::Value::operator=(Json::Value)' cmGlobalGenerator.cxx:(.text+0x11cc8): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11d40): undefined reference to `Json::Value::operator[](char const*)' cmGlobalGenerator.cxx:(.text+0x11d54): undefined reference to `Json::Value::Value(Json::ValueType)' cmGlobalGenerator.cxx:(.text+0x11d64): undefined reference to `Json::Value::operator=(Json::Value)' cmGlobalGenerator.cxx:(.text+0x11d78): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11e58): undefined reference to `Json::Value::Value(std::string const&)' cmGlobalGenerator.cxx:(.text+0x11e68): undefined reference to `Json::Value::append(Json::Value const&)' cmGlobalGenerator.cxx:(.text+0x11e74): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11f60): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11fd0): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11fe0): undefined reference to `Json::Value::~Value()' cmGlobalGenerator.cxx:(.text+0x11ff0): undefined reference to `Json::Value::~Value()' libCMakeLib.a(cmGlobalGenerator.cxx.o):cmGlobalGenerator.cxx:(.text+0x12000): more undefined references to `Json::Value::~Value()' follow ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::FastWriter::writeValue(Json::Value const&)': json_writer.cpp:(.text+0xc4c): undefined reference to `Json::Value::type() const' json_writer.cpp:(.text+0xcbc): undefined reference to `Json::Value::asLargestInt() const' json_writer.cpp:(.text+0xd08): undefined reference to `Json::Value::asLargestUInt() const' json_writer.cpp:(.text+0xd54): undefined reference to `Json::Value::asDouble() const' json_writer.cpp:(.text+0xd98): undefined reference to `Json::Value::asCString() const' json_writer.cpp:(.text+0xddc): undefined reference to `Json::Value::asBool() const' json_writer.cpp:(.text+0xe30): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0xe70): undefined reference to `Json::Value::operator[](int) const' json_writer.cpp:(.text+0xec4): undefined reference to `Json::Value::getMemberNames() const' json_writer.cpp:(.text+0xfc4): undefined reference to `Json::Value::operator[](std::string const&) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledWriter::writeValue(Json::Value const&)': json_writer.cpp:(.text+0x1254): undefined reference to `Json::Value::type() const' json_writer.cpp:(.text+0x12dc): undefined reference to `Json::Value::asLargestInt() const' json_writer.cpp:(.text+0x1320): undefined reference to `Json::Value::asLargestUInt() const' json_writer.cpp:(.text+0x1364): undefined reference to `Json::Value::asDouble() const' json_writer.cpp:(.text+0x13a0): undefined reference to `Json::Value::asCString() const' json_writer.cpp:(.text+0x13dc): undefined reference to `Json::Value::asBool() const' json_writer.cpp:(.text+0x1434): undefined reference to `Json::Value::getMemberNames() const' json_writer.cpp:(.text+0x1520): undefined reference to `Json::Value::operator[](std::string const&) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledWriter::writeArrayValue(Json::Value const&)': json_writer.cpp:(.text+0x1794): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0x189c): undefined reference to `Json::Value::operator[](unsigned int) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledWriter::isMultineArray(Json::Value const&)': json_writer.cpp:(.text+0x1b30): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0x1b88): undefined reference to `Json::Value::operator[](int) const' json_writer.cpp:(.text+0x1ba4): undefined reference to `Json::Value::isArray() const' json_writer.cpp:(.text+0x1bb8): undefined reference to `Json::Value::isObject() const' json_writer.cpp:(.text+0x1bcc): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0x1c78): undefined reference to `Json::Value::operator[](int) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledWriter::writeCommentBeforeValue(Json::Value const&)': json_writer.cpp:(.text+0x1fcc): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x2014): undefined reference to `Json::Value::getComment(Json::CommentPlacement) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledWriter::writeCommentAfterValueOnSameLine(Json::Value const&)': json_writer.cpp:(.text+0x21b0): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x21d8): undefined reference to `Json::Value::getComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x2244): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x2280): undefined reference to `Json::Value::getComment(Json::CommentPlacement) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledWriter::hasCommentForValue(Json::Value const&)': json_writer.cpp:(.text+0x2354): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x236c): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x2384): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledStreamWriter::writeValue(Json::Value const&)': json_writer.cpp:(.text+0x25e8): undefined reference to `Json::Value::type() const' json_writer.cpp:(.text+0x2670): undefined reference to `Json::Value::asLargestInt() const' json_writer.cpp:(.text+0x26b4): undefined reference to `Json::Value::asLargestUInt() const' json_writer.cpp:(.text+0x26f8): undefined reference to `Json::Value::asDouble() const' json_writer.cpp:(.text+0x2734): undefined reference to `Json::Value::asCString() const' json_writer.cpp:(.text+0x2770): undefined reference to `Json::Value::asBool() const' json_writer.cpp:(.text+0x27c8): undefined reference to `Json::Value::getMemberNames() const' json_writer.cpp:(.text+0x28b4): undefined reference to `Json::Value::operator[](std::string const&) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledStreamWriter::writeArrayValue(Json::Value const&)': json_writer.cpp:(.text+0x2b2c): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0x2c30): undefined reference to `Json::Value::operator[](unsigned int) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledStreamWriter::isMultineArray(Json::Value const&)': json_writer.cpp:(.text+0x2ec0): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0x2f14): undefined reference to `Json::Value::operator[](int) const' json_writer.cpp:(.text+0x2f30): undefined reference to `Json::Value::isArray() const' json_writer.cpp:(.text+0x2f44): undefined reference to `Json::Value::isObject() const' json_writer.cpp:(.text+0x2f58): undefined reference to `Json::Value::size() const' json_writer.cpp:(.text+0x3000): undefined reference to `Json::Value::operator[](int) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledStreamWriter::writeCommentBeforeValue(Json::Value const&)': json_writer.cpp:(.text+0x327c): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x32b0): undefined reference to `Json::Value::getComment(Json::CommentPlacement) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledStreamWriter::writeCommentAfterValueOnSameLine(Json::Value const&)': json_writer.cpp:(.text+0x3350): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x3378): undefined reference to `Json::Value::getComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x33e4): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x3420): undefined reference to `Json::Value::getComment(Json::CommentPlacement) const' ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::StyledStreamWriter::hasCommentForValue(Json::Value const&)': json_writer.cpp:(.text+0x34f4): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x350c): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' json_writer.cpp:(.text+0x3524): undefined reference to `Json::Value::hasComment(Json::CommentPlacement) const' collect2: error: ld returned 1 exit status Source/CMakeFiles/cmake.dir/build.make:130: recipe for target 'bin/cmake' failed make[2]: *** [bin/cmake] Error 1 CMakeFiles/Makefile2:2049: recipe for target 'Source/CMakeFiles/cmake.dir/all' failed make[1]: *** [Source/CMakeFiles/cmake.dir/all] Error 2 Makefile:149: recipe for target 'all' failed make: *** [all] Error 2 CMake comes with batteries included and it should just work. No idea why it can't find its own cmjsoncpp library Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Sep 5 16:33:52 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 5 Sep 2016 16:33:52 -0400 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie In-Reply-To: References: Message-ID: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> On 09/05/2016 04:01 PM, Cristian Adam wrote: > [ 62%] Built target cmjsoncpp [snip] > [ 93%] Linking CXX executable ../bin/cmake > libCMakeLib.a(cmGlobalGenerator.cxx.o): In function `cmGlobalGenerator::WriteSummary(cmGeneratorTarget*)': > cmGlobalGenerator.cxx:(.text+0x117a8): undefined reference to `Json::Value::Value(Json::ValueType)' [snip] > ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function `Json::FastWriter::writeValue(Json::Value const&)': [snip] > No idea why it can't find its own cmjsoncpp library Actually it is finding the library because some of the error messages reference objects in it. Something goes wrong with finding some of the symbols in it, such as some from `json_value.cpp`. What is the output of? $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a I don't have access to this platform so hopefully someone else can dig into it further. Perhaps some preprocessing differences cause symbol mangling to be different across sources. -Brad From cristian.adam at gmail.com Mon Sep 5 16:39:03 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Mon, 5 Sep 2016 22:39:03 +0200 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie In-Reply-To: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> References: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> Message-ID: On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote: > On 09/05/2016 04:01 PM, Cristian Adam wrote: > > [ 62%] Built target cmjsoncpp > [snip] > > [ 93%] Linking CXX executable ../bin/cmake > > libCMakeLib.a(cmGlobalGenerator.cxx.o): In function `cmGlobalGenerator:: > WriteSummary(cmGeneratorTarget*)': > > cmGlobalGenerator.cxx:(.text+0x117a8): undefined reference to > `Json::Value::Value(Json::ValueType)' > [snip] > > ../Utilities/cmjsoncpp/libcmjsoncpp.a(json_writer.cpp.o): In function > `Json::FastWriter::writeValue(Json::Value const&)': > [snip] > > No idea why it can't find its own cmjsoncpp library > > Actually it is finding the library because some of the error messages > reference objects in it. Something goes wrong with finding some of > the symbols in it, such as some from `json_value.cpp`. > What is the output of? > > $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a > > $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a json_reader.cpp.o json_value.cpp.o json_writer.cpp.o Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Tue Sep 6 07:26:08 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 6 Sep 2016 11:26:08 +0000 Subject: [cmake-developers] [Patch 5/5] Improved WIX support In-Reply-To: <81f17829-dcea-fa00-ac39-3942d4fc3384@gmail.com> References: <95f264e5-ea18-ac48-6974-86b8ce167e95@gmail.com> <7d2346e2cd9e44ed8698e81f93e90390@DE013666.schaeffler.com> <18345fa8-15c5-eed7-1353-b8b2f9ccf5ab@gmail.com> <8b081282e1d743a6a7c0a0723417e399@DE013666.schaeffler.com> <81f17829-dcea-fa00-ac39-3942d4fc3384@gmail.com> Message-ID: <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> > -----Original Message----- > From: Nils Gladitz [mailto:nilsgladitz at gmail.com] > Sent: Tuesday, August 16, 2016 12:52 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 08/16/2016 11:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > >> There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so > >> I think such an interface change would be fine. > >> > > Ok I'll do this. Should solve all issues and doubts hopefully. > > Great. Thanks. > Here it is. > > > > Adding FeatureRef to #PRODUCT does not work. I get the following > message: > > > > features.wixobj : error LGHT0095 : Multiple primary references were found > for Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}' > > Did you try with IgnoreParent="yes" on your FeatureRef element? > It makes sense that there can only be one root-Feature. > Yes I tried, didn't work somehow. Never mind, the current approach works. > Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-enabled-patching-of-WIX-Feature-tags.patch Type: application/octet-stream Size: 4009 bytes Desc: 0003-enabled-patching-of-WIX-Feature-tags.patch URL: From michael.stuermer at schaeffler.com Tue Sep 6 07:29:33 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 6 Sep 2016 11:29:33 +0000 Subject: [cmake-developers] PATCH: Bugfix for WIX support Message-ID: The generated guid values where not set correctly everywhere. This could lead to WIX build errors when using the CPACK_WIX_SKIP_PROGRAM_FOLDER option. Viele Gr??e Michael St?rmer ?? SZ. Prozessdatenverarbeitung SP/HZA-ZSEP??Tel. +499132 82-86350 ?Mobil.: +49(171)6860010 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixed-setting-of-invalid-guids-in-WIX-source-files-i.patch Type: application/octet-stream Size: 4846 bytes Desc: 0001-fixed-setting-of-invalid-guids-in-WIX-source-files-i.patch URL: From michael.stuermer at schaeffler.com Tue Sep 6 07:32:34 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 6 Sep 2016 11:32:34 +0000 Subject: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources Message-ID: <4276cbcb3e6642a4b7d81efdec033087@DE013666.schaeffler.com> best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-added-support-for-custom-WIX-namespaces-in-generated.patch Type: application/octet-stream Size: 8586 bytes Desc: 0002-added-support-for-custom-WIX-namespaces-in-generated.patch URL: From brad.king at kitware.com Tue Sep 6 08:26:01 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 6 Sep 2016 08:26:01 -0400 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie In-Reply-To: References: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> Message-ID: <6d732325-77f5-7f3b-d321-bc397892c127@kitware.com> On 09/05/2016 04:39 PM, Cristian Adam wrote: > On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote: >> Something goes wrong with finding some of the symbols in it, >> such as some from `json_value.cpp`. > > $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a > json_reader.cpp.o > json_value.cpp.o > json_writer.cpp.o >From the binary you sent me: ``` $ file Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/*.o Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/json_reader.cpp.o: empty Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/json_value.cpp.o: empty Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/json_writer.cpp.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped ``` Somehow two of the .o files ended up empty. The Makefile content looks fine and the command line to compile is the same for all three sources. Is this reproducible? If you remove the two empty files and build again do they still end up empty? -Brad From nilsgladitz at gmail.com Tue Sep 6 08:28:33 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 6 Sep 2016 14:28:33 +0200 Subject: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources In-Reply-To: <4276cbcb3e6642a4b7d81efdec033087@DE013666.schaeffler.com> References: <4276cbcb3e6642a4b7d81efdec033087@DE013666.schaeffler.com> Message-ID: <12503d75-8a3c-94de-f378-b5dc3fe7de58@gmail.com> On 09/06/2016 01:32 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > best regards, > Michael Can you elaborate your use case for the patch? I assume this if for custom patch fragments? In that context wouldn't it suffice to add the namespace declarations to the elements that need them (in the patch fragment itself)? The patch is also missing documentation for the new CPACK_WIX_NAMESPACES variable that it introduces. Thanks. Nils From michael.stuermer at schaeffler.com Tue Sep 6 09:29:51 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 6 Sep 2016 13:29:51 +0000 Subject: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources In-Reply-To: <12503d75-8a3c-94de-f378-b5dc3fe7de58@gmail.com> References: <4276cbcb3e6642a4b7d81efdec033087@DE013666.schaeffler.com> <12503d75-8a3c-94de-f378-b5dc3fe7de58@gmail.com> Message-ID: Wow, thanks for the fast answer! > -----Original Message----- > From: Nils Gladitz [mailto:nilsgladitz at gmail.com] > Sent: Tuesday, September 06, 2016 2:29 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: add custom xmlns namespaces into > generated .wxs sources > > On 09/06/2016 01:32 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > best regards, > > Michael > > Can you elaborate your use case for the patch? > > I assume this if for custom patch fragments? > In that context wouldn't it suffice to add the namespace declarations to the > elements that need them (in the patch fragment itself)? > Hm, I don't see how I can add a namespace before my patch fragment. If I want to use some element from let's say UtilExtension, I need to add the xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" attribute in some parent XML node as far as I understand (no XML expert though). When patching an element, I cannot set attributes within the actual parent node I am patching. For now I managed to move all usages of additional namespace to custom WIX sources, so I do not depend on this patch anymore. Nevertheless I believe it's a good thing being able to influence the used namespaces. > The patch is also missing documentation for the new > CPACK_WIX_NAMESPACES variable that it introduces. > Oh, right. Sorry. I will provide it (if the change will be accepted). > Thanks. > > Nils From nilsgladitz at gmail.com Tue Sep 6 09:45:21 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 6 Sep 2016 15:45:21 +0200 Subject: [cmake-developers] PATCH: Bugfix for WIX support In-Reply-To: References: Message-ID: On 09/06/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > The generated guid values where not set correctly everywhere. This could lead to WIX build errors when using the CPACK_WIX_SKIP_PROGRAM_FOLDER option. Thanks. I modified the patch to work without the global/public GenerateComponentGuids and instead pass the state down into each individual vmWIXSourceWriter instance: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=fe20015b13d6ccf10d99ff9b3d8f68919164fcf8 Please verify that I haven't broken anything. Nils From nilsgladitz at gmail.com Tue Sep 6 09:50:16 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 6 Sep 2016 15:50:16 +0200 Subject: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources In-Reply-To: References: <4276cbcb3e6642a4b7d81efdec033087@DE013666.schaeffler.com> <12503d75-8a3c-94de-f378-b5dc3fe7de58@gmail.com> Message-ID: On 09/06/2016 03:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Hm, I don't see how I can add a namespace before my patch fragment. If I want to use some element from let's say UtilExtension, I need to add the xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" attribute in some parent XML node as far as I understand (no XML expert though). You only have to declare the namespace on the element itself. There is no need for the parent to have it declared. So unless you object for other reasons I don't think the patch is necessary? Nils From michael.stuermer at schaeffler.com Tue Sep 6 10:05:20 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 6 Sep 2016 14:05:20 +0000 Subject: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources In-Reply-To: References: <4276cbcb3e6642a4b7d81efdec033087@DE013666.schaeffler.com> <12503d75-8a3c-94de-f378-b5dc3fe7de58@gmail.com> Message-ID: > -----Original Message----- > From: Nils Gladitz [mailto:nilsgladitz at gmail.com] > Sent: Tuesday, September 06, 2016 3:50 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: add custom xmlns namespaces into > generated .wxs sources > > On 09/06/2016 03:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > > > Hm, I don't see how I can add a namespace before my patch fragment. If I > want to use some element from let's say UtilExtension, I need to add the > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" attribute in > some parent XML node as far as I understand (no XML expert though). > > You only have to declare the namespace on the element itself. There is no > need for the parent to have it declared. > Every day you learn something new, good. This feels a bit strange, but it works! Obviously the patch is not necessary. > So unless you object for other reasons I don't think the patch is necessary? > > Nils From nilsgladitz at gmail.com Tue Sep 6 10:28:01 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 6 Sep 2016 16:28:01 +0200 Subject: [cmake-developers] PATCH: Bugfix for WIX support In-Reply-To: References: Message-ID: <540d1bc3-6e6c-1f8b-7760-263c0a6e472e@gmail.com> On 09/06/2016 03:45 PM, Nils Gladitz wrote: > > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=fe20015b13d6ccf10d99ff9b3d8f68919164fcf8 > > > Please verify that I haven't broken anything. I broke writing of WIX include files. Should be fixed now: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=19f96b8bd54a6dc9c4c08ba90250c3a7ae013227 Nils From michael.stuermer at schaeffler.com Tue Sep 6 11:19:51 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 6 Sep 2016 15:19:51 +0000 Subject: [cmake-developers] PATCH: Bugfix for WIX support In-Reply-To: <540d1bc3-6e6c-1f8b-7760-263c0a6e472e@gmail.com> References: <540d1bc3-6e6c-1f8b-7760-263c0a6e472e@gmail.com> Message-ID: > -----Original Message----- > From: Nils Gladitz [mailto:nilsgladitz at gmail.com] > Sent: Tuesday, September 06, 2016 4:28 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: Bugfix for WIX support > > On 09/06/2016 03:45 PM, Nils Gladitz wrote: > > > > > > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=fe20015b13d6ccf > 10d99ff9b3d8f68919164fcf8 > > > > > > Please verify that I haven't broken anything. > > I broke writing of WIX include files. Should be fixed now: > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=19f96b8bd54a6d > c9c4c08ba90250c3a7ae013227 > > Nils I checked everything on our project. Works as expected so far. I had to add our CSharp patch(es) on top, so this is not a pure WIX feature test, but I think it's good to go. Michael From nilsgladitz at gmail.com Tue Sep 6 11:47:48 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 6 Sep 2016 17:47:48 +0200 Subject: [cmake-developers] PATCH: Bugfix for WIX support In-Reply-To: References: <540d1bc3-6e6c-1f8b-7760-263c0a6e472e@gmail.com> Message-ID: On 06.09.2016 17:19, Stuermer, Michael SP/HZA-ZSEP wrote: > I checked everything on our project. Works as expected so far. I had to add our CSharp patch(es) on top, so this is not a pure WIX feature test, but I think it's good to go. > Thanks I reformatted, squashed and merged to "next" for testing. Nils From cristian.adam at gmail.com Tue Sep 6 14:39:28 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 6 Sep 2016 20:39:28 +0200 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie In-Reply-To: <6d732325-77f5-7f3b-d321-bc397892c127@kitware.com> References: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> <6d732325-77f5-7f3b-d321-bc397892c127@kitware.com> Message-ID: <890dc9bf-a52c-b341-bb8e-5af6571e9e89@gmail.com> On 06-Sep-16 14:26, Brad King wrote: > On 09/05/2016 04:39 PM, Cristian Adam wrote: >> On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote: >>> Something goes wrong with finding some of the symbols in it, >>> such as some from `json_value.cpp`. >> $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a >> json_reader.cpp.o >> json_value.cpp.o >> json_writer.cpp.o > From the binary you sent me: > > ``` > $ file Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/*.o > Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/json_reader.cpp.o: empty > Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/json_value.cpp.o: empty > Utilities/cmjsoncpp/CMakeFiles/cmjsoncpp.dir/src/lib_json/json_writer.cpp.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped > ``` > > Somehow two of the .o files ended up empty. The Makefile content > looks fine and the command line to compile is the same for all > three sources. Is this reproducible? If you remove the two empty > files and build again do they still end up empty? > > -Brad Removal of the empty object files lead to a successful compilation. In retrospect I should have cleaned my build directory after my Raspberry PI froze when compiling with MAKEFLAGS=-j4. Bootstrap compiled fine with -j4, but make managed to crash the system with -j4 and -j3. Who should have noticed that the two object files were empty and try a new compilation? CMake or make? Cheers, Cristian. From irods.ben.keller at gmail.com Tue Sep 6 15:00:03 2016 From: irods.ben.keller at gmail.com (Ben Keller) Date: Tue, 6 Sep 2016 15:00:03 -0400 Subject: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/" Message-ID: CMake version 3.5.0 When exporting from a project (with install(EXPORT ...)), theTargets.cmake file contains logic for computing the _IMPORT_PREFIX. This _IMPORT_PREFIX is then used in the Targets-.cmake file to generate the IMPORTED_LOCATION_. The generation appears to be accomplished by unconditionally appending a "/" to _IMPORT_PREFIX before appending the rest of the path. If _IMPORT_PREFIX is "/", then the IMPORTED_LOCATION_ properties all start with exactly two leading slashes ("//"). Exactly two leading slashes is apparently a special case in POSIX file paths, such that its interpretation is left up to the implementation. This means that changing the path prefix from "/" to "//" should not be allowed. A result of this is that when importing a library installed to /usr/lib, the IMPORTED_LOCATION_DEBUG ends up being "//usr/lib/libmylib.so". At this point in the project, CMake doesn't contract the two leading slashes (as it apparently shouldn't), so executables linking against the mylib target end up with "//usr/lib" in their RPATH. This works fine with the Linux dynamic linker, but if a program uses dladdr() to get the location of the shared library, the leading "//" is still present. Manipulation of this path within the program (e.g. with boost::filesystem) then fails to work as expected, if the manipulation code is sensitive to the leading "//". Example of generated cmake code when CPACK_PACKAGING_INSTALL_PREFIX is "/" and Targets.cmake is installed via the INSTALL() command with DESTINATION "usr/lib//cmake": [ -- From Targets.cmake -- ] # Compute the installation prefix relative to this file. get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) [ -- From Targets-.cmake -- ] IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/usr/lib/libmylib.so" The workaround we are using for this currently is to compile a modified version of cmake that appends the following cmake code below the get_filename_component stanza in Targets.cmake: if("${_IMPORT_PREFIX}" STREQUAL "/") set(_IMPORT_PREFIX "") endif() From brad.king at kitware.com Tue Sep 6 15:13:20 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 6 Sep 2016 15:13:20 -0400 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie In-Reply-To: <890dc9bf-a52c-b341-bb8e-5af6571e9e89@gmail.com> References: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> <6d732325-77f5-7f3b-d321-bc397892c127@kitware.com> <890dc9bf-a52c-b341-bb8e-5af6571e9e89@gmail.com> Message-ID: <5b16d505-460b-d72a-e94c-a9a73d25c7bb@kitware.com> On 09/06/2016 02:39 PM, Cristian Adam wrote: > Who should have noticed that the two object files were empty and try a > new compilation? CMake or make? Nothing. This is not a failure case that we expect to be handled. The .o files exist with a timestamp newer than their dependencies, so the build system thinks they are up to date. The fact that the wrong content was written to them due to a system failure is not something we can know or tolerate. -Brad From brad.king at kitware.com Tue Sep 6 15:24:51 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 6 Sep 2016 15:24:51 -0400 Subject: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/" In-Reply-To: References: Message-ID: <22ab26be-9ca2-083d-bd8a-67031e106fce@kitware.com> On 09/06/2016 03:00 PM, Ben Keller wrote: > The workaround we are using for this currently is to compile a > modified version of cmake that appends the following cmake code below > the get_filename_component stanza in Targets.cmake: > > if("${_IMPORT_PREFIX}" STREQUAL "/") > set(_IMPORT_PREFIX "") > endif() I would consider that a fix rather than a workaround. We don't know the prefix that will be computed since this block is meant to make the package relocatable. We do know that references to the prefix are always followed by "/" so it is safe to leave it as an empty string. Please post the patch. Thanks, -Brad From irods.ben.keller at gmail.com Tue Sep 6 16:31:26 2016 From: irods.ben.keller at gmail.com (Ben Keller) Date: Tue, 6 Sep 2016 16:31:26 -0400 Subject: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/" In-Reply-To: <22ab26be-9ca2-083d-bd8a-67031e106fce@kitware.com> References: <22ab26be-9ca2-083d-bd8a-67031e106fce@kitware.com> Message-ID: Thank you On Tue, Sep 6, 2016 at 3:24 PM, Brad King wrote: > On 09/06/2016 03:00 PM, Ben Keller wrote: >> The workaround we are using for this currently is to compile a >> modified version of cmake that appends the following cmake code below >> the get_filename_component stanza in Targets.cmake: >> >> if("${_IMPORT_PREFIX}" STREQUAL "/") >> set(_IMPORT_PREFIX "") >> endif() > > I would consider that a fix rather than a workaround. We don't know > the prefix that will be computed since this block is meant to make > the package relocatable. We do know that references to the prefix > are always followed by "/" so it is safe to leave it as an empty > string. > > Please post the patch. > > Thanks, > -Brad > -------------- next part -------------- A non-text attachment was scrubbed... Name: edit_IMPORT_PREFIX.patch Type: text/x-patch Size: 1888 bytes Desc: not available URL: From rleigh at codelibre.net Tue Sep 6 17:05:32 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 6 Sep 2016 21:05:32 +0000 Subject: [cmake-developers] [patch] Expose GNUInstallDirs absolute path algorithm In-Reply-To: References: <552e0cb1-0ea8-802f-4710-ac1cd5b51e29@codelibre.net> Message-ID: On 30/08/2016 14:53, Brad King wrote: > On 08/28/2016 01:51 PM, Roger Leigh wrote: >> The macro name might need adjusting > > The idea looks fine to me. Typically we name module-provided APIs with > the module name. How about "GNUInstallDirs_get_absolute_install_dir"? > I'm also open to other suggestions. Seems fine to me. I've merged this (with the above modification) into next for testing; branch gid-func. Regards, Roger From steve.lorimer at gmail.com Tue Sep 6 19:25:52 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Wed, 7 Sep 2016 09:25:52 +1000 Subject: [cmake-developers] targets with the same name as their enclosing directory can't be built when in that directory. In-Reply-To: References: Message-ID: Ok, thanks Brad On 5 September 2016 at 22:42, Brad King wrote: > On 09/05/2016 04:22 AM, Steve Lorimer wrote: > > $ cat src/foo/foobar/CMakeLists.txt > > add_executable(foobar main.cpp) > > However, if I am in the build/foo directory, then nothing happens > > if I "make foobar". > > That's because the foobar target is defined in build/foo/foobar. > The target names are only buildable in the top level or in the > subdirectory that defines a given target. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Wed Sep 7 02:27:38 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Wed, 7 Sep 2016 08:27:38 +0200 Subject: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie In-Reply-To: <5b16d505-460b-d72a-e94c-a9a73d25c7bb@kitware.com> References: <46d90d3c-c608-5dfa-ead2-9b43bef39d87@kitware.com> <6d732325-77f5-7f3b-d321-bc397892c127@kitware.com> <890dc9bf-a52c-b341-bb8e-5af6571e9e89@gmail.com> <5b16d505-460b-d72a-e94c-a9a73d25c7bb@kitware.com> Message-ID: On Tue, Sep 6, 2016 at 9:13 PM, Brad King wrote: > On 09/06/2016 02:39 PM, Cristian Adam wrote: > > Who should have noticed that the two object files were empty and try a > > new compilation? CMake or make? > > Nothing. This is not a failure case that we expect to be handled. > The .o files exist with a timestamp newer than their dependencies, > so the build system thinks they are up to date. The fact that the > wrong content was written to them due to a system failure is not > something we can know or tolerate. > > -Brad > > I see. Due to object headers one should not be able to produce an empty object file with a compiler. Brad, thank you for the help. Now I know how to analyze archive files \m/ Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 7 08:26:29 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 7 Sep 2016 08:26:29 -0400 Subject: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/" In-Reply-To: References: <22ab26be-9ca2-083d-bd8a-67031e106fce@kitware.com> Message-ID: <3e009ef5-faf4-0f0a-4fc4-c212d99c70e3@kitware.com> On 09/06/2016 04:31 PM, Ben Keller wrote: >> Please post the patch. > Thank you Thanks, applied with minor tweaks: install: Fix computed import prefix in export files when it is "/" https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290e4ce8 Please try out that version. -Brad From irods.ben.keller at gmail.com Wed Sep 7 13:39:45 2016 From: irods.ben.keller at gmail.com (Ben Keller) Date: Wed, 7 Sep 2016 13:39:45 -0400 Subject: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/" In-Reply-To: <3e009ef5-faf4-0f0a-4fc4-c212d99c70e3@kitware.com> References: <22ab26be-9ca2-083d-bd8a-67031e106fce@kitware.com> <3e009ef5-faf4-0f0a-4fc4-c212d99c70e3@kitware.com> Message-ID: Thank you, it is working as expected. On Wed, Sep 7, 2016 at 8:26 AM, Brad King wrote: > On 09/06/2016 04:31 PM, Ben Keller wrote: >>> Please post the patch. >> Thank you > > Thanks, applied with minor tweaks: > > install: Fix computed import prefix in export files when it is "/" > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290e4ce8 > > Please try out that version. > > -Brad > From robert.maynard at kitware.com Wed Sep 7 15:27:41 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 7 Sep 2016 15:27:41 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.2 available for download Message-ID: We are pleased to announce that CMake 3.6.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.6.2 since 3.6.1: Ben Boeckel (3): Intel-C: declare support for gnu11 Intel-C: support gnu89 and gnu99 extension flags Intel-C: standard flags are also supported in 12.0 Brad King (11): Add script to update curl from upstream curl: Update script to get curl 7.50.1 curl: Remove CMake-specific README VS: Fix VS 2015 .vcxproj debug setting for Windows7.1SDK toolset GetPrerequisites: Fix regression in gp_resolved_file_type Fortran: Fix .mod file comparison for Intel 16 format VS: Fix VS 2015 .vcxproj debug setting for v80 toolset FindHDF5: Fix regression in providing HDF5_IS_PARALLEL FindHDF5: Fix regression in finding hdf5hl_fortran curl: Backport certificate reuse fix from 7.50.2 CMake 3.6.2 Chuck Atkins (2): FindHDF5: Make sure compile definition vars keep the -D flag CrayLinuxEnvironment: Add alternative methods to get version info Curl Upstream (2): curl 2015-08-11 (1a7f66a3) curl 2016-08-03 (f2cb3a01) Fujii Hironori (1): VS: Fix out-of-bounds write on empty Nsight Tegra version Konstantin Sinitsyn (1): FindProtobuf: Restore support for PROTOBUF_IMPORT_DIRS From daniel at pfeifer-mail.de Wed Sep 7 16:52:06 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 7 Sep 2016 22:52:06 +0200 Subject: [cmake-developers] Developer tasks - Refactoring In-Reply-To: References: Message-ID: On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly wrote: > 3) Compute cmGeneratorTarget state non-lazily in its constructor. > * Historically target state for generators was computed lazily because it > might need to be cleared and re-computed. That is no-longer true. SourceFilesMap is cleared in a call to AddSource. It is then recomputed the next time GetSourceFiles is called. > * For example, the LinkInformation is populated lazily in > cmGeneratorTarget::GetLinkInformation. > * Instead the LinkInformation could be populated in the cmGeneratorTarget > constructor for all known configurations. That is what generators will > request during generate-time anyway. > * Doing this will make it possible to split a cmComputedTarget out of > cmGeneratorTarget. I started splitting out a cmComputedTarget. It is initialized in its constructor for one single configuration. The entries of the ComputedTargets map are computed and recomputed lazily because of the reason mentioned above. Please review: https://github.com/purpleKarrot/CMake/commits/computed-target From steveire at gmail.com Wed Sep 7 18:44:35 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 08 Sep 2016 00:44:35 +0200 Subject: [cmake-developers] CMake version to build CMake Message-ID: Hi, Currently CMake requires a minimum of CMake 2.8.4 to build. I was reviewing the cmake-server work from Tobias starting with the libuv integration, and I think CMake might benefit from using ALIAS targets in its own build. ALIAS targets were introduced in CMake 2.8.12 (released August 2013). What do you think of updating the requirement to that or higher? Thanks, Steve. From steveire at gmail.com Wed Sep 7 18:36:03 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 08 Sep 2016 00:36:03 +0200 Subject: [cmake-developers] Developer tasks - Refactoring References: Message-ID: Daniel Pfeifer wrote: > On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly > wrote: >> 3) Compute cmGeneratorTarget state non-lazily in its constructor. >> * Historically target state for generators was computed lazily because it >> might need to be cleared and re-computed. That is no-longer true. > > SourceFilesMap is cleared in a call to AddSource. It is then > recomputed the next time GetSourceFiles is called. Hmm, maybe there is a way to reduce the amount of times it is cleared, once the computation sequence is better defined by being extracted to cmComputeTarget. cmGeneratorTarget::AddSource is currently called from several generate-time locations, some of which could become compute-time locations. The uses in * cmQtAutoGeneratorInitializer::InitializeAutogenSources * cmGlobalVisualStudio8Generator::AddCheckTarget * cmLocalVisualStudio7Generator::CreateVCProjBuildRule * cmGlobalXCodeGenerator seem that way to me, because the file names don't depend on anything from the cmGeneratorTarget which is only known at build time. Unless I'm missing something, they could be added to the list of files for the cmComputeTarget at compute time before the SourceFilesMap is populated at generate time. The tricky case is when AddSource is called with something computed from the result of cmGeneratorTarget::GetSources. The only case of that seems to be SetupSourceFiles in cmQtAutoGeneratorInitializer. That calls AddSource in a loop. If cmComputeTarget gains an AddSource and doesn't have a SourceFilesMap, then that would be the only use of cmGeneratorTarget::AddSource. That could then be replaced with a new AddSources or AddSourcesForRCC, or something better might be possible. This is just a brain-dump which I haven't investigated. You might find some facts which make the source addition refactoring to compute time to be impossible. Then maybe the entries of the ComputedTargets map might not have to be recomputed lazily. > Please review: > https://github.com/purpleKarrot/CMake/commits/computed-target Cool, thanks for working on this! I am a bit confused by the first commit in the branch. It removes some c++ template code while adding cmComputeTarget. I think that's because you make the working class inherit from cmComputeTarget, and you do that just to re- use the data members, and then later in the branch, to re-use the cmComputeTarget itself. Is it possible to split what is happening in that commit? Is it possible to remove the template code first without introducing cmComputeTarget? Even if doing so would mean introducing a struct with the same data members early in the branch and perhaps removing that struct later, I think it might make the commit more clear. Currently I don't understand it. I also generally recommend to put the most obvious/cleanup commits at the start of the branch (or even in a separate minor-cleanups branch). The 'don't clear container in destructor' commit and the 'use erase-unique instead of reinitialization' commit and the 'factor out common part of AddSources commands' all seem to fit that description. I was able to rebase them at least, but I didn't try building the result. Getting those kinds of commits out of the way first makes the rest of the branch smaller and focused on extending the code in only one specific way. Thanks, Steve. From nilsgladitz at gmail.com Thu Sep 8 05:19:04 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 8 Sep 2016 11:19:04 +0200 Subject: [cmake-developers] [Patch 5/5] Improved WIX support In-Reply-To: <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> References: <95f264e5-ea18-ac48-6974-86b8ce167e95@gmail.com> <7d2346e2cd9e44ed8698e81f93e90390@DE013666.schaeffler.com> <18345fa8-15c5-eed7-1353-b8b2f9ccf5ab@gmail.com> <8b081282e1d743a6a7c0a0723417e399@DE013666.schaeffler.com> <81f17829-dcea-fa00-ac39-3942d4fc3384@gmail.com> <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> Message-ID: <490c2b8c-0f2f-a994-d545-7d0f6503739f@gmail.com> On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > Yes I tried, didn't work somehow. Never mind, the current approach works. It should have worked. I've added a new working test case to my suite: https://github.com/ngladitz/cmake-wix-testsuite/tree/master/feature_ref_in_product I'll look into integrating your patch for consistency nonetheless but it should not really have been required for your use case. Nils From craig.scott at crascit.com Thu Sep 8 06:08:46 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 8 Sep 2016 18:08:46 +0800 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: Merge request implementing this feature is now up for review here: https://gitlab.kitware.com/cmake/cmake/merge_requests/88 I ended up going with FIXTURE_... test property names rather than GROUP_... since it seemed more specific. I have not implemented the logic for skipping regular tests if any of a fixture's setup tests fail as that would require more change than I wanted to bite off for this initial implementation. If it is really required, I guess it could be done, but my primary concern first is not to introduce new bugs. ;) On Thu, Sep 1, 2016 at 9:17 AM, Craig Scott wrote: > Actually, we can't really re-use the RESOURCE_LOCK for the proposed > RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force > all the tests using that resource to be serialised. So yes, a separate > GROUP or something similar would seem to be needed. Let me amend my earlier > proposal (which is an evolution of Ben's) to something like this: > > > add_test(NAME setup-foo ...) > set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo) > > add_test(NAME cleanup-foo ...) > set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo) > > add_test(NAME use-foo ...) > set_tests_properties(use-foo PROPERTIES GROUP foo) > > > The logic would be as follows: > > - Any test cases with a GROUP_SETUP property for a group will be run > before any test cases with GROUP or GROUP_CLEANUP for that same group. The > order of these setup test cases can be controlled with the existing DEPENDS > test property. > - If any of the group's setup test cases fail, all other test cases > for that group will be skipped. All cleanup test cases for the group > probably should still be run though (it could be hard to try to work out > which cleanup tests should run, so maybe conservatively just run all of > them). > - If all setup test cases passed, then run all test cases for that > group. Regardless of the success or failure of these test cases, once they > are all completed, run all the cleanup test cases associated with the group. > - Ordering of cleanup test cases can again be controlled with the > existing DEPENDS test property. > > What the above buys us is that CTest then knows definitively that if it is > asked to run a test case from a particular group, it must also run the > setup and cleanup test cases associated with that group, regardless of > whether those setup/cleanup test cases are in the set of test cases CTest > was originally asked to run. At the moment, CTest could theoretically do > that for the setup steps based on DEPENDS functionality, but not the > cleanup. The above proposal is very clear about the nature of the > dependency and gives the symmetry of both setup and cleanup behaviour. > > I'm not tied to the terminology of "GROUP" for tying a set of test cases > to their setup/cleanup tasks, so I'm happy to consider alternatives. I'm > also wondering whether simply GROUP for a test property is too generic for > the test cases that require the setup/cleanup (as opposed to the test cases > that ARE the setup/cleanup). > > > On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott > wrote: > >> In my original thinking, I was of the view that if a setup/cleanup step >> needed to be executed for each test rather than for the overall test run as >> a whole, then perhaps the test itself should handle that rather than CMake. >> The existing RESOURCE_LOCK functionality could then be used to prevent >> multiple tests from running concurrently if they would interfere with each >> other. Existing test frameworks like GoogleTest and Boost Test already have >> good support for test fixtures which make doing this per-test setup/cleanup >> easy. The problem I want to solve is where a group of tests share a common >> (set of) setup/cleanup steps and CMake knows to run them when asked to run >> any test cases that require them. The specific problem motivating this work >> was running ctest --rerun-failed, where we need CMake to add in any >> setup/cleanup steps required by any of the tests that will be rerun. With >> that in mind, see further comments interspersed below. >> >> >> On Fri, Aug 26, 2016 at 12:08 AM, Ben Boeckel >> wrote: >> >>> On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote: >>> > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott: >>> > > So how would you want the feature to work? I'd suggest an initial >>> set of >>> > > requirements something like the following: >>> > > >>> > > - Need to support the ability to define multiple setup and/or >>> tear down >>> > > tasks. >>> > > - It should be possible to specify dependencies between setup >>> tasks and >>> > > between tear down tasks. >>> > > - Individual tests need to be able to indicate which setup and/or >>> tear >>> > > down tasks they require, similar to the way DEPENDS is used to >>> specify >>> > > dependencies between test cases. >>> > > - When using ctest --rerun-failed, ctest should automatically >>> invoke any >>> > > setup or tear down tasks required by the test cases that will be >>> re-run. >>> > > - Setup or tear down tasks which reference executable targets >>> should >>> > > substitute the actual built executable just like how >>> add_custom_command() >>> > > does. >>> > >>> > -need a way to mark if 2 tests with the same setup/teardown can share >>> those or >>> > if they need to run for every of them >>> >>> Proposal: >>> >>> add_test(NAME setup-foo ...) >>> set_tests_properties(setup-foo PROPERTIES >>> SETUP_GROUP foo >>> SETUP_STEP SETUP_PER_TEST) # Also SETUP_ONCE. >>> add_test(NAME use-foo ...) >>> set_tests_properties(use-foo PROPERTIES >>> SETUP_GROUP foo) # implicit depends on all SETUP_GROUP foo / >>> SETUP_STEP SETUP_* tests. >>> add_test(NAME use-foo2 ...) >>> set_tests_properties(use-foo2 PROPERTIES >>> SETUP_GROUP foo) >>> add_test(NAME teardown-foo2 ...) >>> set_tests_properties(teardown-foo2 PROPERTIES >>> SETUP_GROUP foo >>> SETUP_STEP TEARDOWN) # implicit depends on all non-TEARDOWN steps >>> >>> Multiple setup/teardown steps could be done with DEPENDS between them. >>> >> >> I like the idea of tests being associated with a group and the group >> itself is where the setup/cleanup steps are attached/associated. That said, >> it would seem that RESOURCE_LOCK already more or less satisfies this >> concept. I'm wondering if we can't just somehow attach setup/cleanup steps >> to the named resource instead. That would be a more seamless evolution of >> the existing functionality and have little impact on any existing code. >> Basically all we'd need to do is add the ability to associate the >> setup/cleanup steps with a RESOURCE_LOCK label. >> >> It's still not clear to me whether the setup/cleanup tasks should be >> considered test cases themselves, but I can see benefits with taking that >> path. It would mean all we'd need is to be able to mark a test case as >> "this is a setup/cleanup step for RESOURCE_LOCK label XXX", maybe something >> like this: >> >> set_tests_properties(setup-foo PROPERTIES RESOURCE_SETUP foo) >> set_tests_properties(teardown-foo PROPERTIES RESOURCE_CLEANUP foo) >> >> If multiple setup/cleanup steps are defined for a particular resource, >> then dependencies between those test cases would determine their order and >> where there are no dependencies, the order would be undefined as is already >> the case for test cases. >> >> For the initial implementation at least, I think something like the >> SETUP_PER_TEST concept is more complexity than I'd want to tackle. Maybe it >> could be supported later, but in the first instance I think once per >> group/resource is already a significant win and worth focusing on at the >> start (see my motivation at the top of this email). >> >> >> >>> >>> > -the default for each test is "no s/t", which means it can't be run >>> with any >>> > of the above in parallel (especially for compatibillity)[1] >>> > -need a way to tell if a test doesn't care about those >>> >>> Making RESOURCE_LOCK a rwlock rather than a mutex might make sense here. >>> SETUP_STEP bits have a RESOURCE_LOCK_WRITE group_${group}, otherwise it >>> is RESOURCE_LOCK_READ group_${group}. >>> >> >> Not sure I follow what problem this solves and without a strong >> motivation, I'd be reluctant to add this sort of complexity to the existing >> RESOURCE_LOCK functionality. It's currently quite clean and easy to >> understand. If a test uses some resource, it specifies it in RESOURCE_LOCK. >> The proposal above to add setup/cleanup logic to a resource doesn't require >> differentiating readers and writers (but I'm happy to consider examples >> which do demonstrate the need). >> >> >>> >>> > 1) think of a database connector test: the test that will check what >>> happens >>> > if no DB is present will fail if the setup step "start DB" was run, >>> but not >>> > the teardown >>> >>> RESOURCE_LOCK on that group_${group} can fix that I think. >>> >> >> And this is indeed precisely the motivating situation that got me into >> this thread. We currently use the RESOURCE_LOCK to prevent concurrent >> access to a DB instance, with starting up a clean instance at the beginning >> and shutting it down again at the end of all tests being what I want to >> move into the proposed setup/cleanup tasks. The current functionality >> requires us to use both RESOURCE_LOCK and DEPENDS to specify the same thing >> and it doesn't cover the ctest --rerun-failed scenario. With the proposal >> above to use RESOURCE_SETUP and RESOURCE_CLEANUP test properties, this >> could create an implicit dependency on those setup/cleanup test cases just >> by using RESOURCE_LOCK on the test cases which use that resource (i.e. no >> need for the separate DEPENDS to be specified as it does now). >> >> >> -- >> Craig Scott >> Melbourne, Australia >> http://crascit.com >> > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 8 09:20:10 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 8 Sep 2016 09:20:10 -0400 Subject: [cmake-developers] CMake version to build CMake In-Reply-To: References: Message-ID: <1bed89e6-2cdf-3537-7e94-840ec39c91b4@kitware.com> On 09/07/2016 06:44 PM, Stephen Kelly wrote: > ALIAS targets were introduced in CMake 2.8.12 (released August 2013). > > What do you think of updating the requirement to that or higher? Fine with me. It really only matters on platforms where one cannot use the bootstrap script. Let's go to 3.0 so we have the option to use the bracket argument syntax. -Brad From craig.scott at crascit.com Thu Sep 8 10:15:17 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 8 Sep 2016 22:15:17 +0800 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: I should also point out that another reason for not implementing the "skipping tests if the setup fails logic" relates to the current behaviour of DEPENDS. At the moment, if test B depends on test A, test B still executes if test A fails. This is both useful and unexpected at the same time. It is unexpected because I'd initially have thought of DEPENDS as meaning I can't run test B if test A fails, after all, B depends on A which I'd interpret to mean if A fails, then something B requires isn't working. Conversely, this is also useful because until now, DEPENDS was the only way to get cleanup functionality to run after other tests, and if those other tests fail, we still want the cleanup to occur. Current behaviour of DEPENDS can't change because there would be too much out there in the wild relying on the existing behaviour. I'm wondering if there's merit in adding a DEPENDS_ON_SUCCESS test property or something similar which would implement the perhaps more intuitive behaviour of not running dependent tests when a dependee fails. If that was done, then implementing the "don't run fixture tests if any fixture setup fails" logic would be trivial. On Thu, Sep 8, 2016 at 6:08 PM, Craig Scott wrote: > Merge request implementing this feature is now up for review here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/88 > > I ended up going with FIXTURE_... test property names rather than > GROUP_... since it seemed more specific. I have not implemented the logic > for skipping regular tests if any of a fixture's setup tests fail as that > would require more change than I wanted to bite off for this initial > implementation. If it is really required, I guess it could be done, but my > primary concern first is not to introduce new bugs. ;) > > > > On Thu, Sep 1, 2016 at 9:17 AM, Craig Scott > wrote: > >> Actually, we can't really re-use the RESOURCE_LOCK for the proposed >> RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force >> all the tests using that resource to be serialised. So yes, a separate >> GROUP or something similar would seem to be needed. Let me amend my earlier >> proposal (which is an evolution of Ben's) to something like this: >> >> >> add_test(NAME setup-foo ...) >> set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo) >> >> add_test(NAME cleanup-foo ...) >> set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo) >> >> add_test(NAME use-foo ...) >> set_tests_properties(use-foo PROPERTIES GROUP foo) >> >> >> The logic would be as follows: >> >> - Any test cases with a GROUP_SETUP property for a group will be run >> before any test cases with GROUP or GROUP_CLEANUP for that same group. The >> order of these setup test cases can be controlled with the existing DEPENDS >> test property. >> - If any of the group's setup test cases fail, all other test cases >> for that group will be skipped. All cleanup test cases for the group >> probably should still be run though (it could be hard to try to work out >> which cleanup tests should run, so maybe conservatively just run all of >> them). >> - If all setup test cases passed, then run all test cases for that >> group. Regardless of the success or failure of these test cases, once they >> are all completed, run all the cleanup test cases associated with the group. >> - Ordering of cleanup test cases can again be controlled with the >> existing DEPENDS test property. >> >> What the above buys us is that CTest then knows definitively that if it >> is asked to run a test case from a particular group, it must also run the >> setup and cleanup test cases associated with that group, regardless of >> whether those setup/cleanup test cases are in the set of test cases CTest >> was originally asked to run. At the moment, CTest could theoretically do >> that for the setup steps based on DEPENDS functionality, but not the >> cleanup. The above proposal is very clear about the nature of the >> dependency and gives the symmetry of both setup and cleanup behaviour. >> >> I'm not tied to the terminology of "GROUP" for tying a set of test cases >> to their setup/cleanup tasks, so I'm happy to consider alternatives. I'm >> also wondering whether simply GROUP for a test property is too generic for >> the test cases that require the setup/cleanup (as opposed to the test cases >> that ARE the setup/cleanup). >> >> >> On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott >> wrote: >> >>> In my original thinking, I was of the view that if a setup/cleanup step >>> needed to be executed for each test rather than for the overall test run as >>> a whole, then perhaps the test itself should handle that rather than CMake. >>> The existing RESOURCE_LOCK functionality could then be used to prevent >>> multiple tests from running concurrently if they would interfere with each >>> other. Existing test frameworks like GoogleTest and Boost Test already have >>> good support for test fixtures which make doing this per-test setup/cleanup >>> easy. The problem I want to solve is where a group of tests share a common >>> (set of) setup/cleanup steps and CMake knows to run them when asked to run >>> any test cases that require them. The specific problem motivating this work >>> was running ctest --rerun-failed, where we need CMake to add in any >>> setup/cleanup steps required by any of the tests that will be rerun. With >>> that in mind, see further comments interspersed below. >>> >>> >>> On Fri, Aug 26, 2016 at 12:08 AM, Ben Boeckel >>> wrote: >>> >>>> On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote: >>>> > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott: >>>> > > So how would you want the feature to work? I'd suggest an initial >>>> set of >>>> > > requirements something like the following: >>>> > > >>>> > > - Need to support the ability to define multiple setup and/or >>>> tear down >>>> > > tasks. >>>> > > - It should be possible to specify dependencies between setup >>>> tasks and >>>> > > between tear down tasks. >>>> > > - Individual tests need to be able to indicate which setup >>>> and/or tear >>>> > > down tasks they require, similar to the way DEPENDS is used to >>>> specify >>>> > > dependencies between test cases. >>>> > > - When using ctest --rerun-failed, ctest should automatically >>>> invoke any >>>> > > setup or tear down tasks required by the test cases that will be >>>> re-run. >>>> > > - Setup or tear down tasks which reference executable targets >>>> should >>>> > > substitute the actual built executable just like how >>>> add_custom_command() >>>> > > does. >>>> > >>>> > -need a way to mark if 2 tests with the same setup/teardown can share >>>> those or >>>> > if they need to run for every of them >>>> >>>> Proposal: >>>> >>>> add_test(NAME setup-foo ...) >>>> set_tests_properties(setup-foo PROPERTIES >>>> SETUP_GROUP foo >>>> SETUP_STEP SETUP_PER_TEST) # Also SETUP_ONCE. >>>> add_test(NAME use-foo ...) >>>> set_tests_properties(use-foo PROPERTIES >>>> SETUP_GROUP foo) # implicit depends on all SETUP_GROUP foo / >>>> SETUP_STEP SETUP_* tests. >>>> add_test(NAME use-foo2 ...) >>>> set_tests_properties(use-foo2 PROPERTIES >>>> SETUP_GROUP foo) >>>> add_test(NAME teardown-foo2 ...) >>>> set_tests_properties(teardown-foo2 PROPERTIES >>>> SETUP_GROUP foo >>>> SETUP_STEP TEARDOWN) # implicit depends on all non-TEARDOWN steps >>>> >>>> Multiple setup/teardown steps could be done with DEPENDS between them. >>>> >>> >>> I like the idea of tests being associated with a group and the group >>> itself is where the setup/cleanup steps are attached/associated. That said, >>> it would seem that RESOURCE_LOCK already more or less satisfies this >>> concept. I'm wondering if we can't just somehow attach setup/cleanup steps >>> to the named resource instead. That would be a more seamless evolution of >>> the existing functionality and have little impact on any existing code. >>> Basically all we'd need to do is add the ability to associate the >>> setup/cleanup steps with a RESOURCE_LOCK label. >>> >>> It's still not clear to me whether the setup/cleanup tasks should be >>> considered test cases themselves, but I can see benefits with taking that >>> path. It would mean all we'd need is to be able to mark a test case as >>> "this is a setup/cleanup step for RESOURCE_LOCK label XXX", maybe something >>> like this: >>> >>> set_tests_properties(setup-foo PROPERTIES RESOURCE_SETUP foo) >>> set_tests_properties(teardown-foo PROPERTIES RESOURCE_CLEANUP foo) >>> >>> If multiple setup/cleanup steps are defined for a particular resource, >>> then dependencies between those test cases would determine their order and >>> where there are no dependencies, the order would be undefined as is already >>> the case for test cases. >>> >>> For the initial implementation at least, I think something like the >>> SETUP_PER_TEST concept is more complexity than I'd want to tackle. Maybe it >>> could be supported later, but in the first instance I think once per >>> group/resource is already a significant win and worth focusing on at the >>> start (see my motivation at the top of this email). >>> >>> >>> >>>> >>>> > -the default for each test is "no s/t", which means it can't be run >>>> with any >>>> > of the above in parallel (especially for compatibillity)[1] >>>> > -need a way to tell if a test doesn't care about those >>>> >>>> Making RESOURCE_LOCK a rwlock rather than a mutex might make sense here. >>>> SETUP_STEP bits have a RESOURCE_LOCK_WRITE group_${group}, otherwise it >>>> is RESOURCE_LOCK_READ group_${group}. >>>> >>> >>> Not sure I follow what problem this solves and without a strong >>> motivation, I'd be reluctant to add this sort of complexity to the existing >>> RESOURCE_LOCK functionality. It's currently quite clean and easy to >>> understand. If a test uses some resource, it specifies it in RESOURCE_LOCK. >>> The proposal above to add setup/cleanup logic to a resource doesn't require >>> differentiating readers and writers (but I'm happy to consider examples >>> which do demonstrate the need). >>> >>> >>>> >>>> > 1) think of a database connector test: the test that will check what >>>> happens >>>> > if no DB is present will fail if the setup step "start DB" was run, >>>> but not >>>> > the teardown >>>> >>>> RESOURCE_LOCK on that group_${group} can fix that I think. >>>> >>> >>> And this is indeed precisely the motivating situation that got me into >>> this thread. We currently use the RESOURCE_LOCK to prevent concurrent >>> access to a DB instance, with starting up a clean instance at the beginning >>> and shutting it down again at the end of all tests being what I want to >>> move into the proposed setup/cleanup tasks. The current functionality >>> requires us to use both RESOURCE_LOCK and DEPENDS to specify the same thing >>> and it doesn't cover the ctest --rerun-failed scenario. With the proposal >>> above to use RESOURCE_SETUP and RESOURCE_CLEANUP test properties, this >>> could create an implicit dependency on those setup/cleanup test cases just >>> by using RESOURCE_LOCK on the test cases which use that resource (i.e. no >>> need for the separate DEPENDS to be specified as it does now). >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> http://crascit.com >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> http://crascit.com >> > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 8 11:52:23 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 8 Sep 2016 11:52:23 -0400 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: On 09/08/2016 10:15 AM, Craig Scott wrote: > the current behaviour of DEPENDS. At the moment, if test B depends > on test A, test B still executes if test A fails. > It is unexpected because I'd initially have thought of DEPENDS as > meaning I can't run test B if test A fails, after all, B depends > on A which I'd interpret to mean if A fails, then something B requires > isn't working. Conversely, this is also useful because until now, > DEPENDS was the only way to get cleanup functionality to run after > other tests, and if those other tests fail, we still want the > cleanup to occur. At one time we only had serial testing so the order of tests was fully controllable and based on the order of addition. There were never any conditions for whether a test would run based on results of other tests. Then when parallel testing was added we need a way to restore *order* dependencies, so DEPENDS was added just for that. Maybe a better name would have been RUN_AFTER. > adding a DEPENDS_ON_SUCCESS test property or something similar > which would implement the perhaps more intuitive behaviour of not > running dependent tests when a dependee fails. If that was done, > then implementing the "don't run fixture tests if any fixture > setup fails" logic would be trivial. The semantics of this will have to be carefully though out, in particular with respect to enabling test dependencies. Right now ctest arguments like -E can exclude tests. What if those are dependencies of included tests? I think if we introduce the notion of tests requiring other tests then a new model of test selection and enablement needs to be designed. Some kind of test DAG could be defined with various roots and subgraphs being selectable an causing all reachable tests to be included. -Brad From steveire at gmail.com Thu Sep 8 14:17:51 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 08 Sep 2016 20:17:51 +0200 Subject: [cmake-developers] CMake version to build CMake References: <1bed89e6-2cdf-3537-7e94-840ec39c91b4@kitware.com> Message-ID: Brad King wrote: > On 09/07/2016 06:44 PM, Stephen Kelly wrote: >> ALIAS targets were introduced in CMake 2.8.12 (released August 2013). >> >> What do you think of updating the requirement to that or higher? > > Fine with me. It really only matters on platforms where one cannot use > the bootstrap script. Let's go to 3.0 so we have the option to use the > bracket argument syntax. Are there dashboard machines which need to be updated first? Thanks, Steve. From brad.king at kitware.com Thu Sep 8 15:17:29 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 8 Sep 2016 15:17:29 -0400 Subject: [cmake-developers] CMake version to build CMake In-Reply-To: References: <1bed89e6-2cdf-3537-7e94-840ec39c91b4@kitware.com> Message-ID: <040ed18d-99be-0ca1-00ed-9fc298ac7d50@kitware.com> On 09/08/2016 02:17 PM, Stephen Kelly wrote: > Are there dashboard machines which need to be updated first? Oops, right. I see a bunch that are still on 2.8.12. There are only a few older than that (2.8.7, 2.8.9, 2.8.11). I'll try to get those updated soon and report back. Then we can move to 2.8.12 for now. Thanks, -Brad From rleigh at codelibre.net Thu Sep 8 17:03:11 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 8 Sep 2016 21:03:11 +0000 Subject: [cmake-developers] [patch] BZip2 imported targets Message-ID: <9aabc2a9-1248-2e00-8aeb-4375b393cf80@codelibre.net> Adds BZip2::BZip2 imported target and documentation, along with unit test which may be enabled with the CMake_TEST_FindBZip2 option. Derived from the existing code in FindZLib. Branch: bzip2-imported-targets Merged into stage for testing. Regards, Roger From rleigh at codelibre.net Thu Sep 8 17:06:40 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 8 Sep 2016 21:06:40 +0000 Subject: [cmake-developers] [patch] FreeBSD build fix Message-ID: <58674657-12f5-f73e-c622-0710098b3017@codelibre.net> With FreeBSD 11, I was getting a link failure due to missing kvm symbols in Utilities/cmlibuv. The fix is a trivial addition. It's added unconditionally; I checked for its presence in FreeBSD 11, 10 and 9. Branch: freebsd-kvm-link Merged into stage for testing. Regards, Roger From daniel at pfeifer-mail.de Thu Sep 8 17:14:19 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 8 Sep 2016 23:14:19 +0200 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: On Thu, Sep 8, 2016 at 5:52 PM, Brad King wrote: > On 09/08/2016 10:15 AM, Craig Scott wrote: >> the current behaviour of DEPENDS. At the moment, if test B depends >> on test A, test B still executes if test A fails. >> It is unexpected because I'd initially have thought of DEPENDS as >> meaning I can't run test B if test A fails, after all, B depends >> on A which I'd interpret to mean if A fails, then something B requires >> isn't working. Conversely, this is also useful because until now, >> DEPENDS was the only way to get cleanup functionality to run after >> other tests, and if those other tests fail, we still want the >> cleanup to occur. > > At one time we only had serial testing so the order of tests was > fully controllable and based on the order of addition. There were > never any conditions for whether a test would run based on results > of other tests. Then when parallel testing was added we need a > way to restore *order* dependencies, so DEPENDS was added just > for that. Maybe a better name would have been RUN_AFTER. > >> adding a DEPENDS_ON_SUCCESS test property or something similar >> which would implement the perhaps more intuitive behaviour of not >> running dependent tests when a dependee fails. If that was done, >> then implementing the "don't run fixture tests if any fixture >> setup fails" logic would be trivial. > > The semantics of this will have to be carefully though out, in > particular with respect to enabling test dependencies. Right now > ctest arguments like -E can exclude tests. What if those are > dependencies of included tests? > > I think if we introduce the notion of tests requiring other tests > then a new model of test selection and enablement needs to be > designed. Some kind of test DAG could be defined with various > roots and subgraphs being selectable an causing all reachable > tests to be included. This could be expanded even further. If "tests requiring other tests" is generalized to "tests requiring X", wouldn't this allow incremental testing? Say you change one file in your project. You rebuild only the parts of the project that are affected by this change. Then you rerun only the tests that are affected by the change. This really has to be carefully thought out. Cheers, Daniel From nilsgladitz at gmail.com Fri Sep 9 02:32:48 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 9 Sep 2016 08:32:48 +0200 Subject: [cmake-developers] [Patch 5/5] Improved WIX support In-Reply-To: <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> References: <95f264e5-ea18-ac48-6974-86b8ce167e95@gmail.com> <7d2346e2cd9e44ed8698e81f93e90390@DE013666.schaeffler.com> <18345fa8-15c5-eed7-1353-b8b2f9ccf5ab@gmail.com> <8b081282e1d743a6a7c0a0723417e399@DE013666.schaeffler.com> <81f17829-dcea-fa00-ac39-3942d4fc3384@gmail.com> <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> Message-ID: <1d03152f-88ef-d3ff-8526-50bea4d79de2@gmail.com> On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > Here it is. > The patch only seems to allow patching Features generated for components but not Features generated for component groups. Is that intentional or an oversight? I think we should allow patching for both. Nils From michael.stuermer at schaeffler.com Fri Sep 9 04:54:58 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Fri, 9 Sep 2016 08:54:58 +0000 Subject: [cmake-developers] [Patch 5/5] Improved WIX support In-Reply-To: <1d03152f-88ef-d3ff-8526-50bea4d79de2@gmail.com> References: <95f264e5-ea18-ac48-6974-86b8ce167e95@gmail.com> <7d2346e2cd9e44ed8698e81f93e90390@DE013666.schaeffler.com> <18345fa8-15c5-eed7-1353-b8b2f9ccf5ab@gmail.com> <8b081282e1d743a6a7c0a0723417e399@DE013666.schaeffler.com> <81f17829-dcea-fa00-ac39-3942d4fc3384@gmail.com> <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> <1d03152f-88ef-d3ff-8526-50bea4d79de2@gmail.com> Message-ID: > -----Original Message----- > From: Nils Gladitz [mailto:nilsgladitz at gmail.com] > Sent: Friday, September 09, 2016 8:33 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Here it is. > > > > The patch only seems to allow patching Features generated for components > but not Features generated for component groups. > Is that intentional or an oversight? > > I think we should allow patching for both. > > Nils > The details you miss if you are not using the features ... thanks for the hint, here is corrected patch. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-enabled-patching-of-WIX-Feature-tags.patch Type: application/octet-stream Size: 4182 bytes Desc: 0001-enabled-patching-of-WIX-Feature-tags.patch URL: From nilsgladitz at gmail.com Fri Sep 9 07:06:01 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 9 Sep 2016 13:06:01 +0200 Subject: [cmake-developers] [Patch 5/5] Improved WIX support In-Reply-To: References: <95f264e5-ea18-ac48-6974-86b8ce167e95@gmail.com> <7d2346e2cd9e44ed8698e81f93e90390@DE013666.schaeffler.com> <18345fa8-15c5-eed7-1353-b8b2f9ccf5ab@gmail.com> <8b081282e1d743a6a7c0a0723417e399@DE013666.schaeffler.com> <81f17829-dcea-fa00-ac39-3942d4fc3384@gmail.com> <54b3581f48824d45b08a1ff36707ee15@DE013666.schaeffler.com> <1d03152f-88ef-d3ff-8526-50bea4d79de2@gmail.com> Message-ID: On 09/09/2016 10:54 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > The details you miss if you are not using the features ... thanks for the hint, here is corrected patch. > > Michael Thanks. I merged to "next" with small changes. Nils From brad.king at kitware.com Fri Sep 9 11:13:48 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 9 Sep 2016 11:13:48 -0400 Subject: [cmake-developers] [patch] FreeBSD build fix In-Reply-To: <58674657-12f5-f73e-c622-0710098b3017@codelibre.net> References: <58674657-12f5-f73e-c622-0710098b3017@codelibre.net> Message-ID: On 09/08/2016 05:06 PM, Roger Leigh wrote: > With FreeBSD 11, I was getting a link failure due to missing kvm symbols > in Utilities/cmlibuv. > > The fix is a trivial addition. It's added unconditionally; I checked > for its presence in FreeBSD 11, 10 and 9. Branch: freebsd-kvm-link Thanks. It looks like kvm is also used on NetBSD and OpenBSD so I extended the topic to include a change for those and renamed it to `libuv-link-kvm`. We'll see how that goes on nightly testing. -Brad From brad.king at kitware.com Fri Sep 9 11:44:53 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 9 Sep 2016 11:44:53 -0400 Subject: [cmake-developers] [patch] BZip2 imported targets In-Reply-To: <9aabc2a9-1248-2e00-8aeb-4375b393cf80@codelibre.net> References: <9aabc2a9-1248-2e00-8aeb-4375b393cf80@codelibre.net> Message-ID: <156ef669-add7-c104-dfdd-cd968c7533f2@kitware.com> On 09/08/2016 05:03 PM, Roger Leigh wrote: > Adds BZip2::BZip2 imported target and documentation, along with unit > test which may be enabled with the CMake_TEST_FindBZip2 option. Derived > from the existing code in FindZLib. Looks good, thanks. I revised the topic with some minor tweaks. I've enabled the new test on one of the nightly builders. Once clean I'll merge to `master`. Thanks, -Brad From rcdailey.lists at gmail.com Fri Sep 9 16:04:33 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 9 Sep 2016 15:04:33 -0500 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: Currently nightly builds are tagged 3.6.2. Are there no nightly builds for 3.7 or am I missing something? On Fri, Aug 12, 2016 at 10:26 AM, Robert Goulet wrote: > That's super awesome Brad! > > Looking forward to try this out! > > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King > Sent: Friday, August 12, 2016 11:13 AM > To: cmake-developers at cmake.org > Subject: [cmake-developers] Android Support > > Hi Folks, > > I've implemented native support for cross-compiling to Android with CMake using either an Android NDK or an Android Standalone Toolchain. > I plan to include this in the CMake 3.7 release. > > Please see the MR here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/62 > > This enables building with simple toolchain files, or even without one: > > $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk > > Note that interface compatibility with popular third-party Android toolchain files is a non-goal of this work (though we should not break them too much). > Instead I'd like to make the support feel native within CMake. For example, the Android API level is naturally specified by CMAKE_SYSTEM_VERSION. > > If you're interested in this support please fetch the MR branch and try it out. The Help/manual/cmake-toolchains.7.rst manual has been updated with documentation about how to use this. > > -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 From craig.scott at crascit.com Sat Sep 10 11:34:36 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 10 Sep 2016 23:34:36 +0800 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: On Thu, Sep 8, 2016 at 11:52 PM, Brad King wrote: > On 09/08/2016 10:15 AM, Craig Scott wrote: > > adding a DEPENDS_ON_SUCCESS test property or something similar > > which would implement the perhaps more intuitive behaviour of not > > running dependent tests when a dependee fails. If that was done, > > then implementing the "don't run fixture tests if any fixture > > setup fails" logic would be trivial. > > The semantics of this will have to be carefully though out, in > particular with respect to enabling test dependencies. Right now > ctest arguments like -E can exclude tests. What if those are > dependencies of included tests? > > I think if we introduce the notion of tests requiring other tests > then a new model of test selection and enablement needs to be > designed. Some kind of test DAG could be defined with various > roots and subgraphs being selectable an causing all reachable > tests to be included. > While I can see potential merit, I'd be reluctant to go so far as adding the complexity of a test DAG. One of the attractive things about the current functionality is its simplicity. It's relatively easy for new developers to learn how to use it and I'm keen to preserve that as much as possible, since it helps with adoption of CTest and CMake in general. Indeed, in the more general case, if we added a DEPENDS_ON_SUCCESS test property then we would have to work through how to handle situations where dependee tests were not in the initial test set to be executed. I think this might be less clear cut than I initially thought, so I'm tending to back away from this as a general feature now. For the case of test fixtures though, the semantics are very clear and would be well defined, since one of the primary purposes of fixtures is to bring in setup and cleanup tests which might not have been part of the initial test set. If no-one objects, I'll have a crack at adding the required functionality to my fixtures branch so that regular tests are skipped if setup tests fail (i.e. as per the latest set of requirements that were proposed on this list a few days ago) and I'll do so without adding a new DEPENDS_ON_SUCCESS test property. That will limit the new functionality just to fixtures where the required behaviour is well defined. -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Sep 10 11:58:56 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 10 Sep 2016 23:58:56 +0800 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: On Fri, Sep 9, 2016 at 5:14 AM, Daniel Pfeifer wrote: > On Thu, Sep 8, 2016 at 5:52 PM, Brad King wrote: > > I think if we introduce the notion of tests requiring other tests > > then a new model of test selection and enablement needs to be > > designed. Some kind of test DAG could be defined with various > > roots and subgraphs being selectable an causing all reachable > > tests to be included. > > This could be expanded even further. If "tests requiring other tests" > is generalized to "tests requiring X", wouldn't this allow incremental > testing? Say you change one file in your project. You rebuild only > the parts of the project that are affected by this change. Then you > rerun only the tests that are affected by the change. This really has > to be carefully thought out. > Interesting idea, but yes potentially a big body of work. That said, the fixtures implementation up for review already gets you most of the way there I think. One could potentially define a fixture that covers the tests for functionality a developer is working on. A test is able to require multiple fixtures, so developers could define fixtures to whatever granularity they wanted. We could add option(s) to the ctest command line which allow selection of tests based on fixture names in the same way we currently do with labels and test names. This would allow developers to run just the set of tests related to a particular functionality. One could argue that labels already get you most of the way there now too, but since fixtures would come with clean handing of setup/cleanup dependencies, they may be more useful to developers. They also feel a bit closer to the implementation than what labels are likely to cover and so fixtures might be a better fit for the scenario you mentioned. I'd also be skeptical whether we could make it easy/convenient/robust for CMake to work out which tests to re-run based on which files had to be rebuilt. Asking developers to pick which fixture(s) to retest instead might be a good compromise due to the simplicity of both use and implementation. Even aside from whether the above would satisfy the proposed scenario, maybe it's worth considering adding test selection based on fixture names regardless. I think this probably should be a separate branch that follows from the current one though so it doesn't turn into a monster of a merge. ;) I'd be happy to look at that idea once the current branch is done and in, since I have a concrete use case driving me to get that one completed first. -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.roth at fastprotect.net Mon Sep 12 07:22:58 2016 From: andreas.roth at fastprotect.net (Andreas Roth) Date: Mon, 12 Sep 2016 11:22:58 +0000 Subject: [cmake-developers] Native C# support in CMake Message-ID: Hi, i was wondering if you plan to support C# as language. Currently we are using a custom tailored set of command lines for building but it becomes more and more difficult when complexer requirements surface. Regards, Andreas Roth Development Engineer FAST Protect GmbH Siemensstrasse 16/1 88048 Friedrichshafen Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Sep 12 09:09:27 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Sep 2016 09:09:27 -0400 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: On 09/09/2016 04:04 PM, Robert Dailey wrote: > Currently nightly builds are tagged 3.6.2. Are there no nightly builds > for 3.7 or am I missing something? They are 3.6.2.$date, indicating post-3.6 feature development. See the documentation of CMAKE_VERSION: https://cmake.org/cmake/help/v3.6/variable/CMAKE_VERSION.html -Brad From brad.king at kitware.com Mon Sep 12 09:09:36 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Sep 2016 09:09:36 -0400 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> Message-ID: <64dd7c87-680c-bfbd-5eac-a0e3985b7335@kitware.com> On 09/10/2016 11:34 AM, Craig Scott wrote: > have a crack at adding the required functionality to my fixtures branch > so that regular tests are skipped if setup tests fail [snip] > limit the new functionality just to fixtures where the required > behaviour is well defined. Sounds good to me. Please re-open and extend the associated MR when ready. Thanks, -Brad From brad.king at kitware.com Mon Sep 12 09:10:41 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Sep 2016 09:10:41 -0400 Subject: [cmake-developers] Native C# support in CMake In-Reply-To: References: Message-ID: On 09/12/2016 07:22 AM, Andreas Roth wrote: > i was wondering if you plan to support C# as language. No one upstream is working on this but there has been some progress by others. One should be able to find discussion in the list archives. -Brad From brad.king at kitware.com Mon Sep 12 09:10:49 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Sep 2016 09:10:49 -0400 Subject: [cmake-developers] CMake version to build CMake In-Reply-To: <040ed18d-99be-0ca1-00ed-9fc298ac7d50@kitware.com> References: <1bed89e6-2cdf-3537-7e94-840ec39c91b4@kitware.com> <040ed18d-99be-0ca1-00ed-9fc298ac7d50@kitware.com> Message-ID: <6fdee86d-1d76-e28c-7856-5296528e1316@kitware.com> On 09/08/2016 03:17 PM, Brad King wrote: > There are only a few older than that (2.8.7, 2.8.9, 2.8.11). > I'll try to get those updated soon and report back. Then we > can move to 2.8.12 for now. Done. I temporarily added a CMake-time warning for submissions using lower than 2.8.12.2 and got the rest of them converted. -Brad From brad.king at kitware.com Mon Sep 12 09:10:57 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 12 Sep 2016 09:10:57 -0400 Subject: [cmake-developers] CMake 3.7 feature freeze on 2016-10-03 Message-ID: <69df6fcf-a372-a99b-ef07-bfbe05c0d0b8@kitware.com> Hi Folks, The feature freeze in 'master' for CMake 3.7 will be on Oct 3, 2016. I may announce a freeze in 'next' sometime in the preceding week so that we can get any remaining dashboard trouble cleaned up. Thanks, -Brad From michael.stuermer at schaeffler.com Mon Sep 12 11:57:48 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Mon, 12 Sep 2016 15:57:48 +0000 Subject: [cmake-developers] Native C# support in CMake In-Reply-To: References: Message-ID: Hi, check this out, might help: https://github.com/micst/CMake.git There is a working C# implementation available. I permanently try to keep it up-to-date with master and mergable so the workload will not become too large as soon as I find time to prepare patches for upstream. Contribution (especially about finding C# compilers and .NET frameworks and setting necessary variables) is always welcome. Search the mailing list about status and open issues, there?s still quite something to do... best regards, Michael From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Andreas Roth Sent: Monday, September 12, 2016 1:23 PM To: cmake-developers at cmake.org Subject: [cmake-developers] Native C# support in CMake Hi, i was wondering if you plan to support C# as language. Currently we are using a custom tailored set of command lines for building but it becomes more and more difficult when complexer requirements surface. Regards, Andreas Roth Development Engineer FAST Protect GmbH Siemensstrasse 16/1 88048 Friedrichshafen Germany . -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikedld at mikedld.com Tue Sep 13 04:10:54 2016 From: mikedld at mikedld.com (Mike Gelfand) Date: Tue, 13 Sep 2016 11:10:54 +0300 Subject: [cmake-developers] Fixing up arbitrary Mac OS bundles Message-ID: <0a63b595a979a7b8d40b8868cc3194db.squirrel@mail.mikedld.com> Hello, I'm trying to fixup an embedded bundle which is a QuickLook plugin. The bundle has .qtgenerator extension and should be located in .app/Contents/Library/QuickLook/.qtgenerator. This doesn't work right away. I've tried: 1. fixup_bundle(".app/Contents/Library/QuickLook/.qtgenerator" "" "") This fails with warning "*NOT* handled - directory but not .app case..." and error "fixup_bundle: not a valid bundle" 2. fixup_bundle(".app/Contents/Library/QuickLook/.qtgenerator/Contents/MacOS/" "" "") This fails with warning "*NOT* handled - not .app dir, not executable file..." and error "fixup_bundle: not a valid bundle" Note that `file` reports "Mach-O 64-bit bundle x86_64" for bundle executable file. 3. change bundle .qlgenerator suffix to .app (temporarily for fixup), then fixup_bundle(".app/Contents/Library/QuickLook/.app" "" "") This succeeds with warnings "unexpected reference to '.dylib'" for each library which needs to be copied into the bundle, but no libraries are actually copied and no changes to bundle executable are made. 4. adding bundle to libs parameter when fixing up parent bundle (even though app executable doesn't in fact depend on the bundle), fixup_bundle(".app" ".app/Contents/Library/QuickLook/.qtgenerator/Contents/MacOS/" "") This succeeds without warnings, but no changes to bundle executable are made. So the question is, is it at all possible to do what I want to do with current CMake version? If not, maybe someone's working on this? If not, do you have any suggestions on how one would go about implementing support for this (I might give it a try if/when time permits)? Regards, Mike From ruslan_baratov at yahoo.com Tue Sep 13 07:42:52 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 13 Sep 2016 14:42:52 +0300 Subject: [cmake-developers] Downloading file from S3 private bucket Message-ID: Hi, Currently I'm investigating possibilities of downloading files from private S3 bucket using CMake. The only real issue I see for now is the computing of HMAC + SHA1. This look like a work for some new cryptographic module in family of 'string' functions similar to 'string(MD5|SHA1|...)'. So if we are talking about new command 'string(HMAC SHA1)' what will be the right path to implement it? I took a brief look at hashing functions and it seems that it was not using OpenSSL (what I was thinking before). Will it be okay if CMake will optionally depend on OpenSSL? Or other third party crypto library? Also I know that it's possible to use Query String Request Authentication. It means I can create URL with key and signature in query part first, then put it into file(DOWNLOAD) command. However HMAC + SHA1 in CMake itself offer more opportunities and sounds more solid for me. Thoughts? Ruslo From brad.king at kitware.com Tue Sep 13 08:58:25 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 13 Sep 2016 08:58:25 -0400 Subject: [cmake-developers] Downloading file from S3 private bucket In-Reply-To: References: Message-ID: <7547435f-e09c-0bff-dfa9-6bf796abdd58@kitware.com> On 09/13/2016 07:42 AM, Ruslan Baratov via cmake-developers wrote: > Will it be okay if CMake will optionally depend on OpenSSL? > Or other third party crypto library? Currently the only place that needs it is through `curl`, and that uses either OpenSSL or the Windows-native or macOS-native APIs for TLS. It looks like curl does support HMAC. -Brad From ruslan_baratov at yahoo.com Tue Sep 13 09:28:21 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 13 Sep 2016 16:28:21 +0300 Subject: [cmake-developers] Downloading file from S3 private bucket In-Reply-To: <7547435f-e09c-0bff-dfa9-6bf796abdd58@kitware.com> References: <7547435f-e09c-0bff-dfa9-6bf796abdd58@kitware.com> Message-ID: On 13-Sep-16 15:58, Brad King wrote: > On 09/13/2016 07:42 AM, Ruslan Baratov via cmake-developers wrote: >> Will it be okay if CMake will optionally depend on OpenSSL? >> Or other third party crypto library? > Currently the only place that needs it is through `curl`, and > that uses either OpenSSL or the Windows-native or macOS-native > APIs for TLS. So your suggestion is to extend 'file' command? Like `file(DOWNLOAD|UPLOAD S3_KEY S3_SECRET )`? > It looks like curl does support HMAC. > I don't know, will take a look. We need this functionality: echo -n "${stringToSign}" | openssl sha1 -hmac "${secret}" -binary | base64 Ruslo From yan12125 at gmail.com Wed Sep 14 08:54:07 2016 From: yan12125 at gmail.com (Yen Chi Hsuan) Date: Wed, 14 Sep 2016 20:54:07 +0800 Subject: [cmake-developers] [PATCH] FindPython{Interp, Libs}: Add versions 3.7 Message-ID: <20160914125407.14592-1-yan12125@gmail.com> --- Modules/FindPythonInterp.cmake | 2 +- Modules/FindPythonLibs.cmake | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Modules/FindPythonInterp.cmake b/Modules/FindPythonInterp.cmake index e194185..4d726f2 100644 --- a/Modules/FindPythonInterp.cmake +++ b/Modules/FindPythonInterp.cmake @@ -52,7 +52,7 @@ unset(_Python_NAMES) set(_PYTHON1_VERSIONS 1.6 1.5) set(_PYTHON2_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0) -set(_PYTHON3_VERSIONS 3.6 3.5 3.4 3.3 3.2 3.1 3.0) +set(_PYTHON3_VERSIONS 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0) if(PythonInterp_FIND_VERSION) if(PythonInterp_FIND_VERSION_COUNT GREATER 1) diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake index ab92f86..d9916a1 100644 --- a/Modules/FindPythonLibs.cmake +++ b/Modules/FindPythonLibs.cmake @@ -84,7 +84,7 @@ set(CMAKE_FIND_FRAMEWORK LAST) set(_PYTHON1_VERSIONS 1.6 1.5) set(_PYTHON2_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0) -set(_PYTHON3_VERSIONS 3.6 3.5 3.4 3.3 3.2 3.1 3.0) +set(_PYTHON3_VERSIONS 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0) if(PythonLibs_FIND_VERSION) if(PythonLibs_FIND_VERSION_COUNT GREATER 1) -- 2.9.3 From yan12125 at gmail.com Wed Sep 14 09:05:14 2016 From: yan12125 at gmail.com (Chi Hsuan Yen) Date: Wed, 14 Sep 2016 21:05:14 +0800 Subject: [cmake-developers] [PATCH] FindPython{Interp, Libs}: Add versions 3.7 In-Reply-To: <20160914125407.14592-1-yan12125@gmail.com> References: <20160914125407.14592-1-yan12125@gmail.com> Message-ID: On Wed, Sep 14, 2016 at 8:54 PM, Yen Chi Hsuan wrote: > --- > Modules/FindPythonInterp.cmake | 2 +- > Modules/FindPythonLibs.cmake | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Modules/FindPythonInterp.cmake b/Modules/FindPythonInterp. > cmake > index e194185..4d726f2 100644 > --- a/Modules/FindPythonInterp.cmake > +++ b/Modules/FindPythonInterp.cmake > @@ -52,7 +52,7 @@ unset(_Python_NAMES) > > set(_PYTHON1_VERSIONS 1.6 1.5) > set(_PYTHON2_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0) > -set(_PYTHON3_VERSIONS 3.6 3.5 3.4 3.3 3.2 3.1 3.0) > +set(_PYTHON3_VERSIONS 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0) > > if(PythonInterp_FIND_VERSION) > if(PythonInterp_FIND_VERSION_COUNT GREATER 1) > diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake > index ab92f86..d9916a1 100644 > --- a/Modules/FindPythonLibs.cmake > +++ b/Modules/FindPythonLibs.cmake > @@ -84,7 +84,7 @@ set(CMAKE_FIND_FRAMEWORK LAST) > > set(_PYTHON1_VERSIONS 1.6 1.5) > set(_PYTHON2_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0) > -set(_PYTHON3_VERSIONS 3.6 3.5 3.4 3.3 3.2 3.1 3.0) > +set(_PYTHON3_VERSIONS 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0) > > if(PythonLibs_FIND_VERSION) > if(PythonLibs_FIND_VERSION_COUNT GREATER 1) > -- > 2.9.3 > > Hi all, I use `git send-email -1` to send the previous email. Is it correct? Or I should attach the patch manually in a new email instead? Thanks. Regards, Yen Chi Hsuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 14 09:14:32 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 14 Sep 2016 09:14:32 -0400 Subject: [cmake-developers] [PATCH] FindPython{Interp, Libs}: Add versions 3.7 In-Reply-To: References: <20160914125407.14592-1-yan12125@gmail.com> Message-ID: <7b961549-1d57-9a36-7b91-db0e8e06d3fe@kitware.com> On 09/14/2016 09:05 AM, Chi Hsuan Yen wrote: > I use `git send-email -1` to send the previous email. Is it correct? > Or I should attach the patch manually in a new email instead? Thanks. Either is fine. I've applied the patch: FindPython{Interp,Libs}: Add version 3.7 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c31573b9 Thanks, -Brad From yan12125 at gmail.com Wed Sep 14 09:17:46 2016 From: yan12125 at gmail.com (Chi Hsuan Yen) Date: Wed, 14 Sep 2016 21:17:46 +0800 Subject: [cmake-developers] [PATCH] FindPython{Interp, Libs}: Add versions 3.7 In-Reply-To: <7b961549-1d57-9a36-7b91-db0e8e06d3fe@kitware.com> References: <20160914125407.14592-1-yan12125@gmail.com> <7b961549-1d57-9a36-7b91-db0e8e06d3fe@kitware.com> Message-ID: On Wed, Sep 14, 2016 at 9:14 PM, Brad King wrote: > On 09/14/2016 09:05 AM, Chi Hsuan Yen wrote: > > I use `git send-email -1` to send the previous email. Is it correct? > > Or I should attach the patch manually in a new email instead? Thanks. > > Either is fine. I've applied the patch: > > FindPython{Interp,Libs}: Add version 3.7 > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c31573b9 > > Thanks, > -Brad > > Oh that's astonishingly fast! Thanks. Yen Chi Hsuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Wed Sep 14 10:10:02 2016 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Wed, 14 Sep 2016 16:10:02 +0200 Subject: [cmake-developers] Debug through config/gen inside Visual Studio Message-ID: Hi everyone! I wanted to see how CMake actually Works under the covers to see how much actual work it would take to implement a feature I proposed quite a while ago. My problem is that even though I built CMake with the ?Visual Studio 14 2015 Win64? generator, I setup the cmake target to use: Command Arguments: -G "NMake Makefiles" C:\Users\Matty\OneDrive\Develop\Tests\CMake\CMake_example Working Directory: C:\Users\Matty\Build\CMake_Example\NMake There is even an option to create new environtment variables prior to debugging. My problem is that even though I checked what vcvarsall.bat creates on the command line, I exported the same variables, but the compiler fails according to CMake (see at the end). How do you setup Visual Studio to debug through a config/gen process? Thanks in advance, M?t? -- The C compiler identification is MSVC 19.0.24213.1 -- The CXX compiler identification is MSVC 19.0.24213.1 -- Check for working C compiler: C:/Kellekek/Microsoft/Visual Studio/14.0/VC/bin/amd64/cl.exe -- Check for working C compiler: C:/Kellekek/Microsoft/Visual Studio/14.0/VC/bin/amd64/cl.exe -- broken CMake Error at C:/Users/Matty/Source/Repos/CMake/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/Kellekek/Microsoft/Visual Studio/14.0/VC/bin/amd64/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTC_064d4\fast" "C:\Kellekek\Microsoft\Visual Studio\14.0\VC\bin\amd64\nmake.exe" -f CMakeFiles\cmTC_064d4.dir\build.make /nologo -L CMakeFiles\cmTC_064d4.dir\build Building C object CMakeFiles/cmTC_064d4.dir/testCCompiler.c.obj C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\cl.exe @C:\Users\Matty\AppData\Local\Temp\nmBF98.tmp testCCompiler.c Linking C executable cmTC_064d4.exe C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_064d4.dir --manifests -- C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\cmTC_064d4.dir\objects1.rsp @C:\Users\Matty\AppData\Local\Temp\nmC1FA.tmp RC Pass 1 failed to run. NMAKE : fatal error U1077: 'C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe' : return code '0xffffffff' Stop. NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft\Visual Studio\14.0\VC\bin\amd64\nmake.exe"' : return code '0x2' Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:5 (project) -- Configuring incomplete, errors occurred! See also "C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeOutput.log". See also "C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeError.log". Press any key to continue . . . -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Wed Sep 14 10:17:09 2016 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Wed, 14 Sep 2016 16:17:09 +0200 Subject: [cmake-developers] Debug through config/gen inside Visual Studio Message-ID: Apologies, there is one important moment I failed mention. If I do not set any env vars for the debugger, cmake still finds cl.exe with the ?NMake Makefiles? generator, which clearly states that it is not a clean user environment I get inside the debugger. Felad?: csiga.biga at aol.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Sep 14 10:40:30 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 15 Sep 2016 00:40:30 +1000 Subject: [cmake-developers] [CMake] Setup/tear down steps for CTest In-Reply-To: <64dd7c87-680c-bfbd-5eac-a0e3985b7335@kitware.com> References: <2790033.ITbBjc0OBD@caliban.sf-tec.de> <20160825140810.GA13534@megas.kitware.com> <64dd7c87-680c-bfbd-5eac-a0e3985b7335@kitware.com> Message-ID: I've implemented the change to not run regular tests if they require a fixture with a setup test that fails. The merge request has been reopened and updated. Hopefully this can go through before the feature freeze for 3.7. ;) On Mon, Sep 12, 2016 at 11:09 PM, Brad King wrote: > On 09/10/2016 11:34 AM, Craig Scott wrote: > > have a crack at adding the required functionality to my fixtures branch > > so that regular tests are skipped if setup tests fail > [snip] > > limit the new functionality just to fixtures where the required > > behaviour is well defined. > > Sounds good to me. Please re-open and extend the associated MR when > ready. > > Thanks, > -Brad > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.frederix+cmake at gmail.com Wed Sep 14 11:25:52 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Wed, 14 Sep 2016 17:25:52 +0200 Subject: [cmake-developers] Automatic project generation with Visual Studio generators Message-ID: Hi all, At work we recently switched from source globbing to explicit source listing, which should in theory remove the need for manually having to run CMake. It turns out, however, that for Visual Studio generators, this is not really the case. As far as I understand, the logic behind automatic project regeneration is controlled by the ZERO_CHECK target on which all other targets depend and which reruns CMake when necessary. However, this reconfiguration is triggered from inside a running msbuild, which then in turn is not stopped or restarted and does not pick up the updated project files, causing the running build to be out-of-date. This is known behavior, see, e.g., http://cmake.3232098.n2.nabble.com/MSBuild-and-automatic-project-file-regenation-td7166716.html and arguably a problem with msbuild rather than with CMake. There are currently two use cases in which one runs into problems: - When using "cmake --build . ". - When building from the VS IDE. I would like to propose a small change that would at least improve things already for the first use case. The idea is to change the actual (native) build command (which builds a single target) and replace it by sequentially running two almost identical msbuild commands: first targeting ZERO_CHECK and then targeting whatever target the user requested, picking up any changes to the project files. I am attaching a patch to illustrate what this could look like. If there is interest in this patch, I will gladly clean it up a bit. Thanks. Regards, Yves -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-When-building-using-cmake-build-which-natively-uses-.patch Type: application/octet-stream Size: 9286 bytes Desc: not available URL: From ysblokje at gmail.com Thu Sep 15 03:24:19 2016 From: ysblokje at gmail.com (Minze Zwerver) Date: Thu, 15 Sep 2016 09:24:19 +0200 Subject: [cmake-developers] CodeLite generator enhancement(s) Message-ID: Hi, I've been a been a cmake user for many years now and for the last year or so I've mostly been using the codelite generator. There are 2 "enhancements" I've made on my personal github clone which I like to give back to you guys. 1) There's a setting in cmake to change the final output folder for binaries/libraries and I added a few lines to the generator to take that into account. 2) I've made a copy of the codelite generator, called codelite2 for lack of a better name, and changed the subproject behaviour to use targets instead of projects for .project files. This makes sure that all targets show up in the codelite IDE. (the result looks a lot like what you see in VisualStudio projects) I could merge the codelite enhancements into the original codelite generator, but I would need a setting to control if the generated project should be geared towards targets or projects. Would something like -DCMAKE_CODELITE_USE_TARGETS=ON be an acceptable way, if not, how should one influence the generator ? Regards, Minze -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 15 08:07:42 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Sep 2016 08:07:42 -0400 Subject: [cmake-developers] Automatic project generation with Visual Studio generators In-Reply-To: References: Message-ID: <2b8ca07b-5e2c-f03b-26a7-04b9b4d588a3@kitware.com> On 09/14/2016 11:25 AM, Yves Frederix wrote: > replace it by sequentially running two almost identical msbuild > commands: first targeting ZERO_CHECK and then targeting whatever > target the user requested, picking up any changes to the project > files. For `cmake --build` we already need to detect the generator used for the build tree in order to ask it to construct the appropriate command line. For the VS generator we could directly run the same check that ZERO_CHECK would run in order to decide whether to regen the build files first. That would avoid going through msbuild for this step altogether. -Brad From brad.king at kitware.com Thu Sep 15 08:07:52 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Sep 2016 08:07:52 -0400 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: <20160914141530.908C3E5D43@public.kitware.com> References: <20160914141530.908C3E5D43@public.kitware.com> Message-ID: On 09/14/2016 10:10 AM, Mate Nagy-Egri via cmake-developers wrote: > How do you setup Visual Studio to debug through a config/gen process? The easiest way is to use one of the VS IDE generators rather than NMake Makefiles. Then in the IDE use the properties dialog on the "cmake" target to set up a command line and working directory, and finally use the IDE menu option to start debugging. -Brad From brad.king at kitware.com Thu Sep 15 08:07:58 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Sep 2016 08:07:58 -0400 Subject: [cmake-developers] CodeLite generator enhancement(s) In-Reply-To: References: Message-ID: On 09/15/2016 03:24 AM, Minze Zwerver wrote: > I could merge the codelite enhancements into the original > codelite generator That would be preferred. > Would something like -DCMAKE_CODELITE_USE_TARGETS=ON be an > acceptable way, if not, how should one influence the generator ? Yes. FYI, the "cmake server" work that has been discussed on this list (previously called "cmake daemon") may eventually eliminate the need for "extra" generators. It will allow IDEs to ask CMake for information about the projects in a structured way. -Brad From csiga.biga at aol.com Thu Sep 15 09:04:12 2016 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Thu, 15 Sep 2016 15:04:12 +0200 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: References: <20160914141530.908C3E5D43@public.kitware.com> Message-ID: That is exactly what I?m doing. I am generating a VS solution, and inside that I setup the debugging environment, but the process I want to debug is not the VS solution generation, but the NMake Makefile generation process. What should I put inside the Environment dialog to make things work? Even when it?s empty, it finds cl.exe, but cmake fails trying to use it. Felad?: Brad King -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: screen.png Type: image/png Size: 211936 bytes Desc: not available URL: From brad.king at kitware.com Thu Sep 15 09:11:27 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Sep 2016 09:11:27 -0400 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: <57da9c51.8296420a.9aee5.c4a4SMTPIN_ADDED_MISSING@mx.google.com> References: <20160914141530.908C3E5D43@public.kitware.com> <57da9c51.8296420a.9aee5.c4a4SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 09/15/2016 09:04 AM, csiga.biga at aol.com wrote: > That is exactly what I?m doing. I am generating a VS solution, and > inside that I setup the debugging environment, but the process I want > to debug is not the VS solution generation, but the NMake Makefile > generation process. Okay, misread your original message. I've never actually tried that. > What should I put inside the Environment dialog to make things work? > Even when it?s empty, it finds cl.exe, but cmake fails trying to use it. Add "VERBOSE=1" to the environment to get a little more output about the "RC Pass 1 failed to run" failure. -Brad From csiga.biga at aol.com Thu Sep 15 10:33:14 2016 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Thu, 15 Sep 2016 16:33:14 +0200 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: References: <20160914141530.908C3E5D43@public.kitware.com> <57da9c51.8296420a.9aee5.c4a4SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Some very interesting things are happening. I am walking through the code with F11, F10, Shift+F10 and trying to understand what?s happening. What really makes this process hard is that occasionally it succeeds generating the Makefile and the exit code is 0. Ultimately if I try to run the generated makefile it terminates with a linker error: PS C:\Users\Matty> Import-VisualEnvironment -Version 14 -Architecture Win64 PS C:\Users\Matty> cl.exe Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] PS C:\Users\Matty> cd .\Build\CMake_Example\NMake\ PS C:\Users\Matty\Build\CMake_Example\NMake> nmake clean Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. PS C:\Users\Matty\Build\CMake_Example\NMake> nmake Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. [ 20%] Building CXX object phys/CMakeFiles/Phys.dir/src/stuff.cpp.obj stuff.cpp [ 40%] Building CXX object phys/CMakeFiles/Phys.dir/src/more.cpp.obj more.cpp [ 60%] Linking CXX static library Phys.lib [ 60%] Built target Phys [ 80%] Building CXX object app/CMakeFiles/Application.dir/src/main.cpp.obj main.cpp [100%] Linking CXX executable Application.exe [100%] Built target Application Import-VisualEnvironment is a PowerShell Commandlet made by me which essentially calls vcvarsall.bat. The extra info I gained through the VERBOSE=1 env var is this: Linking C executable cmTC_14330.exe C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_14330.dir --manifests -- C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\cmTC_14330.dir\objects1.rsp @C:\Users\Matty\AppData\Local\Temp\nm32CF.tmp Visual Studio Incremental Link with embedded manifests Create CMakeFiles\cmTC_14330.dir/manifest.rc Create empty: CMakeFiles\cmTC_14330.dir/embed.manifest RC Pass 1: /foCMakeFiles\cmTC_14330.dir/manifest.res CMakeFiles\cmTC_14330.dir/manifest.rc RC Pass 1 failed to run. However, this part I do not understand. I believe something is not quite consistent within the generation process, sometimes succeeding and somethimes not. Any ideas? Thanks Brad for the tips thus far, M?t? Felad?: Brad King Elk?ldve: 2016. szeptember 15., cs?t?rt?k 15:11 C?mzett: csiga.biga at aol.com M?solatot kap: cmake-developers at cmake.org T?rgy: Re: [cmake-developers] Debug through config/gen inside Visual Studio On 09/15/2016 09:04 AM, csiga.biga at aol.com wrote: > That is exactly what I?m doing. I am generating a VS solution, and > inside that I setup the debugging environment, but the process I want > to debug is not the VS solution generation, but the NMake Makefile > generation process. Okay, misread your original message. I've never actually tried that. > What should I put inside the Environment dialog to make things work? > Even when it?s empty, it finds cl.exe, but cmake fails trying to use it. Add "VERBOSE=1" to the environment to get a little more output about the "RC Pass 1 failed to run" failure. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry at codexdigital.com Thu Sep 15 10:22:42 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Thu, 15 Sep 2016 14:22:42 +0000 Subject: [cmake-developers] FindOpenSSL binaries Message-ID: <19BA6563-660A-4BA0-88F0-F2F5C4F1E0D3@codexdigital.com> Hello, 1. We use the openssl binary for encrypting things in a cmake step. It would be nice if FindOpenSSL could find the binary "openssl" as well as the includes and libs, so we can use the same versions as we link easily. Maybe something like the below would do: ... # ``OPENSSL_EXECUTABLE `` # The openssl binary. ... find_path(OPENSSL_EXECUTABLE NAMES openssl ${_OPENSSL_ROOT_HINTS_AND_PATHS} PATH_SUFFIXES bin ) ... 2. Should "OPENSSL_INCLUDE_DIR" be "OPENSSL_INCLUDE_DIRS" or is that not a hard-and-fast rule? Thanks, Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From brad.king at kitware.com Thu Sep 15 11:12:01 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Sep 2016 11:12:01 -0400 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: <57dab12d.4a0d420a.3c21d.b5a3SMTPIN_ADDED_MISSING@mx.google.com> References: <20160914141530.908C3E5D43@public.kitware.com> <57da9c51.8296420a.9aee5.c4a4SMTPIN_ADDED_MISSING@mx.google.com> <57dab12d.4a0d420a.3c21d.b5a3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <3cde5b95-f221-9aec-1c76-32476e6aa76a@kitware.com> On 09/15/2016 10:33 AM, csiga.biga at aol.com wrote: > RC Pass 1: > > /foCMakeFiles\cmTC_14330.dir/manifest.res CMakeFiles\cmTC_14330.dir/manifest.rc The "rc" tool is missing from the beginning of this command line. It needs to be in the PATH within the VS environment. -Brad From brad.king at kitware.com Thu Sep 15 11:13:12 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 15 Sep 2016 11:13:12 -0400 Subject: [cmake-developers] FindOpenSSL binaries In-Reply-To: <19BA6563-660A-4BA0-88F0-F2F5C4F1E0D3@codexdigital.com> References: <19BA6563-660A-4BA0-88F0-F2F5C4F1E0D3@codexdigital.com> Message-ID: <5a9fc1f5-6744-38d2-3ea8-f63efe1bcc10@kitware.com> On 09/15/2016 10:22 AM, Harry Mallon wrote: > # ``OPENSSL_EXECUTABLE `` > # The openssl binary. Yes, this would be a reasonable addition as long as it is optional. > 2. Should "OPENSSL_INCLUDE_DIR" be "OPENSSL_INCLUDE_DIRS" or is that > not a hard-and-fast rule? In general the singular name should be the cache entry and the plural name should be used to collect results for consumption by the project code. One could add the plural name. Thanks, -Brad From yves.frederix+cmake at gmail.com Fri Sep 16 03:37:22 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Fri, 16 Sep 2016 09:37:22 +0200 Subject: [cmake-developers] Automatic project generation with Visual Studio generators In-Reply-To: <2b8ca07b-5e2c-f03b-26a7-04b9b4d588a3@kitware.com> References: <2b8ca07b-5e2c-f03b-26a7-04b9b4d588a3@kitware.com> Message-ID: Hi Brad, > For `cmake --build` we already need to detect the generator used > for the build tree in order to ask it to construct the appropriate > command line. For the VS generator we could directly run the same > check that ZERO_CHECK would run in order to decide whether to regen > the build files first. That would avoid going through msbuild for > this step altogether. Thanks for your answer. So if I understand correctly, you would avoid msbuild using msbuild for the up-to-date check and instead call something like (taken from ZERO_CHECK.vcxproj): cmake -H... -B.. --check-stamp-list CMakeFiles/generate.stamp.list This would work, but it would make all builds using 'cmake --build' more verbose as before actually starting the msbuild-build, this would always print an often large number of lines like: CMake does not need to re-run because .../CMakeFiles/generate.stamp is up-to-date. When using msbuild to build the zero_check target, you avoid this somehow as you make use of the dependency tracking offered by msbuild. I don't have a strong opinion on whether to use 'cmake -H -B...' or msbuild, but I would like to avoid cluttering normal build output with this information. Assuming we do not want to call msbuild, an option would be to remove the print statement if a stamp file is up to date? Or alternatively I could add an option '--verbose|-V' to cmake that would control whether to print them? Regards, Yves From ysblokje at gmail.com Fri Sep 16 05:49:44 2016 From: ysblokje at gmail.com (Minze Zwerver) Date: Fri, 16 Sep 2016 11:49:44 +0200 Subject: [cmake-developers] CodeLite generator enhancement(s) In-Reply-To: <82d462aa-669f-9e90-e211-dff60e1b2b59@kitware.com> References: <82d462aa-669f-9e90-e211-dff60e1b2b59@kitware.com> Message-ID: I can't commit to the gitlab , it says something regarding no disk space. $ git push Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 2.36 KiB | 0 bytes/s, done. Total 5 (delta 4), reused 0 (delta 0) remote: error: file write error (No space left on device) remote: fatal: unable to write sha1 file error: unpack failed: unpack-objects abnormal exit To gitlab.kitware.com:ysblokje/cmake.git ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to 'git at gitlab.kitware.com: ysblokje/cmake.git' On Thu, Sep 15, 2016 at 10:19 PM, Brad King wrote: > On 09/15/2016 04:14 PM, Minze Zwerver wrote: > > I'll try to remove as much duplicated code and try to get a patch soon. > > When you do, please use our GitLab instance to submit it: > > https://gitlab.kitware.com/cmake/cmake > > One can optionally use a GitHub account to authenticate. It has a > fork-and-merge-request model. We're still experimenting with it > so CONTRIBUTING.rst has not been updated yet. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Fri Sep 16 06:32:04 2016 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Fri, 16 Sep 2016 12:32:04 +0200 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: <3cde5b95-f221-9aec-1c76-32476e6aa76a@kitware.com> References: <20160914141530.908C3E5D43@public.kitware.com> <57da9c51.8296420a.9aee5.c4a4SMTPIN_ADDED_MISSING@mx.google.com> <57dab12d.4a0d420a.3c21d.b5a3SMTPIN_ADDED_MISSING@mx.google.com> <3cde5b95-f221-9aec-1c76-32476e6aa76a@kitware.com> Message-ID: Thank you Brad. I took the aggressive way and completely wiped the environment inside the debugged process. For those anyone wishing to do something similar, here?s what I?ve done: I wrote a PowerShell oneliner: gci Env: | foreach { $_.Name + "=" + $_.Value } | Out-File -FilePath .\Desktop\env.txt -Append When invoked inside a Visual Command Prompt this outputs a complete environment into a file in a format that can be copy-pasted into the Visual Studio Project Property Page. Make sure to set Merge Environment option to No. After this it worked like a charm. Now it?s only up to me to understand the entire process of Makefile generation. Global/Local Generators, LocalMakeFileGenerator3 (does 3 correspond to the third layer of makefiles? If yes, where is 2?)? The code is fairly convoluted (seems a bit more complex than neccessary, but it might be my lack of understanding that makes me feel this way). One sidequestion: what is the reason for eliding STL algorithms? There are nice iterators all over the place, yet no algorithms used, even when it were possible. Algorithms make the code much easier to understand (the name of the algorithm states the intent of the for-loop), plus when C++17 hits (configure-time check?), parallel STL invocations could speed up the configuration process automatically with minimal code impact. Would you accept such patches, where loops are exchanged for algorithms where possible? Felad?: Brad King -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Sep 16 08:38:59 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 16 Sep 2016 08:38:59 -0400 Subject: [cmake-developers] Automatic project generation with Visual Studio generators In-Reply-To: References: <2b8ca07b-5e2c-f03b-26a7-04b9b4d588a3@kitware.com> Message-ID: <52ffcc2c-c08f-1684-e204-4b4818011ff3@kitware.com> On 09/16/2016 03:37 AM, Yves Frederix wrote: > This would work, but it would make all builds using 'cmake --build' > more verbose as before actually starting the msbuild-build, this would > always print an often large number of lines like: > > CMake does not need to re-run because .../CMakeFiles/generate.stamp > is up-to-date. [snip] > Or alternatively I could add an option '--verbose|-V' to cmake that > would control whether to print them? We don't need to invoke the `--check-stamp-list` command by executing another process. The `cmake --build` process can just invoke the same APIs internally, and with options to be quiet. After regeneration is complete (or not done) then it can run the normal build command. -Brad From brad.king at kitware.com Fri Sep 16 08:39:09 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 16 Sep 2016 08:39:09 -0400 Subject: [cmake-developers] Debug through config/gen inside Visual Studio In-Reply-To: <57dbca27.d647620a.542a3.dcc3SMTPIN_ADDED_MISSING@mx.google.com> References: <20160914141530.908C3E5D43@public.kitware.com> <57da9c51.8296420a.9aee5.c4a4SMTPIN_ADDED_MISSING@mx.google.com> <57dab12d.4a0d420a.3c21d.b5a3SMTPIN_ADDED_MISSING@mx.google.com> <3cde5b95-f221-9aec-1c76-32476e6aa76a@kitware.com> <57dbca27.d647620a.542a3.dcc3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 09/16/2016 06:32 AM, csiga.biga at aol.com wrote: > Now it?s only up to me to understand the entire process of Makefile generation. > Global/Local Generators, LocalMakeFileGenerator3 (does 3 correspond to the > third layer of makefiles? If yes, where is 2?) The 3 is the third generation of makefile generator design. The older versions are only available in version control history. > The code is fairly convoluted (seems a bit more complex than neccessary, > but it might be my lack of understanding that makes me feel this way). There are many years of redesigns and partial refactors accumulated ;) > One sidequestion: what is the reason for eliding STL algorithms? > There are nice iterators all over the place, yet no algorithms used, > even when it were possible. Algorithms make the code much easier to > understand (the name of the algorithm states the intent of the for-loop) Only in the last few years have we dropped support for ancient compilers that don't have all that implemented correctly. Some progress has been made on modernizing some of the internals, but no thorough sweep has been done. Any place you see that can have a loop replaced with an algorithm is fair game to update (with normal review of course). > plus when C++17 hits (configure-time check?), parallel STL invocations > could speed up the configuration process automatically with minimal > code impact. Would you accept such patches, where loops are exchanged > for algorithms where possible? We do need to continue supporting C++98-only builds because we still support platforms where C++11 compilers are hard to come by. We do allow compiling as any newer standard on compilers that support it (e.g. the nightly binaries currently all build as C++11 or above). One can see some configure-time checks for things like unordered_map. Other optional optimizations like this are allowed, so long as they do not produce too much clutter or layers of macros. -Brad From brad.king at kitware.com Fri Sep 16 08:49:55 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 16 Sep 2016 08:49:55 -0400 Subject: [cmake-developers] CodeLite generator enhancement(s) In-Reply-To: References: <82d462aa-669f-9e90-e211-dff60e1b2b59@kitware.com> Message-ID: On 09/16/2016 05:49 AM, Minze Zwerver wrote: > I can't commit to the gitlab , it says something regarding no disk space. Bad luck ;) I've notified our admins. Please try again in a few hours. -Brad From ysblokje at gmail.com Sat Sep 17 05:37:18 2016 From: ysblokje at gmail.com (Minze Zwerver) Date: Sat, 17 Sep 2016 11:37:18 +0200 Subject: [cmake-developers] CodeLite generator enhancement(s) In-Reply-To: References: <82d462aa-669f-9e90-e211-dff60e1b2b59@kitware.com> Message-ID: Okay got it pushed. That bot sure is a ...... I made a pull request, fixed it's remarks. And it's still not happy. On Fri, Sep 16, 2016 at 2:49 PM, Brad King wrote: > On 09/16/2016 05:49 AM, Minze Zwerver wrote: > > I can't commit to the gitlab , it says something regarding no disk space. > > Bad luck ;) > > I've notified our admins. Please try again in a few hours. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at takar.nl Sun Sep 18 06:21:10 2016 From: info at takar.nl (Tamar Kranenburg) Date: Sun, 18 Sep 2016 12:21:10 +0200 Subject: [cmake-developers] [FindPostgreSQL] Search for version 9.6 Message-ID: Hi all, PostgreSQL 9.6 will be released this quarter. The first patch corrects a comment, the second patch adds version 9.6 to the search suffixes of the FindPostgreSQL module. Regards, Tamar -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindPostgreSQL-Correct-comment-about-known-postgres-.patch Type: application/octet-stream Size: 959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-FindPostgreSQL-Search-for-version-9.6.patch Type: application/octet-stream Size: 1361 bytes Desc: not available URL: From eike at sf-mail.de Sun Sep 18 10:40:42 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 18 Sep 2016 16:40:42 +0200 Subject: [cmake-developers] [FindPostgreSQL] Search for version 9.6 In-Reply-To: References: Message-ID: <3383136.3sTNvSneLQ@daneel.sf-tec.de> Am Sonntag, 18. September 2016, 12:21:10 schrieb Tamar Kranenburg: > Hi all, > > PostgreSQL 9.6 will be released this quarter. The first patch corrects a > comment, the second patch adds version 9.6 to the search suffixes of the > FindPostgreSQL module. Merged to next here: https://cmake.org/gitweb?p=cmake.git;a=commit;h=0c1355ff6b6e05324b7d9d28d9b72d91e3ef9e20 Greetings, Eike -------------- 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 ruslan_baratov at yahoo.com Mon Sep 19 10:39:27 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 19 Sep 2016 17:39:27 +0300 Subject: [cmake-developers] Downloading file from S3 private bucket In-Reply-To: References: <7547435f-e09c-0bff-dfa9-6bf796abdd58@kitware.com> Message-ID: <0ae0476e-4ea7-2832-458c-47bb55616c44@yahoo.com> Circumstances changed, we are not interested in this feature anymore at this moment. Just for the record workarounds using external call to 'openssl' can be found here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/105 * https://gitlab.kitware.com/cmake/cmake/merge_requests/108 Ruslo On 13-Sep-16 16:28, Ruslan Baratov wrote: > On 13-Sep-16 15:58, Brad King wrote: >> On 09/13/2016 07:42 AM, Ruslan Baratov via cmake-developers wrote: >>> Will it be okay if CMake will optionally depend on OpenSSL? >>> Or other third party crypto library? >> Currently the only place that needs it is through `curl`, and >> that uses either OpenSSL or the Windows-native or macOS-native >> APIs for TLS. > So your suggestion is to extend 'file' command? Like > `file(DOWNLOAD|UPLOAD S3_KEY S3_SECRET )`? > >> It looks like curl does support HMAC. >> > I don't know, will take a look. We need this functionality: > > echo -n "${stringToSign}" | openssl sha1 -hmac "${secret}" -binary | > base64 > > Ruslo From craig.scott at crascit.com Tue Sep 20 11:12:26 2016 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 21 Sep 2016 01:12:26 +1000 Subject: [cmake-developers] Use of C++11 in CMake's own source code Message-ID: Tried searching the archives for this but too many hits for the general CMake feature supporting C++11. What's the current policy for use of C++11 in CMake's own source code? A cursory trip through some sources recently suggested no C++11 features are being used, which I can understand if there is the requirement to support building CMake on systems with compilers which don't have C++11 support. I do, however, see some C++11 stuff in at least one recent merge request, so I'm wondering what the current policy on this is? I don't want to start a long philosophical discussion, I just want to clarify the constraints on merge requests, etc. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Sep 20 11:30:44 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 20 Sep 2016 11:30:44 -0400 Subject: [cmake-developers] Use of C++11 in CMake's own source code In-Reply-To: References: Message-ID: <34c8766f-7b41-b2a1-ad0d-c7408896ee9e@kitware.com> On 09/20/2016 11:12 AM, Craig Scott wrote: > some C++11 stuff in at least one recent merge request We allow C++14 in code guarded by HAVE_SERVER_MODE because that is a new/optional feature that doesn't have to work on all platforms yet. Everything not guarded by HAVE_SERVER_MODE needs to be able to compile in all language levels C++98 and above. We have CM_NULLPTR and similar macros to enable C++11 safety checks when building at that level or above, but they fall back to C++98-compatible code too. -Brad From konstantin at podsvirov.pro Wed Sep 21 12:56:51 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 21 Sep 2016 19:56:51 +0300 Subject: [cmake-developers] [MODERN] CMake 3.6+ vs Qt 5.7 vs MSVC2015 In-Reply-To: <629571466699878@web27g.yandex.ru> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <1975171437723971@web22h.yandex.ru> <55B653D0.4020001@kitware.com> <198581438094978@web29o.yandex.ru> <825181443680946@web21o.yandex.ru> <56451463763913@web25o.yandex.ru> <476621464710287@web16g.yandex.ru> <4434461464882342@web5o.yandex.ru> <629571466699878@web27g.yandex.ru> Message-ID: <1581361474477011@web11h.yandex.ru> Hi all! CMake Master (Win32/Win64) updated! :-) It's time to upgrade: CMake 3.6.20160921 now available! "CMake Master" - is himself created (IFW generator) online installer for CMake users and developers. 23.06.2016, 19:38, "Konstantin Podsvirov" : > Let me remind you of the link. > > Windows 32bit: > > http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe > > Windows 64bit: > > http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe > > If you have used it before, you can update via "CMake Maintenance Tool" > > I used Windows 7, but it should work for Windows Vista and Windows 8 and Windows 10. > > I ask those wishing to test the functionality. > > Please test it :-) Pay your attention: Added new component "CMake Developer Reference" - Doxygen based source code reference. You can install it by online installer in HTML and Qt Compressed Help formats or preview it in your browser online at http://ifw.podsvirov.pro/cmake/doc/doxygen/ >>>> ???01.10.2015, 09:29, Konstantin Podsvirov" : >>>>> ????Hi all! Modern master alive! :-) >>>>> >>>>> ????It's been almost a month and it's time to upgrade: >>>>> >>>>> ????3.3.20150901 CMake => CMake 3.3.20151001 >>>>> >>>>> ????Dear friends, I have a question and call for help. >>>>> >>>>> ????With my assistance the project has an option for component installation project: >>>>> >>>>> ????CMake_INSTALL_COMPONENTS >>>>> >>>>> ????Unfortunately not all files found your component. >>>>> ????The files to be installed without specifying a component fall into 'Unspecified' component. >>>>> ????Need to parse them out and assign them to the component context. >>>>> >>>>> ????Now have the components: >>>>> >>>>> ????- cmake; >>>>> ????- ctest; >>>>> ????- cpack; >>>>> ????- cmake-gui; >>>>> ????- sphinx-man; >>>>> ????- sphinx-html; >>>>> ????- sphinx singlehtml; >>>>> ????- sphinx-qthelp >>>>> >>>>> ????and General for everything else >>>>> >>>>> ????Is Unspecified; >>>>> >>>>> ????A list of unaccounted for 'Unspecified' of files to install on the Window is attached. >>>>> >>>>> ????Links to the installers were specified earlier (see below). >>>>> >>>>> ????On 28.07.2015, 17:49, "Konstantin Podsvirov" : >>>>>> ????Hi dear CMake developers! >>>>>> >>>>>> ????27.07.2015, 18:52, "Brad King" : >>>>>>> ????On 07/24/2015 03:46 AM, Konstantin Podsvirov wrote: >>>>>>>> ????To solve the problem you run cmake-gui is now possible with the >>>>>>>> ????the following changes: >>>>>>> >>>>>>> ????Applied as two separate commits with minor tweaks: >>>>>>> >>>>>>> ????cmake-gui: Install Qt5 Windows platform plugin >>>>>>> ????http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f0155b >>>>>>> >>>>>>> ????CMake: Add option CMake_INSTALL_DEPENDENCIES >>>>>>> ????http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 >>>>>> >>>>>> ????Code now in 'master' branch. >>>>>> >>>>>> ????Thanks, Brad! >>>>>> >>>>>> ????Meet/install/CMake built modern update on MSVC2015 c QtDialog based on Qt 5.5 from today :-) >>>>>> >>>>>> ????Windows 32bit: >>>>>> >>>>>> ????http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe >>>>>> >>>>>> ????Windows 64bit: >>>>>> >>>>>> ????http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe >>>>>> >>>>>> ????cmake-gui should work now, but if not, then update your system and install >>>>>> >>>>>> ????The Visual C++ Redistributable for Visual Studio 2015 from the link below: >>>>>> >>>>>> ????http://www.microsoft.com/en-us/download/details.aspx?id=48145 >>>>>> >>>>>> ????As always, questions and suggestions are welcome. >>>>> >>>>> ????-- >>>>> ????Regards, >>>>> ????Konstantin Podsvirov >>>>> ????,-- >>>>> >>>>> ????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 >> >> ?Regards, >> ?Konstantin Podsvirov >> ?-- >> >> ?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 > -- > > 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 roman.wueger at gmx.at Wed Sep 21 17:04:46 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 21 Sep 2016 23:04:46 +0200 Subject: [cmake-developers] CPack [NSIS] Install directory per component Message-ID: Hello, Per default the install directory for a component is $INSTDIR. Is there a chance to change the install dir per component? Thanks Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.pugin at gmail.com Wed Sep 21 17:22:45 2016 From: egor.pugin at gmail.com (Egor Pugin) Date: Thu, 22 Sep 2016 00:22:45 +0300 Subject: [cmake-developers] Security in CMake In-Reply-To: References: Message-ID: Hi, For those who may be interested I will leave this message here. Mentioned package (dependency) manager is C++ Archive Network. https://cppan.org/ It generates CMakeLists.txt from specification files. It manages packages' dependencies, versions, different OSs (it's crossplatform from very beginning), handles crossplatform builds very easy (build will inherit your current project settings and autocrossplaform all deps). All builds are cached too - you build your dependency only once. Static/shared mt/md 32/64 deb/rel/... different toolchains (vc11, vc12,vc14, clangX.X, gcc-X) are handled and supported out of the box (with help of CMake). It also stores sources on its site, so they shouldn't be lost. And more to come. I've added a lot of popular packages. I didn't do much advertisement yet, so cppan is used only by a few people/projects at the moment. In my 'to add' list of big and very known projects: opencv (near future), qt (qt-lite?, ~ end of 2016). I'm adding small projects from time to time. Feel free to contact me here or privately. On 22 August 2016 at 20:52, Egor Pugin wrote: > Hi Chuck, > >> Is this intended to run on Linux? > > Yes. And thanks for the pointing out to SELinux. I'll add it to my checklist. > > --- > > The system is on very early stages now, so its parts are changing > rapidly and I'm able to consider different approaches to its > subsystems (including security). > But I probably confused all of you with the words 'package manager'. > It's the package manager only in the narrow sense. It's not trying to > be another apt, yum etc. Sorry that I didn't provide much details, but > the original topic is very precise and I think I'll return to it a bit > later when the functionality of the system will be in more stable > state. > > > On 22 August 2016 at 20:17, Chuck Atkins wrote: >> Hi Egor, >> Is this intended to run on Linux? If so, I think you're FAR better off >> leveraging an existing security framework like SELinux, since it's actually >> designed from the ground up to enforce these types of controls. You could >> define a label that you place on the executables run by the package manager >> and then enforce whatever restrictions and controls you feel are >> appropriate. This will let you do things like block network access got the >> specific CMake executable used by the package system. It allows the CMake >> scripts to leverage all the available language and command features but >> deny, ant a system level, actions you deem unsafe or harmful. >> >> ---------- >> Chuck Atkins >> Staff R&D Engineer, Scientific Computing >> Kitware, Inc. >> >> >> On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin wrote: >>> >>> > What is the attack you want to stop? What are bad scripts and commands >>> > in this context? >>> >>> I wrote them in the first message. For example, >>> - any cmake commands that use COMMAND keyword (execute_process(COMMAND >>> ...), add_custom_{command|target}(...) etc. This will deny any user >>> scripts, programs (wget, curl, rm, ...). >>> - download commands (CMake's builtin curl) - they can fill the drives >>> with trash. >>> >>> > CMake runs lots of commands all the time. Most can be changed by a user, >>> > many are changed by the generator based on environment and whatnot. Any of >>> > these may be bad commands -- based on configuration. >>> >>> Yes, and it should deny only stuff above in small CMakeLists.txt part >>> that will be protected with some other commands or policies. >>> >>> > But if CMake gets a secure mode for your generator and if that is merged >>> > upstream, then I need to know about that when reading or writing >>> > CMakeLists.txt. >>> >>> For the moment I'm just asking about possibility of implementation of >>> these features. Any decision will go from CMake guys, not from me. So, >>> you shouldn't ask me about it. :) >>> >>> > Generated code is safe only as long as you very tightly control the >>> > environment CMake runs in. >>> >>> I don't care what is around, what is in user env. This is his >>> responsibility. I'm just worrying for my parts of CMake stuff. >>> >>> On 21 August 2016 at 20:43, Tobias Hunger wrote: >>> > Hi Egor, >>> > >>> > Am 21.08.2016 12:34 schrieb "Egor Pugin" : >>> >> >>> >> > What are the attack scenarios you want to defend against? What should >>> >> > not be possible in your system that currently is in CMake? >>> >> >>> >> At least downloading or executing bad scripts and commands. >>> > >>> > What is the attack you want to stop? What are bad scripts and commands >>> > in >>> > this context? >>> > >>> > CMake runs lots of commands all the time. Most can be changed by a user, >>> > many are changed by the generator based on environment and whatnot. Any >>> > of >>> > these may be bad commands -- based on configuration. >>> > >>> > Downloading can be done using internal commands or by running e.g. wget >>> > or >>> > curl, both of which are pretty widely available on developer machines. >>> > >>> >> > That forces me to keep more state in my head when reading >>> >> > CMakeLists.txt >>> >> > files. >>> >> >>> >> CMake files are generated in my system. That's what I mean when I said >>> >> 'based on CMake'. >>> > >>> > Sure. But if CMake gets a secure mode for your generator and if that is >>> > merged upstream, then I need to know about that when reading or writing >>> > CMakeLists.txt. >>> > >>> >> It's like compiler compiler like yacc, bison, lex, flex. They are >>> >> producing output not for human readers, but for computer parsers. >>> >> And that's why generated code is safe and insertions from users are >>> >> not. >>> > >>> > Generated code is safe only as long as you very tightly control the >>> > environment CMake runs in. >>> > >>> >> Also in the most cases there's no any insertions at all, so it's rare >>> >> case. >>> > >>> > I'm sure you know what you are doing:) >>> > >>> > Best regards, >>> > Tobias >>> >>> >>> >>> -- >>> Egor Pugin >>> -- >>> >>> 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 >> >> > > > > -- > Egor Pugin -- Egor Pugin From roman.wueger at gmx.at Thu Sep 22 06:30:26 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 22 Sep 2016 12:30:26 +0200 Subject: [cmake-developers] Security in CMake In-Reply-To: References: Message-ID: <1922ECC6-045D-42D2-9256-91AB7776E84F@gmx.at> The most of the functions could be overloaded. You could overload those functions, filter options out and pass the new options to the original function which starts with and '_' underscore. The most of the CMake module files could also be overloaded. Hope it helps Best regards Roman > Am 21.08.2016 um 10:24 schrieb Tobias Hunger : > > Hi Egor, > > Am 20.08.2016 23:42 schrieb "Egor Pugin" : > > You are right at many points. It's hard to really secure the system > > from build system/build artifacts/3rd party apps. > > But step by step it's possible to decrease number of potential sources > > of vulnerabilities. > > Retrofitting security into a product that was designed without any consideration for security from the start is going to be hard. > > I do not know what you want to do, so I am not going to claim it is impossible:-) > > > Described cmake features would be very helpful for this. > > Right now I'm just investigating possible security improvements and > > this is only 'nice-to-have' feature. > > What are the attack scenarios you want to defend against? What should not be possible in your system that currently is in CMake? How do these steps help in securing against those attacks? > > As a user of CMake I am very much opposed to disabling functionality based on the context: That forces me to keep more state in my head when reading CMakeLists.txt files. CMake does way too much in a way to obscure syntax already! > > Best regards, > Tobias > > > On 21 August 2016 at 00:25, Tobias Hunger wrote: > > > Hi Egor, > > > > > > Am 20.08.2016 13:48 schrieb "Egor Pugin" : > > >> > > >> Hi, > > >> > > >> I'm working on a package manager based on cmake. > > >> And some cmake instructions are downloaded with user packages. > > >> I'd like to have an ability to deny some cmake features in such > > >> external untrusted insertions. > > > > > > I am no CMake expert, but you are talking about securing a program that is > > > meant to take arbitrary input and run user-defined commands on that to > > > produce possibly executable output. > > > > > > I do not see any safe subset of CMake commands that is still able to do > > > anything useful. > > > > > > I can see a way for "insertions" to be useful, that does not involve them > > > changing the configuration (e.g. for a cross compiler), involve running some > > > 3rd party program (e.g. to add support for a new documentation system, > > > parser generator or whatnot), or the production of build artifacts (e.g. > > > build some library for the developer to use). > > > > > > *All* of these are inheritently unsafe. > > > > > > Configuration change: Change the C compiler to rm and pass force -rf -- / as > > > flags. > > > > > > 3rd party program: Run rm -rf / when some certain input file is seen. > > > > > > Build artifacts: Put running rm -rf / into the binary/library so that this > > > is run during normal development workflow. > > > > > > I would try to run my package manager in an environment where running rm -rf > > > is harmless to the overall system health. Virtual machines or containers > > > spring to mind there. Not sure that is feasible. > > > > > > Or come up with insertions signing, etc. so that users can at least know > > > they got what was uploaded and know whom to blame when their systems get > > > wiped. > > > > > > Beat Regards, > > > Tobias > > > > > > > > -- > > Egor Pugin > > -- > > 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 Thu Sep 22 10:41:56 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 22 Sep 2016 14:41:56 +0000 Subject: [cmake-developers] FastBuild Generator Message-ID: Hi, As some of you may know, there is a Fastbuild generator in the works, whose development started on CMake 3.2, and was pretty much abandonned for the past 5 months. I took the time to rebase it on master, and while there is a lot to clean up (and some stuff works worse that it used to because the rebase was done hastily), I'd like for a first step review to start, so that big design issues can be caught right now, instead of waiting for 100% of the tests to pass before re-writing most of the code. How does this process goes ? Should I create a MergeRequest on gitlab ? A Pull request on GitHub ? patches sent by mail ? So far the code lives in https://github.com/packadal/CMake/tree/fastbuild-master Thanks, Charles. FYI as of the rebase on CMake 3.6.1, the tests results are: 94% tests passed, 25 tests failed out of 400 Label Time Summary: Label1 = 0.66 sec (1 test) Label2 = 0.66 sec (1 test) Total Test time (real) = 614.33 sec The following tests FAILED: 37 - MSManifest (Failed) 46 - ObjectLibrary (Failed) 61 - Preprocess (Failed) 62 - ExportImport (Failed) 70 - StagingPrefix (Failed) 79 - Module.ExternalData (Failed) 109 - CustomCommand (Failed) 114 - BuildDepends (Failed) 115 - SimpleInstall (Failed) 116 - SimpleInstall-Stage2 (Failed) 132 - ExternalProject (Failed) 134 - ExternalProjectLocal (Failed) 135 - ExternalProjectUpdateSetup (Failed) 136 - ExternalProjectUpdate (Failed) 153 - Plugin (SEGFAULT) 156 - SubDir (Failed) 194 - CMakeCommands.target_link_libraries (Failed) 226 - InterfaceLinkLibraries (Failed) 275 - RunCMake.CMP0060 (Failed) 277 - RunCMake.CMP0065 (Failed) 280 - RunCMake.BuildDepends (Failed) 282 - RunCMake.Configure (Failed) 362 - RunCMake.ExternalProject (Failed) 369 - RunCMake.AutoExportDll (Failed) 400 - CMake.CheckSourceTree (Failed) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 22 13:26:13 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 22 Sep 2016 13:26:13 -0400 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: Message-ID: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> On 09/22/2016 10:41 AM, Charles Huet wrote: > a Fastbuild generator in the works, whose development started on CMake 3.2, > and was pretty much abandonned for the past 5 months. > > I took the time to rebase it on master Thanks for reviving it. IIUC this refers to: * http://fastbuild.org * https://github.com/fastbuild/fastbuild > big design issues can be caught right now >From a quick glance the main problem I see is that it doesn't follow the Makefile/Ninja generator model of organizing the generator code into a per-target generator. See cmCommonTargetGenerator and its subclasses. We've found that having a per-target generator is much easier than passing the target pointers around in "local" generators. > Should I create a MergeRequest on gitlab? That will be fine when you have something ready, preferably after addressing major architectural issues. We can do high-level reviews here first. > https://github.com/packadal/CMake/tree/fastbuild-master Please make every commit properly formatted (with clang-format) rather than formatting after-the-fact. If you've made substantial non-formatting changes from the original version please record yourself as the author and add a trailer to the commit message such as Co-Author: Josh Green or Inspired-by: Josh Green depending on how much original work remains. Thanks, -Brad From charles.huet at gmail.com Thu Sep 22 15:02:52 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 22 Sep 2016 19:02:52 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> Message-ID: > IIUC this refers to: > * http://fastbuild.org > * https://github.com/fastbuild/fastbuild Yes, exactly. >From a quick glance the main problem I see is that it doesn't follow the Makefile/Ninja generator model of organizing the generator code into a per-target generator. OK, so I need to make use of these. >We can do high-level reviews here first. Alright then. >Please make every commit properly formatted (with clang-format) rather than formatting after-the-fact. I actually remembered about the clang-format thread just before writing the first email, so I thought I should just quickly ut everything to format. >If you've made substantial non-formatting changes from the original >version please record yourself as the author and add a trailer to >the commit message I squashed everything into a big commit to make things easier for me, and completely forgot about proper attribution of the work, so I'll squash all of Josh's commits into one, and all of mine into another and make sure those are correctly formatted. To sum up, what I have to do now is: * squash commits and format those for proper attribuation * refactor to have a cmFastbuildTargetGenerator that inherits cmCommonTargetGenerator * get the tests to pass I guess before it gets fully integrated into CMake 100% test pass is mandatory, but is linux/mac support mandatory also ? Fastbuild does support those platforms, but the generator so far does not work as well (or at all) on those platforms. Best, Charles Le jeu. 22 sept. 2016 ? 19:26, Brad King a ?crit : > On 09/22/2016 10:41 AM, Charles Huet wrote: > > a Fastbuild generator in the works, whose development started on CMake > 3.2, > > and was pretty much abandonned for the past 5 months. > > > > I took the time to rebase it on master > > Thanks for reviving it. > > IIUC this refers to: > > * http://fastbuild.org > * https://github.com/fastbuild/fastbuild > > > big design issues can be caught right now > > From a quick glance the main problem I see is that it doesn't follow > the Makefile/Ninja generator model of organizing the generator code > into a per-target generator. See cmCommonTargetGenerator and its > subclasses. We've found that having a per-target generator is much > easier than passing the target pointers around in "local" generators. > > > Should I create a MergeRequest on gitlab? > > That will be fine when you have something ready, preferably after > addressing major architectural issues. We can do high-level reviews > here first. > > > https://github.com/packadal/CMake/tree/fastbuild-master > > Please make every commit properly formatted (with clang-format) > rather than formatting after-the-fact. > > If you've made substantial non-formatting changes from the original > version please record yourself as the author and add a trailer to > the commit message such as > > Co-Author: Josh Green > > or > > Inspired-by: Josh Green > > depending on how much original work remains. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 22 15:14:24 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 22 Sep 2016 15:14:24 -0400 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> Message-ID: <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> On 09/22/2016 03:02 PM, Charles Huet wrote: > is linux/mac support mandatory also ? > Fastbuild does support those platforms, but the generator so far does > not work as well (or at all) on those platforms. I think it is okay to support only a subset of platforms at first. Please just make the generator error out early on a platform that is not supported, or simply not even compile on such hosts. Thanks, -Brad From clinton at elemtech.com Thu Sep 22 15:25:53 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 22 Sep 2016 13:25:53 -0600 (MDT) Subject: [cmake-developers] possible fix to include in release Message-ID: <88896737.13574526.1474572353354.JavaMail.zimbra@elemtech.com> Hi, If there is a CMake 3.6.3, I'd like to request the inclusion of https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c Some Linux distros are now shipping cmake-gui on top of Qt5, and the reported QFileDialog problem is present. See also http://public.kitware.com/pipermail/cmake/2016-September/064262.html Thanks, Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysblokje at gmail.com Fri Sep 23 01:58:10 2016 From: ysblokje at gmail.com (Minze Zwerver) Date: Fri, 23 Sep 2016 07:58:10 +0200 Subject: [cmake-developers] Use of C++11 in CMake's own source code In-Reply-To: <34c8766f-7b41-b2a1-ad0d-c7408896ee9e@kitware.com> References: <34c8766f-7b41-b2a1-ad0d-c7408896ee9e@kitware.com> Message-ID: That was my merge request. Which didn't get accepted anyway. I'm currently starting a new clone to address all the points the CI had. But after reading this I'll also remove the C++11 stuff. Minze On Tue, Sep 20, 2016 at 5:30 PM, Brad King wrote: > On 09/20/2016 11:12 AM, Craig Scott wrote: > > some C++11 stuff in at least one recent merge request > > We allow C++14 in code guarded by HAVE_SERVER_MODE because that is > a new/optional feature that doesn't have to work on all platforms yet. > > Everything not guarded by HAVE_SERVER_MODE needs to be able to compile > in all language levels C++98 and above. We have CM_NULLPTR and similar > macros to enable C++11 safety checks when building at that level or > above, but they fall back to C++98-compatible code too. > > -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 ysblokje at gmail.com Fri Sep 23 02:00:30 2016 From: ysblokje at gmail.com (Minze Zwerver) Date: Fri, 23 Sep 2016 08:00:30 +0200 Subject: [cmake-developers] CodeLite generator enhancement(s) In-Reply-To: References: <82d462aa-669f-9e90-e211-dff60e1b2b59@kitware.com> Message-ID: Alright I'm going to try this again. Removed the clone I had, made a new one. Going to address all the points the CI issues again & undo c++11 Minze On Sat, Sep 17, 2016 at 11:37 AM, Minze Zwerver wrote: > Okay got it pushed. > > That bot sure is a ...... > I made a pull request, fixed it's remarks. And it's still not happy. > > > On Fri, Sep 16, 2016 at 2:49 PM, Brad King wrote: > >> On 09/16/2016 05:49 AM, Minze Zwerver wrote: >> > I can't commit to the gitlab , it says something regarding no disk >> space. >> >> Bad luck ;) >> >> I've notified our admins. Please try again in a few hours. >> >> -Brad >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Fri Sep 23 03:03:37 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 23 Sep 2016 09:03:37 +0200 Subject: [cmake-developers] CPack [NSIS] Install directory per component In-Reply-To: References: Message-ID: <11B2F93C-843A-41A4-991F-BB8F2F4BAE65@gmx.at> Hello, I've attached a patch with which it is now possible to set custom install directories per component. Best Regards Roman > Am 21.09.2016 um 23:04 schrieb Roman W?ger : > > Hello, > > Per default the install directory for a > component is $INSTDIR. > > Is there a chance to change the install dir per component? > > Thanks > Roman > -- > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CPack-NSIS-custom-component-install-directory.patch Type: application/octet-stream Size: 5563 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Fri Sep 23 06:29:46 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Fri, 23 Sep 2016 10:29:46 +0000 Subject: [cmake-developers] [PATCH] preparations for native C# support Message-ID: <295a2badc7a641b59225c2a54ae9b6c5@DE013666.schaeffler.com> These are some minor changes for native support of C# targets. The remaining C++ implementation will go into the Visual Studio target 10 generator class. Best Regards Michael St?rmer -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-preparational-patches-for-CSharp-support.patch Type: application/octet-stream Size: 4078 bytes Desc: 0001-preparational-patches-for-CSharp-support.patch URL: From domen.vrankar at gmail.com Fri Sep 23 06:47:29 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 23 Sep 2016 12:47:29 +0200 Subject: [cmake-developers] Linux PGI compiler missing --build-id flag by default Message-ID: Hi all, I have rpm tests failing on dashboard [1] and it would seem that PGI compiler is missing --build-id flag by default which can be added [2] . Is this default behavior (missing --build-id flag) intended or simply missing from CMake? I'm guessing that this is a linker option (or do I also need a compiler flag?) so how do I add it only for this compiler? Which CMAKE_CXX_COMPILER_ID value should I compare to or should I use a different CMake variable? Thanks, Domen [1] https://open.cdash.org/testSummary.php?project=1&name=RunCMake.CPack_RPM&date=2016-09-22 [2] http://www.pgroup.com/userforum/viewtopic.php?p=11665&sid=330354c1739f0409fd1be6878830b457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Sep 23 08:08:35 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 23 Sep 2016 08:08:35 -0400 Subject: [cmake-developers] [PATCH] preparations for native C# support In-Reply-To: <295a2badc7a641b59225c2a54ae9b6c5@DE013666.schaeffler.com> References: <295a2badc7a641b59225c2a54ae9b6c5@DE013666.schaeffler.com> Message-ID: On 09/23/2016 06:29 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > These are some minor changes for native support of C# targets. > The remaining C++ implementation will go into the Visual Studio > target 10 generator class. Great! I'd like to wait until after the 3.7 branch to start introducing changes for a major new feature like this. That will be Oct 3. Please rebase this on 'master' after the branch and re-send after that. Thanks! -Brad From brad.king at kitware.com Fri Sep 23 08:33:14 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 23 Sep 2016 08:33:14 -0400 Subject: [cmake-developers] Linux PGI compiler missing --build-id flag by default In-Reply-To: References: Message-ID: On 09/23/2016 06:47 AM, Domen Vrankar wrote: > I have rpm tests failing on dashboard [1] and it would seem that PGI compiler > is missing --build-id flag by default which can be added [2] > > Is this default behavior (missing --build-id flag) intended or simply missing from CMake? > > I'm guessing that this is a linker option (or do I also need a compiler flag?) so how do > I add it only for this compiler? Which|CMAKE_CXX_COMPILER_ID value should I compare > to or should I use a different CMake variable? Is this flag needed in general or only for your test? Thanks, -Brad > [1] https://open.cdash.org/testSummary.php?project=1&name=RunCMake.CPack_RPM&date=2016-09-22 > [2] http://www.pgroup.com/userforum/viewtopic.php?p=11665&sid=330354c1739f0409fd1be6878830b457 From brad.king at kitware.com Fri Sep 23 08:44:49 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 23 Sep 2016 08:44:49 -0400 Subject: [cmake-developers] possible fix to include in release In-Reply-To: <88896737.13574526.1474572353354.JavaMail.zimbra@elemtech.com> References: <88896737.13574526.1474572353354.JavaMail.zimbra@elemtech.com> Message-ID: <49c48b83-e0cf-019e-183e-afeed42d3473@kitware.com> On 09/22/2016 03:25 PM, clinton at elemtech.com wrote: > If there is a CMake 3.6.3, I'd like to request the inclusion of > https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c I've merged it to the 'release' branch, but I don't think there will be a 3.6.3. We're freezing for 3.7.0 soon. > Some Linux distros are now shipping cmake-gui on top of Qt5, and the reported QFileDialog problem is present. > See also http://public.kitware.com/pipermail/cmake/2016-September/064262.html If necessary these distros can include this patch in their packaging. Thanks, -Brad From domen.vrankar at gmail.com Fri Sep 23 09:01:02 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 23 Sep 2016 15:01:02 +0200 Subject: [cmake-developers] Linux PGI compiler missing --build-id flag by default In-Reply-To: References: Message-ID: > On 09/23/2016 06:47 AM, Domen Vrankar wrote: > > I have rpm tests failing on dashboard [1] and it would seem that PGI > compiler > > is missing --build-id flag by default which can be added [2] > > > > Is this default behavior (missing --build-id flag) intended or simply > missing from CMake? > > > > I'm guessing that this is a linker option (or do I also need a compiler > flag?) so how do > > I add it only for this compiler? Which|CMAKE_CXX_COMPILER_ID value > should I compare > > to or should I use a different CMake variable? > > Is this flag needed in general or only for your test? > This is mandatory for rpm debug info packages but as far as I can tell it only serves for easier identification of binaries/shared libs for debugging and dump analysis... I was wondering if this is mandatory on Linux since I didn't even know until today that this option exists (seems to always be set with gcc/clang). If nobody else is missing this flag I'll just add the flag in 'if(CMAKE_CXX_COMPILER_ID MATCHES "PGI")' block for this test for now and explain it in CPackRPM docs. Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Sep 23 10:25:51 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 23 Sep 2016 10:25:51 -0400 Subject: [cmake-developers] Linux PGI compiler missing --build-id flag by default In-Reply-To: References: Message-ID: On 09/23/2016 09:01 AM, Domen Vrankar wrote: > If nobody else is missing this flag I'll just add the flag in > 'if(CMAKE_CXX_COMPILER_ID MATCHES "PGI")' block for this test > for now and explain it in CPackRPM docs. Sounds good. You should be able to use STREQUAL instead of MATCHES. Thanks, -Brad From charles.huet at gmail.com Fri Sep 23 10:30:14 2016 From: charles.huet at gmail.com (Charles Huet) Date: Fri, 23 Sep 2016 14:30:14 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> Message-ID: Ok, so I will focus on windows support for now. I squashed the commits correctly, to not lose the correct authors names, and I started moving all that I could from the global generator to a target generator, and simplified a few things along the way. If you want to take a quick glance it should be close to what you want, but there is still some work as I introduced a few regressions in the refactoring. Le jeu. 22 sept. 2016 ? 21:14, Brad King a ?crit : > On 09/22/2016 03:02 PM, Charles Huet wrote: > > is linux/mac support mandatory also ? > > Fastbuild does support those platforms, but the generator so far does > > not work as well (or at all) on those platforms. > > I think it is okay to support only a subset of platforms at first. > Please just make the generator error out early on a platform that is > not supported, or simply not even compile on such hosts. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Sep 23 10:52:15 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 23 Sep 2016 10:52:15 -0400 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> Message-ID: <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> On 09/23/2016 10:30 AM, Charles Huet wrote: > If you want to take a quick glance it should be close to what you want Did you push an update to the fastbuild-master branch? It looks the same. FYI, I'd like to wait until after the Oct 3 branch for the 3.7 release before introducing changes toward a major new feature. Therefore I likely won't have a chance to take a serious look at this until after that. -Brad From charles.huet at gmail.com Fri Sep 23 11:21:15 2016 From: charles.huet at gmail.com (Charles Huet) Date: Fri, 23 Sep 2016 15:21:15 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> Message-ID: Sorry I pushed on fastbuild-rebase, as the rebase on master fails evento self host. I did not expect this to be merged for 3.7, as I'm not sure I'll have time to polish it enough for release. On Fri, Sep 23, 2016, 16:52 Brad King wrote: > On 09/23/2016 10:30 AM, Charles Huet wrote: > > If you want to take a quick glance it should be close to what you want > > Did you push an update to the fastbuild-master branch? It looks the same. > > FYI, I'd like to wait until after the Oct 3 branch for the 3.7 release > before introducing changes toward a major new feature. Therefore I > likely won't have a chance to take a serious look at this until after > that. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dneto at google.com Fri Sep 23 18:17:25 2016 From: dneto at google.com (David Neto) Date: Fri, 23 Sep 2016 22:17:25 +0000 Subject: [cmake-developers] Adding GLSL to SPIR-V compilation support In-Reply-To: References: Message-ID: I've attached a patch to add GLSL language support, compiling down to SPIR-V. It's based on master from this morning. GLSL is the OpenGL Shading Language, used by OpenGL, OpenGL ES, and Vulkan graphics APIs. By convention, the recognized source file extensions are .vert, .tese, .tesc, .geom, .frag, and .comp corresponding to five stages in the graphics pipeline, and compute shaders. SPIR-V is a standardized hardware-independent intermediate language for shaders; basically an abstract machine language for GPUs. Vulkan drivers consume shaders in SPIR-V form. By convention its file extension is .spv The attached patch adds support for adding GLSL as a language, automatically resolving the open source "glslc" compiler. See https://github.com/google/shaderc/tree/master/glslc from https://github.com/google/shaderc The glslc compiler supports #include and -M style options for dependency generation. A test is included. I've tested it on a double-bootstrapped cmake on Linux, using Ninja. I've also manually verified dependency generation and checking with Ninja. Portions of the patch were derived from C++ compiler discovery, and Fortran support discovery for tests. Let me know if the patch is ok, or whether changes are required. I also have a subsequent patch to support the SPIR-V assembler (.spvasm -> .spv) but will wait until I've got this one right first. thanks, david -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-GLSL-to-SPIR-V-compilation.patch Type: application/octet-stream Size: 14452 bytes Desc: not available URL: From brad.king at kitware.com Mon Sep 26 09:59:08 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Sep 2016 09:59:08 -0400 Subject: [cmake-developers] Adding GLSL to SPIR-V compilation support In-Reply-To: References: Message-ID: On 09/23/2016 06:17 PM, David Neto via cmake-developers wrote: > I've attached a patch to add GLSL language support, compiling down to SPIR-V. > It's based on master from this morning. Thanks! We are currently experimenting with a GitLab workflow on https://gitlab.kitware.com/cmake/cmake but haven't updated CONTRIBUTING.rst yet. This change/feature is substantial enough to warrant review over there. Please submit a merge request on our GitLab for this. FYI, we're close to the Oct 3 freeze for the 3.7 release, so detailed review and integration of substantial features like adding a new language will likely be delayed until after that. Please rebase on `master` once post-3.7 development is announced. Thanks, -Brad From daniel at pfeifer-mail.de Mon Sep 26 10:07:45 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 26 Sep 2016 16:07:45 +0200 Subject: [cmake-developers] semantics of ctest_build(APPEND) Message-ID: Hi, the documentation of the ctest_build command states "Append semantics are defined by the dashboard server in use." I think this is not precise enough. The client side effect of APPEND is that CTest creates an Append="true" attribute in the XML. It does not append anything to the already existing file. The existing file is overwritten. For append to work as expected, it is necessary to call ctest_submit(PARTS Build) between the ctest_build commands. This is not documented. Cheers, Daniel From dneto at google.com Mon Sep 26 10:48:30 2016 From: dneto at google.com (David Neto) Date: Mon, 26 Sep 2016 14:48:30 +0000 Subject: [cmake-developers] Adding GLSL to SPIR-V compilation support In-Reply-To: References: Message-ID: Thanks for the quick reply. I completely understand the move to Gitlab; it's a much nicer flow. I've posted https://gitlab.kitware.com/cmake/cmake/merge_requests/124 for review. cheers, david On Mon, Sep 26, 2016 at 9:59 AM Brad King wrote: > On 09/23/2016 06:17 PM, David Neto via cmake-developers wrote: > > I've attached a patch to add GLSL language support, compiling down to > SPIR-V. > > It's based on master from this morning. > > Thanks! > > We are currently experimenting with a GitLab workflow on > > https://gitlab.kitware.com/cmake/cmake > > but haven't updated CONTRIBUTING.rst yet. This change/feature is > substantial enough to warrant review over there. Please submit a > merge request on our GitLab for this. > > FYI, we're close to the Oct 3 freeze for the 3.7 release, so detailed > review and integration of substantial features like adding a new > language will likely be delayed until after that. Please rebase > on `master` once post-3.7 development is announced. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Sep 26 10:55:22 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 26 Sep 2016 10:55:22 -0400 Subject: [cmake-developers] semantics of ctest_build(APPEND) In-Reply-To: References: Message-ID: <872329a9-b271-143d-ea92-b294d6235740@kitware.com> On 09/26/2016 10:07 AM, Daniel Pfeifer wrote: > the documentation of the ctest_build command states "Append semantics > are defined by the dashboard server in use." I think this is not > precise enough. > > The client side effect of APPEND is that CTest creates an > Append="true" attribute in the XML. It does not append anything to the > already existing file. The existing file is overwritten. > > For append to work as expected, it is necessary to call > ctest_submit(PARTS Build) between the ctest_build commands. This is > not documented. Yes. Please add this to anywhere in the documentation you expected to see it. Thanks, -Brad From florent.castelli at gmail.com Mon Sep 26 17:23:33 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Mon, 26 Sep 2016 23:23:33 +0200 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: On 12/09/2016 15:09, Brad King wrote: > On 09/09/2016 04:04 PM, Robert Dailey wrote: >> Currently nightly builds are tagged 3.6.2. Are there no nightly builds >> for 3.7 or am I missing something? > They are 3.6.2.$date, indicating post-3.6 feature development. > See the documentation of CMAKE_VERSION: > > https://cmake.org/cmake/help/v3.6/variable/CMAKE_VERSION.html > > -Brad Resurrecting this! I've seen that the Android Gradle build tools now have an official CMake plugin that has a custom 3.6 version with a custom toolchain and Android platform support. https://developer.android.com/ndk/guides/cmake.html#variables The problem is that they have a set of configuration options for their toolchain that is similar to what you have, but incompatible. Have you tried working it out with Google? Maybe dropping your implementation and integrate theirs as they released it first and started documenting it? I just don't want to have 2 toolchains to support, that would be really terrible :( /Orphis From dneto at google.com Mon Sep 26 17:50:30 2016 From: dneto at google.com (David Neto) Date: Mon, 26 Sep 2016 21:50:30 +0000 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: On Mon, Sep 26, 2016 at 5:23 PM Florent Castelli wrote: > > Have you tried working it out with Google? Maybe dropping your > implementation and integrate theirs as they released it first and > started documenting it? > > I just don't want to have 2 toolchains to support, that would be really > terrible :( > I agree. I work for Google but not in this area, and I don't know who is doing this support. I suspect this is just an accidental duplication of effort. I've pinged someone to see about finding the right person to coordinate with. david -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Sep 26 18:28:28 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 26 Sep 2016 18:28:28 -0400 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: <91d1ff4b-852b-65c5-6df8-fcf270ab4263@kitware.com> On 9/26/2016 5:50 PM, David Neto via cmake-developers wrote: > > I agree. I work for Google but not in this area, and I don't know who > is doing this support. I suspect this is just an accidental duplication > of effort. I've pinged someone to see about finding the right person to > coordinate with. Brad has been working with the team at Google. He can elaborate more tomorrow. Just wanted to let folks sleep easy tonight. :) -Bill From jh0822.kim at samsung.com Tue Sep 27 00:20:08 2016 From: jh0822.kim at samsung.com (=?UTF-8?B?SnVuZ2h5dW4gS2lt?=) Date: Tue, 27 Sep 2016 04:20:08 +0000 Subject: [cmake-developers] =?utf-8?q?=5BPATCH=5D_Sort_list_of_files_for_a?= =?utf-8?q?ux=5Fsource=5Fdirectory=28=29_and_file=28glob=2C*=29?= References: Message-ID: <313794036.271957.1474950008792.JavaMail.weblogic@ep2ml102b> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Sort-list-of-files-for-aux_source_directory-and-file.patch Type: application/octet-stream Size: 2385 bytes Desc: not available URL: From brad.king at kitware.com Tue Sep 27 07:51:25 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 27 Sep 2016 07:51:25 -0400 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> On 09/26/2016 05:50 PM, David Neto wrote: >> I just don't want to have 2 toolchains to support, that would be really terrible :( > > I work for Google but not in this area, and I don't know who is doing this support. > I suspect this is just an accidental duplication of effort. I have been in contact with them. They are aware of what CMake 3.7 will have and plan to port their toolchain files to take advantage of it. They can simply map their options to CMake's new equivalents. The two efforts were mostly orthogonal. CMake's side of the work makes toolchain files much simpler, but does not actually provide any toolchain files. The NDK's side of the work provides toolchain files that are aware of exactly what comes with the NDK. -Brad From brad.king at kitware.com Tue Sep 27 07:55:38 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 27 Sep 2016 07:55:38 -0400 Subject: [cmake-developers] [PATCH] Sort list of files for aux_source_directory() and file(glob, *) In-Reply-To: <313794036.271957.1474950008792.JavaMail.weblogic@ep2ml102b> References: <313794036.271957.1474950008792.JavaMail.weblogic@ep2ml102b> Message-ID: <4f1169d2-8995-0e32-5702-f867ba7e1ff0@kitware.com> On 09/27/2016 12:20 AM, Junghyun Kim wrote: > If aux_source_directory(. SRCS) or file(glob SRCS "*.c") is used > files in SRCS are not sorted. The file(GLOB) command sorts as of CMake 3.6: file: Sort GLOB results to make it deterministic (#14491) https://gitlab.kitware.com/cmake/cmake/commit/edcccde7 A similar change could be made to aux_source_directory, though there is little reason to use that ancient command these days. Also, the CMake documentation recommends against using file(GLOB) to collect sources. -Brad From dneto at google.com Tue Sep 27 10:05:20 2016 From: dneto at google.com (David Neto) Date: Tue, 27 Sep 2016 14:05:20 +0000 Subject: [cmake-developers] Android Support In-Reply-To: <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> Message-ID: Sounds good to me. Sorry if I caused concern. thanks david On Tue, Sep 27, 2016 at 7:51 AM Brad King wrote: > On 09/26/2016 05:50 PM, David Neto wrote: > >> I just don't want to have 2 toolchains to support, that would be really > terrible :( > > > > I work for Google but not in this area, and I don't know who is doing > this support. > > I suspect this is just an accidental duplication of effort. > > I have been in contact with them. They are aware of what CMake 3.7 will > have > and plan to port their toolchain files to take advantage of it. They can > simply > map their options to CMake's new equivalents. > > The two efforts were mostly orthogonal. CMake's side of the work makes > toolchain files much simpler, but does not actually provide any toolchain > files. > The NDK's side of the work provides toolchain files that are aware of > exactly > what comes with the NDK. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Tue Sep 27 11:28:27 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 27 Sep 2016 17:28:27 +0200 Subject: [cmake-developers] Android Support In-Reply-To: <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> Message-ID: <131CA254-9634-47FC-9886-F9298A5A4542@gmail.com> That?s great to know, thanks! Is there any plan on having their toolchain in CMake directly at some point? I?m afraid that even if they update their options to use the upstream support, they may not allow using those options directly and we?ll still have to support 2 toolchains. That?s especially true if you chose not to build with Gradle but a standalone CMake build (using upstream) and then don?t have access to their toolchain file. /Orphis > On 27 Sep 2016, at 13:51, Brad King wrote: > > On 09/26/2016 05:50 PM, David Neto wrote: >>> I just don't want to have 2 toolchains to support, that would be really terrible :( >> >> I work for Google but not in this area, and I don't know who is doing this support. >> I suspect this is just an accidental duplication of effort. > > I have been in contact with them. They are aware of what CMake 3.7 will have > and plan to port their toolchain files to take advantage of it. They can simply > map their options to CMake's new equivalents. > > The two efforts were mostly orthogonal. CMake's side of the work makes > toolchain files much simpler, but does not actually provide any toolchain files. > The NDK's side of the work provides toolchain files that are aware of exactly > what comes with the NDK. > > -Brad > From brad.king at kitware.com Tue Sep 27 11:39:05 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 27 Sep 2016 11:39:05 -0400 Subject: [cmake-developers] Android Support In-Reply-To: <131CA254-9634-47FC-9886-F9298A5A4542@gmail.com> References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> <131CA254-9634-47FC-9886-F9298A5A4542@gmail.com> Message-ID: On 09/27/2016 11:28 AM, Florent Castelli wrote: > Is there any plan on having their toolchain in CMake directly at some point? No. Their toolchain files are designed to be loaded from the NDK. They compute things relative to their own location and are meant to know exactly what is there. The whole point of a toolchain file is supposed to be to have information about the local machine that CMake can't know in general. They aren't supposed to be these huge files with tables of information common to the target platform and full of system introspection logic. CMake now has those tables so the toolchain files don't have to. With CMake 3.7 you shouldn't actually need a toolchain file from the NDK. In fact for simple cases you don't even need a toolchain file at all. -Brad From rcdailey.lists at gmail.com Tue Sep 27 12:23:21 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 27 Sep 2016 11:23:21 -0500 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> <131CA254-9634-47FC-9886-F9298A5A4542@gmail.com> Message-ID: On Tue, Sep 27, 2016 at 10:39 AM, Brad King wrote: > On 09/27/2016 11:28 AM, Florent Castelli wrote: >> Is there any plan on having their toolchain in CMake directly at some point? > > No. Their toolchain files are designed to be loaded from the NDK. They > compute things relative to their own location and are meant to know exactly > what is there. > > The whole point of a toolchain file is supposed to be to have information about > the local machine that CMake can't know in general. They aren't supposed to be > these huge files with tables of information common to the target platform and > full of system introspection logic. CMake now has those tables so the toolchain > files don't have to. > > With CMake 3.7 you shouldn't actually need a toolchain file from the NDK. > In fact for simple cases you don't even need a toolchain file at all. Brad, do you have a guide or walkthrough for the new CMake integration features of 3.7 that I can read? I'm actively developing using CMake + NDK and it's incredibly difficult to keep takanome's android-cmake toolchain file functional for newer versions of the NDK (specifically r11 and r12). Would love to see a tutorial on how it works for an out-of-the-box NDK setup. I'm not sure how much CMake has hard-coded the location of prebuilt toolchains and such on the NDK. As you pointed out, the toolchain is supposed to point to this stuff. Does CMake just need the ANDROID_NDK environment variable? Thanks in advance!! From brad.king at kitware.com Tue Sep 27 13:27:48 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 27 Sep 2016 13:27:48 -0400 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <29a9cc79-d015-6e73-0d7f-676f7072e76a@kitware.com> <131CA254-9634-47FC-9886-F9298A5A4542@gmail.com> Message-ID: <0dff7bdd-0060-cb26-56d3-df5800623a21@kitware.com> On 09/27/2016 12:23 PM, Robert Dailey wrote: > Brad, do you have a guide or walkthrough for the new CMake integration > features of 3.7 that I can read? It's documented in the cmake-toolchains(7) manual: https://cmake.org/cmake/help/git-master/manual/cmake-toolchains.7.html#cross-compiling-for-android > Would love to see a tutorial on how it works for an out-of-the-box NDK > setup. The basic usage is: ``` $ cmake ../src \ -DCMAKE_SYSTEM_NAME=Android \ -DCMAKE_SYSTEM_VERSION=21 \ -DCMAKE_ANDROID_NDK=/path/to/android-ndk ``` The ANDROID_NDK environment variable is among the documented ways to specify the path to the NDK instead of defining CMAKE_ANDROID_NDK. -Brad From jh0822.kim at samsung.com Tue Sep 27 20:07:19 2016 From: jh0822.kim at samsung.com (=?UTF-8?B?SnVuZ2h5dW4gS2lt?=) Date: Wed, 28 Sep 2016 00:07:19 +0000 Subject: [cmake-developers] =?utf-8?q?=5BPATCH=5D_Sort_list_of_files_for_a?= =?utf-8?q?ux=5Fsource=5Fdirectory=28=29_and_file=28glob=2C*=29?= References: <313794036.271957.1474950008792.JavaMail.weblogic@ep2ml102b> Message-ID: <20160928000719epcms1p6451ac6916edcef315001364cca976c2e@epcms1p6> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: From brad.king at kitware.com Wed Sep 28 07:50:38 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 28 Sep 2016 07:50:38 -0400 Subject: [cmake-developers] [PATCH] Sort list of files for aux_source_directory() and file(glob, *) In-Reply-To: <20160928000719epcms1p6451ac6916edcef315001364cca976c2e@epcms1p6> References: <313794036.271957.1474950008792.JavaMail.weblogic@ep2ml102b> <20160928000719epcms1p6451ac6916edcef315001364cca976c2e@epcms1p6> Message-ID: <7318529a-dad4-ce23-1a24-0149456aa4df@kitware.com> On 09/27/2016 08:07 PM, Junghyun Kim wrote: > 1) Add the same sort logic of the patch(#14491) to cmAuxSourceDirectoryCommand.cxx > 2) Apply my patch and remove the sort logic of patch #14491 Please patch cmAuxSourceDirectoryCommand.cxx directly. KWSys Directory is a low-level API whose clients may not all need sorting. Thanks, -Brad From ruslan_baratov at yahoo.com Wed Sep 28 16:09:40 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 28 Sep 2016 23:09:40 +0300 Subject: [cmake-developers] Remove RPATH on install Message-ID: <60c00d54-1ad4-e94c-8dae-dc68949dd8aa@yahoo.com> Hi, I want to link the library to all executables in project so I'm adding ` -Wl,-rpath,` to CMAKE_EXE_LINKER_FLAGS. That works fine however after install step this RPATH was not removed and full path to remains as part of executable in LC_RPATH. As far as I understand there is no such variable for now in CMake that holds the list of RPATH directories that need to be removed on install step. If it is true what about adding new one, like CMAKE_INSTALL_DELETE_RPATH? Just for the record is not a part of CMAKE_INSTALL_PREFIX or CMAKE_BINARY_DIR. Ruslo From brad.king at kitware.com Wed Sep 28 16:33:09 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 28 Sep 2016 16:33:09 -0400 Subject: [cmake-developers] CMake 3.7 feature freeze on 2016-10-03 In-Reply-To: <69df6fcf-a372-a99b-ef07-bfbe05c0d0b8@kitware.com> References: <69df6fcf-a372-a99b-ef07-bfbe05c0d0b8@kitware.com> Message-ID: <9542584c-07a6-39e9-02c6-f47387b66368@kitware.com> On 09/12/2016 09:10 AM, Brad King wrote: > The feature freeze in 'master' for CMake 3.7 will be on Oct 3, 2016. > I may announce a freeze in 'next' sometime in the preceding week so > that we can get any remaining dashboard trouble cleaned up. In order to get 'master' ready to branch for 3.7, 'next' is now frozen to new features. After 3.7 is branched I'll announce when post-3.7 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.7 * A few specific features that have been in progress for a while in their respective merge requests. I will handle such merges to 'next'. Thanks, -Brad From brad.king at kitware.com Wed Sep 28 16:34:21 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 28 Sep 2016 16:34:21 -0400 Subject: [cmake-developers] Remove RPATH on install In-Reply-To: <60c00d54-1ad4-e94c-8dae-dc68949dd8aa@yahoo.com> References: <60c00d54-1ad4-e94c-8dae-dc68949dd8aa@yahoo.com> Message-ID: On 09/28/2016 04:09 PM, Ruslan Baratov via cmake-developers wrote: > ` -Wl,-rpath,` to CMAKE_EXE_LINKER_FLAGS. That adds it in a way that hides its presence from CMake. CMake has its own way to specify RPATH entries in the build tree. It will replace the build-tree-only entries with install-tree-only entries (if any) during installation. Any entries it doesn't know about are assumed to be added by the toolchain and are thus preserved. If one uses target_link_libraries to link each executable explicitly to the shared library via absolute path to the library file then IIRC CMake will put the RPATH in the build tree for that and remove it on installation. > adding new one, like CMAKE_INSTALL_DELETE_RPATH? We don't actually define any kind of first-class RPATH-update operation. It is only an implementation detail that we edit the RPATH on installation. In principle the design is that there is a build tree RPATH and an install tree RPATH. On non-ELF platforms we actually need to re-run the linker to produce the install tree version. Therefore CMAKE_INSTALL_DELETE_RPATH would not fit within our model. Instead one could add a BUILD_RPATH target property with CMAKE_BUILD_RPATH variable that specifies additional entries to put in the build tree RPATH. This would be the build-tree equivalent to the INSTALL_PATH target property. -Brad From ruslan_baratov at yahoo.com Wed Sep 28 16:54:52 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 28 Sep 2016 23:54:52 +0300 Subject: [cmake-developers] Remove RPATH on install In-Reply-To: References: <60c00d54-1ad4-e94c-8dae-dc68949dd8aa@yahoo.com> Message-ID: <7916a554-ab63-215f-0c18-ab015bb3b8c7@yahoo.com> On 28-Sep-16 23:34, Brad King wrote: > On 09/28/2016 04:09 PM, Ruslan Baratov via cmake-developers wrote: >> ` -Wl,-rpath,` to CMAKE_EXE_LINKER_FLAGS. > That adds it in a way that hides its presence from CMake. CMake has its > own way to specify RPATH entries in the build tree. It will replace the > build-tree-only entries with install-tree-only entries (if any) during > installation. I'm not aware of any better ways to apply global settings for all targets without modifying CMakeLists.txt > Any entries it doesn't know about are assumed to be added > by the toolchain and are thus preserved. I can't save them because it's full path hence will be not relocatable. > > If one uses target_link_libraries to link each executable explicitly > to the shared library via absolute path to the library file then IIRC > CMake will put the RPATH in the build tree for that and remove it on > installation. Yep, I know. > >> adding new one, like CMAKE_INSTALL_DELETE_RPATH? > We don't actually define any kind of first-class RPATH-update operation. > It is only an implementation detail that we edit the RPATH on installation. > In principle the design is that there is a build tree RPATH and an install > tree RPATH. On non-ELF platforms we actually need to re-run the linker > to produce the install tree version. Therefore CMAKE_INSTALL_DELETE_RPATH > would not fit within our model. Ok > Instead one could add a BUILD_RPATH target property with CMAKE_BUILD_RPATH > variable that specifies additional entries to put in the build tree RPATH. > This would be the build-tree equivalent to the INSTALL_PATH target property. Should work too. I will do the tests and send a patch. Ruslo From michele.pagot at hotmail.it Wed Sep 28 19:18:33 2016 From: michele.pagot at hotmail.it (michele pagot) Date: Wed, 28 Sep 2016 23:18:33 +0000 Subject: [cmake-developers] cmake server mode Message-ID: I'm interested in the cmake server mode. I've started from https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ and then to https://github.com/steveire/CMake.git and finally to the cmake official git master branch as it seems e I rebuilt it from scratch on Windows trying both VS2010 and MinGW. With this second one, using gcc4.8. Everything seems fine as the build works as expected and the inline help report server mode with both compilers. >> c:\......\cmake\cmake_master\build\buils_vs2010\bin\Debug\cmake.exe -E > CMake Error: cmake version 3.6.20160928-g9a9b9 > Usage: c:\.......\cmake\cmake_master\build\buils_vs2010\bin\Debug\cmake.exe -E [arguments...] > Available commands: > capabilities - Report capabilities built into cmake in JSON format > chdir dir cmd [args...] - run command in a given directory > compare_files file1 file2 - check if file1 is same as file2 > copy ... destination - copy files to destination (either file or directory) > copy_directory ... destination - copy content of ... directories to 'destination' directory > copy_if_different ... destination - copy files if it has changed > echo [...] - displays arguments as text > echo_append [...] - displays arguments as text but no new line > env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]... > - run command in a modified environment > environment - display the current environment > make_directory ... - create parent and directories > md5sum ... - create MD5 checksum of files > remove [-f] ... - remove the file(s), use -f to force it > remove_directory dir - remove a directory and its contents > rename oldname newname - rename a file or directory (on one volume) > server - start cmake in server mode > sleep ... - sleep for given number of seconds but as I try to use it: >> cmake -E server > CMake Error: CMake was not built with server mode enabled > First issue: server reported in the help even if not included the new feature seems to be activated only if some special compiler capability are fulfilled. So I've changed compiler to gcc5.3 and now I'm even nor able to build due to errors like: [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.cxx.obj [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.obj c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx: In member function 'bool cmsys::SystemToolsPathCaseCmp::operator()(const string&, const string&) const': c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx:465:43: error: 'strcasecmp' was not declared in this scope return strcasecmp(l.c_str(), r.c_str()) < 0; ^ c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx: In static member function 'static bool cmsys::SystemTools::ComparePath(const string&, const string&)': c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx:4289:43: error: 'strcasecmp' was not declared in this scope return strcasecmp(c1.c_str(), c2.c_str()) == 0; ^ make[2]: *** [Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.obj] Error 1 make[1]: *** [Source/kwsys/CMakeFiles/cmsys.dir/all] Error 2 make: *** [all] Error 2 Fixed by: #endif #include #include #include #include #include c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive_read.c:825:1: error: conflicting types for 'archive_read_data' archive_read_data(struct archive *_a, void *buff, size_t s) ^ In file included from c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive_read.c:51:0: c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive.h:581:24: note: previous declaration of 'archive_read_data' was here __LA_DECL la_ssize_t archive_read_data(struct archive *, ^ make[2]: *** [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj] Error 1 make[1]: *** [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/all] Error 2 make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Thu Sep 29 00:55:13 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 29 Sep 2016 06:55:13 +0200 Subject: [cmake-developers] cmake server mode In-Reply-To: References: Message-ID: Hi Michele, cmake -E server mode will always trigger something in cmake, so the help will report that. I think it is nicer to report "Server mode unavailable" when somebody attempts to run "cmake -E server" when that is not available than to produce a "Unknown command". To check whether or not server mode is available you can run "cmake -E capabilities": That has a "serverMode" key with a boolean in its JSON output. Easy to parse:-) Gcc 4.8 should be new enough to enable it, there is only very light C++11 usage, but I admit that I am not sure about MSVC2010. Your build errors seem unrelated to server-mode. Best Regards, Tobias On Thu, Sep 29, 2016 at 1:18 AM, michele pagot wrote: > I'm interested in the cmake server mode. I've started from > https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ and > then to https://github.com/steveire/CMake.git and finally to the cmake > official git master branch as it seems e > > I rebuilt it from scratch on Windows trying both VS2010 and MinGW. With this > second one, using gcc4.8. Everything seems fine as the build works as > expected and > > the inline help report server mode with both compilers. > > >>> c:\......\cmake\cmake_master\build\buils_vs2010\bin\Debug\cmake.exe -E >> CMake Error: cmake version 3.6.20160928-g9a9b9 >> Usage: >> c:\.......\cmake\cmake_master\build\buils_vs2010\bin\Debug\cmake.exe -E >> [arguments...] >> Available commands: >> capabilities - Report capabilities built into cmake in JSON >> format >> chdir dir cmd [args...] - run command in a given directory >> compare_files file1 file2 - check if file1 is same as file2 >> copy ... destination - copy files to destination (either file or >> directory) >> copy_directory ... destination - copy content of ... >> directories to 'destination' directory >> copy_if_different ... destination - copy files if it has changed >> echo [...] - displays arguments as text >> echo_append [...] - displays arguments as text but no new line >> env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]... >> - run command in a modified environment >> environment - display the current environment >> make_directory ... - create parent and directories >> md5sum ... - create MD5 checksum of files >> remove [-f] ... - remove the file(s), use -f to force it >> remove_directory dir - remove a directory and its contents >> rename oldname newname - rename a file or directory (on one volume) >> server - start cmake in server mode >> sleep ... - sleep for given number of seconds > > > but as I try to use it: > >>> cmake -E server >> CMake Error: CMake was not built with server mode enabled >> > First issue: server reported in the help even if not included > > > the new feature seems to be activated only if some special compiler > capability are fulfilled. So I've changed compiler to gcc5.3 and now I'm > even nor able to build due to errors like: > > > [ 2%] Building CXX object > Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.cxx.obj > > [ 2%] Building CXX object > Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.obj > > c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx: In > member function 'bool cmsys::SystemToolsPathCaseCmp::operator()(const > string&, const string&) const': > > c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx:465:43: > error: 'strcasecmp' was not declared in this scope > > return strcasecmp(l.c_str(), r.c_str()) < 0; > > ^ > > c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx: In > static member function 'static bool cmsys::SystemTools::ComparePath(const > string&, const string&)': > > c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx:4289:43: > error: 'strcasecmp' was not declared in this scope > > return strcasecmp(c1.c_str(), c2.c_str()) == 0; > > ^ > > make[2]: *** [Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.obj] Error 1 > > make[1]: *** [Source/kwsys/CMakeFiles/cmsys.dir/all] Error 2 > > make: *** [all] Error 2 > > > > Fixed by: > > #endif > > #include > > #include > > #include > > #include > > #include > > > > > > > > > > > > c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive_read.c:825:1: > error: conflicting types for 'archive_read_data' > archive_read_data(struct archive *_a, void *buff, size_t s) > ^ > In file included from > c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive_read.c:51:0: > c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive.h:581:24: > note: previous declaration of 'archive_read_data' was here > __LA_DECL la_ssize_t archive_read_data(struct archive *, > ^ > make[2]: *** > [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj] > Error 1 > make[1]: *** > [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/all] Error 2 > make: *** [all] Error 2 > > > > -- > > 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 roman.wueger at gmx.at Fri Sep 30 02:43:46 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 30 Sep 2016 08:43:46 +0200 Subject: [cmake-developers] CPack [WiX] Customizations of individual features/components Message-ID: <1F9467E7-A7EE-4869-A68A-00F9AE92C601@gmx.at> Hello, I want to customize some with CPack generated *.wxs files. For example: directories.wxs is generated with only the TARGET_DIR. How can I add an additional directory in this file and use the newly added directory in the components (features.wxs)? I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it, but if so how? Thanks in advance Regards Roman From seblist at xwmw.org Fri Sep 30 05:38:35 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Fri, 30 Sep 2016 11:38:35 +0200 Subject: [cmake-developers] QtAutogen: Patches to allow empty .qrc files Message-ID: Hello again. There is a bug/limitation in AUTORCC for .qrc files that are valid but do not contain any file references. On occurrence of such a file cmake 3.6.2 silently stops _all_ further qrc file processing and generates an incomplete/invalid automoc target. Here are some small patches that fix the issue and add a test case. The patches based on the current git master branch. It would be nice if they could make it into 3.7. Best resgards, Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_3-6-2_autogen_patches_empty_qrc_v001.tar.gz Type: application/gzip Size: 2967 bytes Desc: not available URL: From nilsgladitz at gmail.com Fri Sep 30 06:53:52 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 30 Sep 2016 12:53:52 +0200 Subject: [cmake-developers] CPack [WiX] Customizations of individual features/components In-Reply-To: <1F9467E7-A7EE-4869-A68A-00F9AE92C601@gmx.at> References: <1F9467E7-A7EE-4869-A68A-00F9AE92C601@gmx.at> Message-ID: <67244edc-d6a0-6b03-cdf3-98a448fbba06@gmail.com> On 09/30/2016 08:43 AM, Roman W?ger wrote: > Hello, > > I want to customize some with CPack generated *.wxs files. > > For example: directories.wxs is generated with only the TARGET_DIR. TARGETDIR (no underscore) is always the one and only root-directory element [1]. > How can I add an additional directory in this file and use the newly added directory in the components (features.wxs)? > > I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it, but if so how? CPACK_WIX_PATCH_FILE can be used to add XML content to (some) existing elements. It can not be used to reorder or remove existing elements and can not be used to modify the attributes of existing elements. Nils [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa372064(v=vs.85).aspx From brad.king at kitware.com Fri Sep 30 10:17:22 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 30 Sep 2016 10:17:22 -0400 Subject: [cmake-developers] QtAutogen: Patches to allow empty .qrc files In-Reply-To: References: Message-ID: On 09/30/2016 05:38 AM, Sebastian Holtermann wrote: > Here are some small patches that fix the issue and add a test case. Thanks. I've applied the patches with minor tweaks: QtAutogen: Allow .qrc files that do not contain any file reference https://gitlab.kitware.com/cmake/cmake/commit/98b11f25 QtAutogen: Add test for empty qrc file https://gitlab.kitware.com/cmake/cmake/commit/bcafc399 QtAutogen: Use cmSystemTools::Error instead of std::cerr https://gitlab.kitware.com/cmake/cmake/commit/a189d019 -Brad From seblist at xwmw.org Fri Sep 30 11:56:13 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Fri, 30 Sep 2016 17:56:13 +0200 Subject: [cmake-developers] QtAutogen: Patches to allow empty .qrc files In-Reply-To: References: Message-ID: <9b4664af-dfd7-9c74-a772-3da0db8989b1@xwmw.org> Am 30.09.2016 um 16:17 schrieb Brad King: > On 09/30/2016 05:38 AM, Sebastian Holtermann wrote: >> Here are some small patches that fix the issue and add a test case. > > Thanks. I've applied the patches with minor tweaks: > > QtAutogen: Allow .qrc files that do not contain any file reference > https://gitlab.kitware.com/cmake/cmake/commit/98b11f25 > > QtAutogen: Add test for empty qrc file > https://gitlab.kitware.com/cmake/cmake/commit/bcafc399 > > QtAutogen: Use cmSystemTools::Error instead of std::cerr > https://gitlab.kitware.com/cmake/cmake/commit/a189d019 > > -Brad > Thanks. -Sebastian