[CMake] Creating package
Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb - The only way to overcome this was to downgrade cmake version 2.8.8 to 2.8.5. (I had to use following packages from ubuntu 11.10: cmake_2.8.5-1ubuntu1_amd64.deb cmake-data_2.8.5-1ubuntu1_all.deb cmake-qt-gui_2.8.5-1ubuntu1_amd64.deb libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb liblzma2_5.0.0-2_amd64.deb libxmlrpc-c3-0_1.16.32-0ubuntu4_amd64.deb libxmlrpc-core-c3-0_1.16.32-0ubuntu3_amd64.deb ) With this version the now created packages are ok. Regards Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb - The only way to overcome this was to downgrade cmake version 2.8.8 to 2.8.5. (I had to use following packages from ubuntu 11.10: cmake_2.8.5-1ubuntu1_amd64.deb cmake-data_2.8.5-1ubuntu1_all.deb cmake-qt-gui_2.8.5-1ubuntu1_amd64.deb libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb liblzma2_5.0.0-2_amd64.deb libxmlrpc-c3-0_1.16.32-0ubuntu4_amd64.deb libxmlrpc-core-c3-0_1.16.32-0ubuntu3_amd64.deb ) With this version the now created packages are ok. This is stange. There are not that many concerning CPackDeb between 2.8.5 and 2.8.8 beside the automatic fakeroot feature. Could you try to launch the following commands on the offending deb package. dpkg -I xyzzy.deb Here it comes: #dpkg -I lyx20-2.0.1-Linux.deb neues Debian-Paket, Version 2.0. Größe 15864390 Byte: control-Archiv= 48242 Byte. 277 Byte,10 Zeilen control 136151 Byte, 1743 Zeilen md5sums Package: lyx20 Version: 2.0.1 Section: devel Priority: optional Architecture: amd64 Depends: libenchant1c2a (= 1.6.0-0),libqtgui4 (= 4.4.3-0) Installed-Size: 52663 Maintainer: lyx-de...@lists.lyx.org Description: A WYSIWYM (What You See Is What You Mean) document processor dpkg -c xyzzy.deb This gives the standard tar ztvf output from data.tar.gz, could not see anything special there. One thing though is the definition of owner/group of all listed files. In the working version, this is kornel/kornel, in the bad version it is root/root; Would you be able to try with prebuilt cmake-2.8.8 from kitware: you can untar this archive http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz Yes, but I fear, it is not cmake but cpack. ... As I expected, replacing the cpack binary cured everything. The BIG difference is #ldd /mnt/usr2/src/cmake/cmake-2.8.8-Linux-i386/bin/cpack linux-gate.so.1 = (0xf7761000) libdl.so.2 = /lib/i386-linux-gnu/libdl.so.2 (0xf771d000) libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xf76f1000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754b000) /lib/ld-linux.so.2 (0xf7762000) while #ldd /usr/bin/cpack display 45 different shared libraries, among them also libarchive.so.12 = /usr/lib/x86_64-linux-gnu/libarchive.so.12 (0x7fd16c52e000) which I suspect to be the one creating trouble ... and use cmake with full path from there. (May be some ubuntu specific patch are playing behind our back??) Last but not least may be the automatic usage of fakeroot is the culprit, In order to check that could you 1) uninstall fakeroot (aptitude remove fakeroot) Sorry, this one has tried to remove 468 other packages while leaving also next 126 packages with unresolved dependencies. So I prefer not to follow. 2) re-run cmake 2.8.8 and check if the generated deb works or not. In the very end if all this fails you can provide us with a stripped down failing example. In any case if kitware pre-compiled binary failed you should file a bug report on the tracker. As I wrote, this one works. Erk Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko kor...@lyx.org Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb Anyway, this looks as like data.tar.gz were not ok. The package will be corrected, if I do following: mkdir tmp cp xyzzy.deb tmp cd tmp ar xv xyzzy.deb data.tar.gz tar xzvf data.tar.gz tar zcvf data.tgz ./usr mv data.tgz data.tar.gz ar rv xyzzy.deb data.tar.gz Now dpkg -i xyzzy.deb is working. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 22:02:19, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko kor...@lyx.org Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb Anyway, this looks as like data.tar.gz were not ok. The package will be corrected, if I do following: mkdir tmp cp xyzzy.deb tmp cd tmp ar xv xyzzy.deb data.tar.gz tar xzvf data.tar.gz tar zcvf data.tgz ./usr mv data.tgz data.tar.gz ar rv xyzzy.deb data.tar.gz Now dpkg -i xyzzy.deb is working. Ok then, could you try with cmake -E tar zcvf data.tgz ./usr instead. This one produces the same _bad_ tar file. The error output of #tar ztvf data.tgz /dev/null tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' Googling I found http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00734.html or this one http://public.kitware.com/Bug/view.php?id=11176 which looks more related. Following the last link to http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb266d is interesting too. I think I've seen some bug like this in the past I'll check the mailing list archive and the CMake bug tracker. Found it: http://www.cmake.org/Bug/view.php?id=8790 not really the same issue but who knows... I'll try to get my hand on an Ubuntu 12.04 box to check whether if I can reproduce the problem. This deserve a bug report to Ubuntu https://launchpad.net/cmake and may be we will get one for CMake when the ubuntu package maintainer get your report. I feared, you could propose something like this :) Erk Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard eric.noul...@gmail.com [ snip ] I understand the will of distro packager to build cmake using SYSTEM lib but (I think that) this cannot be tested on all system combination so may be they should do some regression testing when doing that. May be we can suggest that distros packager run a CMake dashboard with their own configuration problem with this being that they may apply patches that may triggers red flags which may not be upstream concerns... I am now in the process of compiling myself. The first compilation was ok. It works but has CMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=OFF ... Setting to ON, I get the same behaviour as previously in the ubuntu version. Since cpack is calling cmake -E tar ..., so we should change Source/cmArchiveWrite.cxx I suppose. But, cpack seems also to use libarchive. So the patch looks ok (on ubuntu) for cmake but not for cpack. Korneldiff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx index dc6b749..74586ec 100644 --- a/Source/cmArchiveWrite.cxx +++ b/Source/cmArchiveWrite.cxx @@ -123,9 +123,9 @@ cmArchiveWrite::cmArchiveWrite(std::ostream os, Compress c, Type t): } break; case TypeTAR: - if(archive_write_set_format_pax_restricted(this-Archive) != ARCHIVE_OK) + if(archive_write_set_format_gnutar(this-Archive) != ARCHIVE_OK) { -this-Error = archive_write_set_format_pax_restricted: ; +this-Error = archive_write_set_format_gnutar: ; this-Error += archive_error_string(this-Archive); return; } signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Sonntag, 27. Mai 2012 um 13:50:37, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/27 Kornel Benko kor...@lyx.org: Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard eric.noul...@gmail.com [ snip ] I understand the will of distro packager to build cmake using SYSTEM lib but (I think that) this cannot be tested on all system combination so may be they should do some regression testing when doing that. May be we can suggest that distros packager run a CMake dashboard with their own configuration problem with this being that they may apply patches that may triggers red flags which may not be upstream concerns... I am now in the process of compiling myself. The first compilation was ok. It works but has CMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=OFF ... Setting to ON, I get the same behaviour as previously in the ubuntu version. Which precisely shows that the libarchive from Ubuntu has something weird in it since the builtin version of libarchive which comes with CMake seems to work. Note that AFAIK, the libarchive in CMake source is a reduced (but unpatched) version of libarchive: /home/erk/workspace/CMake-gitted/Utilities/cmlibarchive/README-CMake.txt Since cpack is calling cmake -E tar ..., so we should change Source/cmArchiveWrite.cxx I suppose. No we can't do that, PAX format has been chosen on purpose because it was the most portable accross Linux, *BSD and other unices so we certainly don't wan't to default to gnutar since many system don't use gnutar as a default. But, cpack seems also to use libarchive. Like I said cpack uses libarchive but cpack DEB uses both libarchive and builtin BSD tar. So the patch looks ok (on ubuntu) for cmake but not for cpack. Like I said we certainly cannot accept that patch for upstream CMake. Nonetheless, do mean that with your patched Source/cmArchiveWrite.cxx version cmake -E tar is working but cpack DEB is not? I should have to investigate further. With this patch I have _no_ problems on ubuntu. If you are going to provide/discuss patch (I'm glad you do) may be we should switch to cmake-developers Mailing List (http://www.cmake.org/mailman/listinfo/cmake-developers) since many users may be afraid/annoyed by this kind of discussion. OK, will do. Another solution is to open a bug report on CMake bug tracker (I think that at this point you can do that) and we can discuss the issue and the solution there. Do not expect more answers from me today, I'll be off network until probably tomorrow. Erk Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE installing files instead of symbolic link
Am Dienstag, 26. Juni 2012 um 14:19:56, schrieb Eric Noulard eric.noul...@gmail.com 2012/6/26 vivek goel goelvivek2...@gmail.com: hi, I am building my custom library inside lib/linux/gcc/${BIT}/lib/ Currently I am using following command to install required library INSTALL(DIRECTORY lib/linux/gcc/${BIT}/lib/ DESTINATION lib FILES_MATCHING PATTERN *.so.* PATTERN icu EXCLUDE ) But it is not working. It is installing broken symbolic link. It is installing symbolic link like libicutu.so - libicutu.so.48.1 Which version of CMake are you using? Is the libicutu.so.48.1 installed or not? I would try with PATTERN *icu* EXCLUDE Where symbolic link is broken. Is there a way to copy original file instead as symbolic link using cmake? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Downgrade CMake
Am Mittwoch, 4. Juli 2012 um 05:05:48, schrieb vaibhavt tekamvaibha...@gmail.com I am running through same issue. I am working on a project, which is like one year old. I don't what cmake version was used in it. I am having cmake-2.8.8 installed in my macbook. When I try to run the project I get following error - make: *** No rule to make target `/opt/local/share/cmake-2.8/Modules/CMakeCCompiler.cmake.in', needed by `CMakeFiles/cmake.check_cache'. Stop. I think, may be its because of the different version(Just a random guess. I am really new to all these things.) So, I thought may be downgrading to same version might help. Any pointers? Somehow you are using _old_ CMakeCache.txt file. I would delete this file first and try again. Please. I am really stuck. Thanks. Regards, Vaibhav Tekam Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Downgrade CMake
Am Donnerstag, 5. Juli 2012 um 00:21:38, schrieb vaibhavt tekamvaibha...@gmail.com exists Somehow you are using _old_ CMakeCache.txt file. I would delete this file first and try again. Done. But still same error. Please check if /opt/local/share/cmake-2.8/Modules/CMakeCCompiler.cmake.in exists. If not, check if you can find CMakeCCompiler.cmake.in under some other path. Other path == cmake installation may be inconsistent (cmake-data belong to different cmake version) else == cmake installation may be incomplete (missing cmake-data) I would reinstall cmake (+ cmake-data) Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to define file access mode in file write function?
Am Mittwoch, 25. Juli 2012 um 04:17:18, schrieb hce jupiter@gmail.com Hi, How do you control the file access permission when using file(WRITE filename content)? The cmake 2.8.8 manual does not seem allow to specify access permission in file(WRITE ..). But install() does. Thank you. J Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Executable depending on all source files
Am Samstag, 25. August 2012 um 10:53:48, schrieb Russell Wallace russell.wall...@gmail.com I don't understand what you mean, but explicit listing violates DRY in a big way with the usual consequence, the two lists will inevitably get out of sync. I'd rather use globbing (unless CMake has some other method that doesn't involve trying to keep things in sync by hand)? Even plain Make can use globbing reliably. The you may want to try file(GLOB foo_sources . src/*.cc) add_executable(foo ${foo_sources}) On Sat, Aug 25, 2012 at 10:41 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Saturday 25 August 2012, Russell Wallace wrote: How do you specify that an executable depends on all source files in a directory? I've tried doing it like: add_executable(foo src/*.cc) but that only seems to pick up the first source file? Explicitely list all of them. Globbing is not good, cmake can't notice then when it has to rerun, and it may pick up stuff it shouldn't. Alex Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Executable depending on all source files
Am Samstag, 25. August 2012 um 12:04:21, schrieb Alexander Neundorf a.neundorf-w...@gmx.net On Saturday 25 August 2012, Russell Wallace wrote: I don't understand what you mean, but explicit listing violates DRY in a big way with the usual consequence, the two lists will inevitably get out of sync. Yes, but here this is good IMO, since in general a file laying around in some directory does not necessarily belong to the project. I'd rather use globbing (unless CMake has some other method that doesn't involve trying to keep things in sync by hand)? There is not much trying involved. You notice immediately if a file is missing in your CMakeLists.tx or if you list a file which does not exist. If a file is missing, you notice it in both cases. If you add a file (without touching CMakeLists.txt of course) you will not notice in both cases. Even plain Make can use globbing reliably. You can use file(GLOB ...), but it is not recommended. When a new file is added to a target, cmake needs to rerun, to generate the rules for building this file and to link the target. In the makefiles generated by cmake there is the dependency to rerun cmake when any of its input files have changed (e.g. when you added or removed a source file), but there is no rule to rerun cmake if anything in a directory has changed. So simply adding a file to a directory will not cause cmake to rerun automatically. By having to add that file explicitely to the CMakeLists.txt, cmake will rerun and you will always have a consistent build system. Alex Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] AC_C_RESTRICT
Hi, I am searching for something appropriate to the autoconf AC_C_RESTRICT macro. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AC_C_RESTRICT
Am Freitag, 4. Januar 2013 um 14:59:23, schrieb Mateusz Loskot mate...@loskot.net On 4 January 2013 14:46, Bill Hoffman bill.hoff...@kitware.com wrote: On 1/4/2013 9:24 AM, Mateusz Loskot wrote: It tests if C compiler supports C99 restrict keyword, perhaps also implementation-specific form, e.g. __restrict, etc. [1]http://en.wikipedia.org/wiki/Restrict Should be able to do it with a CheckCSourceCompiles: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#module:CheckCSourceCompiles Yup: CHECK_C_SOURCE_COMPILES ( int test (void *restrict x); int main (void) {return 0;} HAVE_RESTRICT) I implemented it now this way (used the autoconf macro as guide : # Check for restrict keyword # Builds the macro A_C_RESTRICT form automake foreach(ac_kw __restrict __restrict__ _Restrict restrict) check_cxx_source_compiles( typedef int * int_ptr; int foo (int_ptr ${ac_kw} ip) { return ip[0]; } int main(){ int s[1]; int * ${ac_kw} t = s; t[0] = 0; return foo(t); } RESTRICT) if(RESTRICT) set(ac_cv_c_restrict ${ac_kw}) break() endif() endforeach() if(RESTRICT) add_definitions(-Drestrict=${ac_cv_c_restrict}) else() add_definitions(-Drestrict=) endif() Thanks to all replies. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake is not getting installed
Am Montag, 28. Januar 2013 um 09:15:58, schrieb Pradeep Jha pradeep.kumar@gmail.com When I run the bootsrap command, it executes it successfully but gives me the following message at the end: Curses libraries were not found. Curses GUI for CMake will not be built. To compile, you need the devel-version of libncurses package. On your OS it may have slightly different name. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch utility is installed, but my ExternalProject build step fails to execute it
Am Sonntag, 24. Februar 2013 um 19:58:53, schrieb David Brown cypher...@gmail.com I'm trying to patch and build a Makefile-based project using the ExternalProject module. My patch command looks like this: PATCH_COMMAND patch -p1 -t -N ${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch When building, however, I get this: [ 10%] Performing patch step for 'IntelDFP' /bin/sh: 1: patch -p1 -t -N /home/david/Projects/db/IntelDFP.patch: not found I'm certain that the patch utility is installed and that the patch file path is correct. If I run that command myself, it works fine. So why does the CMake-generated Makefile fail to execute it? How should cmake know, that you do not mean a command with blanks in his path? Try PATCH_COMMAND patch -p1 -t -N ${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch or PATCH_COMMAND patch -p1 -t -N ${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Not resolving Symlinks at all
Am Dienstag, 26. Februar 2013 um 10:52:36, schrieb Michael Jackson mike.jack...@bluequartz.net I have the following code: message(STATUS Found HDFLibrary ${HDF5_LIBRARY_RELEASE}) if(IS_SYMLINK ${HDF_LIBRARY_DEBUG}) message(STATUS SYMLINK: ${HDF_LIBRARY_DEBUG}) get_filename_component(test ${HDF_LIBRARY_DEBUG} REALPATH) message(STATUS Real Path: ${test}) endif() if(IS_SYMLINK ${HDF_LIBRARY_RELEASE}) You surely mean ${HDF5_LIBRARY_RELEASE} here. message(STATUS SYMLINK: ${HDF_LIBRARY_RELEASE}) get_filename_component(test ${HDF_LIBRARY_RELEASE} REALPATH) message(STATUS Real Path: ${test}) endif() The issue is that I am not dropping into the IF(IS_SYMLINK) conditional. The HDF5_LIBRARY_RELEASE is /home/mjackson/DREAM3D_SDK/hdf5-1.8.10/lib/libhdf5.so and if we do an ls on the parent directory we get this: OK, but you ask for ${HDF_LIBRARY_RELEASE}, not for ${HDF5_LIBRARY_RELEASE} Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest git submodules
Am Donnerstag, 28. Februar 2013 um 07:07:52, schrieb Brad King brad.k...@kitware.com On 02/28/2013 02:38 AM, NoRulez wrote: But if I set the option: set(CTEST_GIT_UPDATE_OPTIONS --tags) Then I get the following error message: Update command failed: C:/Program Files/Git/cmd/git.cmd fetch --tags Maybe, you should set also the working directory for this command (source tree!). Isn't that the command you want? Perhaps it really fails. Try running it by hand from a command line. -Brad Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL CODE Error Results and Termination
Am Mittwoch, 13. November 2013 um 18:12:26, schrieb David Hauck dav...@netacquire.com Hello, I've been using several install (CODE EXECUTE_PROCESS ...) constructs in my top-level CMakeLists.txt file. However, I've been unable to capture/operate on any exit status of the embedded command. Unfortunately, documentation/searches haven't turned up any useful pointers. The closest I've come is a pointer in the following thread: http://www.cmake.org/pipermail/cmake/2011-July/045475.html However, I've not been able to sufficiently read between the lines to get this working. Does anyone have any thoughts on how to get something like the following working: install (CODE EXECUTE_PROCESS ( COMMAND ant ... WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}/java ERROR_VARIABLE _err Didn't you mean 'RESULT_VARIABLE' here? ) If (${_err}) MESSAGE( FATAL_ERROR \err: ${_err}\) endif ()) Thanks! -David Kornel signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL CODE Error Results and Termination
Am Mittwoch, 13. November 2013 um 18:41:03, schrieb David Hauck dav...@netacquire.com Hi Kornel, On Wednesday, November 13, 2013 10:26 AM, cmake-boun...@cmake.org wrote: Am Mittwoch, 13. November 2013 um 18:12:26, schrieb David Hauck dav...@netacquire.com Hello, I've been using several install (CODE EXECUTE_PROCESS ...) constructs in my top-level CMakeLists.txt file. However, I've been unable to capture/operate on any exit status of the embedded command. Unfortunately, documentation/searches haven't turned up any useful pointers. The closest I've come is a pointer in the following thread: http://www.cmake.org/pipermail/cmake/2011-July/045475.html However, I've not been able to sufficiently read between the lines to get this working. Does anyone have any thoughts on how to get something like the following working: install (CODE EXECUTE_PROCESS ( COMMAND ant ... WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}/java ERROR_VARIABLE _err Didn't you mean 'RESULT_VARIABLE' here? No, I really do mean ERROR_VARIABLE (unless, of course, this variable does not include the non-zero exit status of the EXECUTE_PROCESS command?). If you run 'cmake --help-command execute_process', you see: ... If RESULT_VARIABLE is given the variable will be set to contain the result of running the processes. This will be an integer return code from the last child or a string describing an error condition. ... So, if this is not 0, then you have an error condition. BTW, I'm still curious about the (dual 'code') construct generally. Specifically, if I do the following I never see the fatal error message (so I'm wondering if there's still something wrong regarding the scoping of the message command)? install (CODE EXECUTE_PROCESS ( COMMAND ant ... WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}/java ERROR_VARIABLE _err ) MESSAGE( FATAL_ERROR \err: ${_err}\) Never did this. When do you want to see the message? As I understand your code, only in call of cmake, e.g. at configuration time. Kornel signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Phony target for version 3.0
Trying to use phony target (working with 2.8.12) like add_custom_target(doc0 DEPENDS ${some_dep_files}) leads to error messages like: CMake Error: Could not get source file entry for builddir/CMakeFiles/doc0 Kornel signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Add libraries to end of compilation line ...
Am Donnerstag, 26. Juni 2014 um 20:12:12, schrieb Hendrik Sattler p...@hendrik-sattler.de Hi, you can also override the target_link_libraries function with your own in the top-level lists file and call the original one from within that function. This way you only have to edit one file. Nice idea, but how to call the original function from within? If I do that, I get a recursion into the overriding function. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Passing options into COMMAND inside of add_custom_target() or add_custom_command()
Am Samstag, 28. Juni 2014 um 12:06:56, schrieb Martin Mitáš m...@morous.org Hello, I'm trying to pass multiple options from outside to a command in add_custom_target() or add_custom_command(). I am new to CMake and I don't know whether the observed behavior is bug or I do it in a wrong way. I am doing all this with CMake 3.0 on Windows within MSYS environment if it plays some role. A test demonstrating the issue follows (using 'ls' as the command and '-l -h' as the options): # CMakeLists.txt === cmake_minimum_required(VERSION 3.0) project(test_project) set(MYTOOL ls) add_custom_target( x ALL COMMAND ${MYTOOL} ${MYTOOL_FLAGS} COMMENT test VERBATIM ) # End of CMakeLists.txt === Using the CMakeLists.txt above, I get this: $ mkdir buildcd build $ cmake -G MSYS Makefiles -DMYTOOL_FLAGS=-l -h .. ... (unimportant output censored) $ make VERBOSE=1 ... (unimportant output censored) [100%] test ls -l -h ls: invalid option -- So 'ls' got '-l -h' as one paramater. I would use 1.) -DMYTOOL_FLAGS=-lh or 2.) -DMYTOOL_FLAGS=-l;-h Try `ls --help' for more information. make[2]: *** [CMakeFiles/x] Error 2 make[2]: Leaving directory `/prj/pok/build' make[1]: *** [CMakeFiles/x.dir/all] Error 2 make[1]: Leaving directory `/prj/pok/build' make: *** [all] Error 2 As can be seen, CMake propagates the contents of ${MYTOOL_FLAGS} as a single option into 'ls', i.e. generated Makefile attempts to execute ls -l -h instead of ls -l -h Any ideas how to do this correctly? Thanks, Martin Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Passing options into COMMAND inside of add_custom_target() or add_custom_command()
Am Samstag, 28. Juni 2014 um 19:21:50, schrieb Hendrik Sattler p...@hendrik-sattler.de So 'ls' got '-l -h' as one paramater. I would use 1.) -DMYTOOL_FLAGS=-lh or 2.) -DMYTOOL_FLAGS=-l;-h Or maybe escaping on the shell as -DMYTOOL_FLAGS=-l -h also works? This is identical to -DMYTOOL_FLAGS=-l -h. The shell simply removes quotes. The command (in this case cmake) get this (as one) parameter '-DMYTOOL_FLAGS=-l -h' including the blank. So it should not work. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Autotools-CMake build error
Am Donnerstag, 28. August 2014 um 14:36:45, schrieb Richard Shaw hobbes1...@gmail.com I'm working on converting a project[1] from autotools to CMake and I've gotten a lot of it working. The project HEAVILY relies on values from a config.h but I think I've gotten the essentials covered although it took a while. Currently the build is failing on the following: [ 23%] Building CXX object src/CMakeFiles/fldigi.dir/widgets/FTextRXTX.cxx.o cd /home/build/tmp/build_fldigi/src /usr/lib64/ccache/c++ -DBUILD_FLDIGI -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/local/share/locale\ -DPKGDATADIR=\/usr/local/share\ -DUSE_HAMLIB -DUSE_PNG -DUSE_PORTAUDIO -DUSE_PULSEAUDIO -DUSE_SAMPLERATE -DUSE_SNDFILE -DUSE_X -Wall -ffast-math -finline-functions -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pthread -O3 -DNDEBUG -I/home/build/tmp/build_fldigi -I/home/build/git/fldigi/src/xmlrpcpp -I/home/build/git/fldigi/src/fileselector -I/home/build/git/fldigi/src/libtiniconv -I/home/build/git/fldigi/src/irrxml -I/home/build/git/fldigi/src/include -I/home/build/git/fldigi/src -I/usr/include/libpng16 -I/usr/include/alsa -I/home/build/tmp/build_fldigi/src -I/home/build/git/fldigi/src/flarq-src/include-o CMakeFiles/fldigi.dir/widgets/FTextRXTX.cxx.o -c /home/build/git/fldigi/src/widgets/FTextRXTX.cxx /home/build/git/fldigi/src/widgets/FTextRXTX.cxx:252:6: error: prototype for ‘void FTextRX::add(unsigned int, int)’ does not match any in class ‘FTextRX’ void FTextRX::add(unsigned int c, int attr) ^ In file included from /home/build/git/fldigi/src/include/fl_digi.h:34:0, from /home/build/git/fldigi/src/widgets/FTextRXTX.cxx:47: /home/build/git/fldigi/src/include/FTextRXTX.h:50:15: error: candidates are: virtual void FTextRX::add(const char*, int) virtual void add(const char *s, int attr = RECV) ^ /home/build/git/fldigi/src/include/FTextRXTX.h:49:15: error: virtual void FTextRX::add(unsigned char, int) virtual void add(unsigned char c, int attr = RECV); ^ --- end --- The automake line is: g++ -DHAVE_CONFIG_H -I. -DBUILD_FLDIGI -DLOCALEDIR=\/usr/share/locale\ -I. -I./include -I./irrxml -I./libtiniconv -I./fileselector -I./xmlrpcpp -DPKGDATADIR=\/usr/share/fldigi\ -pthread -I/usr/include/alsa -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT-D_REENTRANT -I/usr/include/libpng16 -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o fldigi-FTextRXTX.o `test -f 'widgets/FTextRXTX.cxx' || echo './'`widgets/FTextRXTX.cxx --- end --- Besides a lot of extra flags enforced by Fedora, I can't seem to find the essential difference between the two. Can someone point me in the right direction? I was going to put in a link to my remote branch at sourceforge but I'm not able to push to it right now Thanks, Richard [1] http://www.w1hkj.com/Fldigi.html You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'. Differences between generation of this file of automake/cmake? Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Autotools-CMake build error
Am Donnerstag, 28. August 2014 um 15:47:06, schrieb Richard Shaw hobbes1...@gmail.com On Thu, Aug 28, 2014 at 3:39 PM, Kornel Benko kor...@lyx.org wrote: You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'. Differences between generation of this file of automake/cmake? Could be but I think I found most of those. I tried browsing through the code and I didn't see any #if's that would affect what code is built but I can check again. If your compiler is g++, you could try '-g3 -E' options to create preprocessed output. E.g.: # cd /home/build/tmp/build_fldigi/src # g++ -g3 -E -DHAVE_CONFIG_H ... /home/build/git/fldigi/src/widgets/FTextRXTX.cxx FTextRXTX.i Thanks, Richard Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory
Am Donnerstag, 10. Dezember 2015 um 12:38:11, schrieb Nikita Barawade> > Hi, > > getting following error when trying to run LLAPI_TestApp > > ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot > open shared object file: No such file or directory > > Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind. > > > CMakeLists.txt for LLAPI_TestApp : > > > include_directories (../Include) > include_directories (../../LLAPI/Include) > > # collect all cpp files > file (GLOB ALL_SOURCES > "*.cpp") > > # Adds sources to the Solution Explorer > add_executable ( LLAPI_TestApp ${ALL_SOURCES}) > > target_link_libraries (LLAPI_TestApp LLAPI) > > install (TARGETS LLAPI_TestApp > RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind) > > set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ") > set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > Searched whole day on Internet but could not fix it . > > Pls guide > And where is your call to create the library? e.g. add_library(LLAPI ${lib_sources}) ? > Regards, > Nikita Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Babel Frage
Am Donnerstag, 12. Juli 2018 17:06:17 CEST schrieb Jürgen Spitzmüller : ... > > > > Ja, das steht in der Doku, stimmt aber nicht ganz. Akzeptiert wird > > z.B auch ngerman. > > Das übersetzt aber nicht die internen Makros. Siehe sr-vorl.cls: A-ha. Schade. Gruß Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Babel Frage
Am Freitag, 13. Juli 2018 11:54:45 CEST schrieb Kornel Benko : > Am Donnerstag, 12. Juli 2018 17:06:17 CEST schrieb Jürgen Spitzmüller > : > ... > > > > > > Ja, das steht in der Doku, stimmt aber nicht ganz. Akzeptiert wird > > > z.B auch ngerman. > > > > Das übersetzt aber nicht die internen Makros. Siehe sr-vorl.cls: > > A-ha. Schade. > > Gruß > Kornel > Sorry, wrong list. Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] General question about regex
Am Dienstag, 4. Juni 2019, 18:10:19 CEST schrieb Steven Truppe: > Hello again, > > > i've the following variable defined: > > set(WITH_LIB_GLAD_EXAMPLE_BASIC 1) > > And the if the line > > > foreach(_var VARIABLES) > > if(_var MATCHES "WITH_LIB_GLAD_EXAMPLE_([A-Za-z]+)") > > message(STATUS "Found a match") > > endforeach() > > > I never get the message "Found match", what am i doing wrong here ?? > > What about the attached? Kornel set(WITH_LIB_GLAD_EXAMPLE_BASIC 1) get_cmake_property(_variableNames VARIABLES) foreach(_var ${_variableNames}) message(STATUS "_var = ${_var}") if(_var MATCHES "WITH_LIB_GLAD_EXAMPLE_([A-Za-z]+)") message(STATUS "Found a match") endif() endforeach() signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] find_program doesn't use the PATH
Am Mittwoch, 31. Juli 2019, 12:19:48 CEST schrieb Braden McDaniel: > I was tempted to go ahead and file a bug on this; but it seems so basic > that I figure I must be missing something. > > Per the documentation for find_program: > >If NO_DEFAULT_PATH is not specified, the search process is as >follows: >⋮ >5. Search the standard system environment variables. This can be >skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument. > * PATH > That indicates to me that for "find_program(PROG_VAR NAME foo)", CMake > ought to find "foo" if "foo" is in the PATH. That doesn't seem to be > the case, though. A concrete example: > >cmake_minimum_required(VERSION 3.0) >cmake_policy(SET CMP0048 NEW) >project("hello" VERSION 0.1.0 LANGUAGES C) >find_program(GETTEXT_MSGMERGE_EXECUTABLE NAME msgmerge) The find_program() is searching something like "/usr/bin/NAME". "NAME" should be a placeholder. What you had in mind was probably the second form find_program(GETTEXT_MSGMERGE_EXECUTABLE NAMES msgmerge) Mark the string "NAMES". Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Welcome to June, time for the next release candidate
Am Montag, 4. Juni 2012 um 17:13:26, schrieb David Cole david.c...@kitware.com We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Thanks, David There is still the problem that created debian packages are not working with dpkg. System: ubuntu 12.04, 64 bit. Cmake: created with -DCMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=ON The following list of commands: # make package # create xyzz.deb # ar rv xyzz.deb data.tar.gz # tar ztvf data.tgz /dev/null tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' I already proposed a patch in the users list (using archive_write_set_format_gnutar() instead of archive_write_set_format_pax_restricted() in file Source/cmArchiveWrite.cxx) which make things work OK on this system. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Welcome to June, time for the next release candidate
Am Dienstag, 5. Juni 2012 um 10:11:40, schrieb Eric Noulard eric.noul...@gmail.com I already proposed a patch in the users list (using archive_write_set_format_gnutar() Discussion is in this thread: http://www.cmake.org/pipermail/cmake/2012-May/050483.html instead of archive_write_set_format_pax_restricted() in file Source/cmArchiveWrite.cxx) which make things work OK on this system. Hi Kornel, Like I said in the previous thread, we simply cannot switch to gnutar, it will potentially break many other systems. OK, I understood the hesitation. Moreover when you compiled the very same CMake using the shipped-in cmlibarchive you didn't get the error. So the issue is an interaction between system provided libarchive and CMake, did try to contact Ubuntu packager about that? You mean, I should press the ubuntu packager to use built-in libarchive, instead of using the the approved brand new libarchive version already there? What should I expect as an answer from them? My opinion is: this libarchive will (sooner or later) find it's way to other platforms as well, and also in cmake's own sources. We already reacted once (changing archive_write_set_format_ustar() to archive_write_set_format_pax_restricted()). Never mind, I did not want to be importunate ... Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Welcome to June, time for the next release candidate
Am Dienstag, 5. Juni 2012 um 08:37:37, schrieb Brad King brad.k...@kitware.com On Tue, Jun 5, 2012 at 8:17 AM, Eric Noulard eric.noul...@gmail.com wrote: 2012/6/5 Kornel Benko kor...@lyx.org: Somebody shall dive into the build process of the libarchive Ubuntu package and see **why** it breaks the CMake build while using cmlibarchive does not. This is the proper action. What version of libarchive is used from the system? The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: https://github.com/libarchive/libarchive/tree/28267d8f/ plus some portability fixes. On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Dont know what, if anything, they changed. This may-be a usage error on CMake side (and I'll try to help to fix it) but this may well be a mistake on libarchive/Ubuntu side as well. [snip] Yes but this action was widening the compatibility. pax_restricted -- gnutar may be narrowing it. This was discussed here: http://www.cmake.org/Bug/view.php?id=11958 Yes, this is very alike to what I see here. but many archive portability concerns were lifted by updating to a libarchive that included this: https://github.com/libarchive/libarchive/commit/de60ddd0 Still the SHILY.fflags were not handled ... The issue was resolved without changing formats by a fix suggested by a libarchive maintainer: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8558efa If there are extended headers that dpkg doesn't support then we need to know why they appear in the first place and which ones can be cleared. -Brad OK. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags (was: Welcome to June, time for the next release candidate)
Am Dienstag, 5. Juni 2012 um 13:19:31, schrieb Brad King brad.k...@kitware.com On 06/05/2012 08:57 AM, Kornel Benko wrote: The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Can you provide a simple script that reproduces a bad tarball using cmake -E tar when CMake is built against that libarchive, and a test to know if it is bad? If I can reproduce it I can bisect libarchive history. I don't have Ubuntu 12.04 but I do have dpkg. Thanks, -Brad It is really not so easy. I have a directory, which produces such a tar file. Even if I remove all files from that dir, the created tar is bad. It looks, like it would depend on initial number of entries (in my case 528). Maybe, if there are more than 128 ... have to check Ok, I created a dir with 340 entries. (330 entries was not enough). Kornel data.tgz Description: application/compressed-tar signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 15:35:15, schrieb Brad King brad.k...@kitware.com On 06/05/2012 01:19 PM, Brad King wrote: On 06/05/2012 08:57 AM, Kornel Benko wrote: The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Can you provide a simple script that reproduces a bad tarball using cmake -E tar when CMake is built against that libarchive, and a test to know if it is bad? If I can reproduce it I can bisect libarchive history. I don't have Ubuntu 12.04 but I do have dpkg. I'd still like a test case so I can reproduce the problem locally. However, there were very few changes between the two versions of libarchive, at least upstream: $ git rev-list --count 28267d8..v3.0.3 18 The only one that looks even remotely like it could affect the pax output is this: https://github.com/libarchive/libarchive/commit/bc523371 -Brad Maybe this version (3.0.2) is erroneous too. The last working version on ubuntu 11.10 was libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 16:43:15, schrieb Brad King brad.k...@kitware.com On 06/05/2012 03:55 PM, Kornel Benko wrote: Ok, I created a dir with 340 entries. (330 entries was not enough). Thanks. I see the header in the tarball you sent: $ tar xvzf ../data.tgz |wc -l tar: Ignoring unknown extended header keyword `SCHILY.fflags' 341 However, I cannot reproduce it. I built libarchive 3.0.3 from upstream and built CMake 2.8.8 against it: $ tar --version tar (GNU tar) 1.26 $ .../bin/cmake --version cmake version 2.8.8 $ ldd .../bin/cmake |grep libarchive libarchive.so.12 = .../lib/libarchive.so.12 (0x7fd4a999a000) $ strings .../lib/libarchive.so.12 |grep 3.0 libarchive 3.0.3 Same tar version here. I can create a tarball from the same directory extracted from yours and it has no trouble: Not nice, isn't it? $ .../bin/cmake -E tar cf xx.tar xx $ tar xvf xx.tar |wc -l 341 I can make a much bigger one without trouble too: $ for n in $(seq 1 4096); do echo $n xx/$n; done $ .../bin/cmake -E tar cf xx.tar xx $ tar xvf xx.tar |wc -l 4097 I can do this too, but only if explicitly called # cmake -E tar cf xx.tar xx/* == ok but # cmake -E tar cf xx.tar xx == error in xx.tar Is there any change in Ubuntu's package for libarchive that is not upstream? I don't know, but it would surprise me ... Maybe it is one of the underlying libs, like libattr.so.1 or libnettle.so.4 . This guessing makes me not happy. #ldd /usr/lib/x86_64-linux-gnu/libarchive.so.12.0.3 linux-vdso.so.1 = (0x7fff197ff000) libacl.so.1 = /lib/x86_64-linux-gnu/libacl.so.1 (0x7f693958a000) libattr.so.1 = /lib/x86_64-linux-gnu/libattr.so.1 (0x7f6939385000) liblzma.so.5 = /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x7f6939162000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f6938f52000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f6938d3b000) libxml2.so.2 = /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x7f69389df000) libnettle.so.4 = /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x7f69387b9000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f69383fc000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f69381de000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6937fda000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6937ce) /lib64/ld-linux-x86-64.so.2 (0x7f6939a5b000) This may also depend on the filesystem. EXT3 Are you using selinux? The selinux libraries are installed, but selinux and selinux-basics are not, so the answer should be no. -Brad Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 16:27:28, schrieb Brad King brad.k...@kitware.com On 06/05/2012 04:04 PM, Kornel Benko wrote: However, there were very few changes between the two versions of libarchive, at least upstream: $ git rev-list --count 28267d8..v3.0.3 Maybe this version (3.0.2) is erroneous too. The last working version on ubuntu 11.10 was libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb ...but wasn't it reported that building with the builtin cmlibarchive works? That is 3.0.2 plus a few changes (upstream commit 28267d8). Sorry, I was not aware of the version of the builtin cmlibarchive. I reported it. And yes, this was working. -Brad Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 17:11:47, schrieb Brad King brad.k...@kitware.com On 06/05/2012 04:43 PM, Brad King wrote: Is there any change in Ubuntu's package for libarchive that is not upstream? I traced through the source to see how SCHILY.fflags can ever be added to the archive. I think it depends on whether the HAVE_STRUCT_STAT_ST_FLAGS test is true when libarchive is built: https://github.com/libarchive/libarchive/blob/v3.0.3/libarchive/archive_read_disk_entry_from_file.c#L174 Try the patch below when building CMake against Ubuntu's libarchive. -Brad $ git diff |cat diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx index dc6b749..b410e44 100644 --- a/Source/cmArchiveWrite.cxx +++ b/Source/cmArchiveWrite.cxx @@ -240,6 +240,7 @@ bool cmArchiveWrite::AddFile(const char* file, // Clear acl and xattr fields not useful for distribution. archive_entry_acl_clear(e); archive_entry_xattr_clear(e); + archive_entry_set_fflags(e, 0, 0); if(archive_write_header(this-Archive, e) != ARCHIVE_OK) { this-Error = archive_write_header: ; This one works. But wait ... checking again without the patch ... ERROR You made it. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Mittwoch, 6. Juni 2012 um 07:38:44, schrieb Brad King brad.k...@kitware.com On Tue, Jun 5, 2012 at 5:46 PM, Kornel Benko kor...@lyx.org wrote: Try the patch below when building CMake against Ubuntu's libarchive. This one works. But wait ... checking again without the patch ... ERROR You made it. Thanks for testing: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a34015d3 -Brad Thanks for your patience. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Mittwoch, 6. Juni 2012 um 07:38:44, schrieb Brad King brad.k...@kitware.com On Tue, Jun 5, 2012 at 5:46 PM, Kornel Benko kor...@lyx.org wrote: Try the patch below when building CMake against Ubuntu's libarchive. This one works. But wait ... checking again without the patch ... ERROR You made it. Thanks for testing: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a34015d3 -Brad Hmm, may I ask, when it should (have been) be committed? I regularly check out the sources, but the change is still missing. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Montag, 11. Juni 2012 um 10:10:16, schrieb Brad King brad.k...@kitware.com On 06/11/2012 10:08 AM, Kornel Benko wrote: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a34015d3 Hmm, may I ask, when it should (have been) be committed? I regularly check out the sources, but the change is still missing. The topic is in the 'next' branch of the Git repo. We have weekly meetings, usually on Tuesday, to review and merge topics to 'master'. -Brad OK, thanks Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] current hugin not compilable ATM
Maybe forgotten to push Image.cpp and Image.h? ... [ 81%] Building CXX object src/hugin_cpfind/localfeatures/CMakeFiles/keypoints.dir/keypoints.cpp.o /usr/src/hugin/hugin_hg/src/hugin_cpfind/localfeatures/keypoints.cpp: In function ‘bool DetectKeypoints(const string, bool, double, lfeat::KeyPointPtr, bool, int, int, int, lfeat::KeypointWriter)’: /usr/src/hugin/hugin_hg/src/hugin_cpfind/localfeatures/keypoints.cpp:188:86: error: no matching function for call to ‘lfeat::Image::init(vigra::BasicImagedouble::iterator, int, int)’ /usr/src/hugin/hugin_hg/src/hugin_cpfind/localfeatures/keypoints.cpp:188:86: note: candidate is: /usr/src/hugin/hugin_hg/src/hugin_cpfind/./localfeatures/Image.h:41:10: note: void lfeat::Image::init(vigra::DImage) /usr/src/hugin/hugin_hg/src/hugin_cpfind/./localfeatures/Image.h:41:10: note: candidate expects 1 argument, 3 provided make[2]: *** [src/hugin_cpfind/localfeatures/CMakeFiles/keypoints.dir/keypoints.cpp.o] Error 1 make[1]: *** [src/hugin_cpfind/localfeatures/CMakeFiles/keypoints.dir/all] Error 2 make: *** [all] Error 2 ... Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] current hugin not compilable ATM
Am Sonntag, 17. Juni 2012 um 18:12:46, schrieb Eric Noulard eric.noul...@gmail.com 2012/6/17 Kornel Benko kor...@lyx.org: Maybe forgotten to push Image.cpp and Image.h? Looks like this mail end-up in the wrong list? This is cmke-developer ML? Looks like it belongs to Hugin ML? Or did I miss something? ... Ouch ... Yes ... Sorry Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Setting source property COMPILE_DEFINITIONS
Hi, I see a problem in setting the source property for a certain file, say x.cpp. set_property(SOURCE x.cpp APPEND COMPILE_DEFINITIONS XX=something) At first glance, this seems to work well, in that only x.cpp gets compiled with '-DXX=something'. Unfortunately, if something changes, the effect is, that _all_ sources in the relevant directory are recompiled. (I expected the recompilation of x.cpp only). This may depend on the build system. In my case Unix makefiles. The reason is that each object file created for this directory depends on flags.make, which changes accordingly. If one has hundreds of files in the source dir, this is less welcome. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Test unsuccessful for cmake version 2.8.10.20121108-gc31e1
Hi, running make test on the latest available cmake yields to the following ... Start 12: kwsys.testSystemInformation 13/272 Test #12: kwsys.testSystemInformation ..***Exception: SegFault 0.13 sec ... 99% tests passed, 1 tests failed out of 272 Label Time Summary: Label1= 0.04 sec Label2= 0.04 sec Total Test time (real) = 721.84 sec The following tests FAILED: 12 - kwsys.testSystemInformation (SEGFAULT) Errors while running CTest make: *** [test] Fehler 8 Exit 2 ... The system in ubuntu 12.04, 64-bit. Are there any log-files I should provide? This one ./Tests/SystemInformation/CMakeFiles/CMakeOutput.log is 149568 bytes long and contains 12 entries The output was: 0 The last lines (1355 to 1604) end with ... remove lib [gcc_s] remove lib [gcc] remove lib [gcc_s] remove lib [gcc] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6] == [/usr/lib/gcc/x86_64-linux-gnu/4.6] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu] == [/usr/lib/x86_64-linux-gnu] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib] == [/usr/lib] collapse dir [/lib/x86_64-linux-gnu] == [/lib/x86_64-linux-gnu] collapse dir [/lib/../lib] == [/lib] collapse dir [/usr/lib/x86_64-linux-gnu] == [/usr/lib/x86_64-linux-gnu] collapse dir [/usr/lib/../lib] == [/usr/lib] collapse dir [/usr/lib/gcc/x86_64-linux-gnu/4.6/../../..] == [/usr/lib] implicit libs: [stdc++;m;c] implicit dirs: [/usr/lib/gcc/x86_64-linux-gnu/4.6;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib] ... Regards Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test unsuccessful for cmake version 2.8.10.20121108-gc31e1
Am Donnerstag, 8. November 2012 um 09:47:55, schrieb Kornel Benko kor...@lyx.org Hi, running make test on the latest available cmake yields to the following ... Start 12: kwsys.testSystemInformation 13/272 Test #12: kwsys.testSystemInformation ..***Exception: SegFault 0.13 sec ... 99% tests passed, 1 tests failed out of 272 Label Time Summary: Label1= 0.04 sec Label2= 0.04 sec Total Test time (real) = 721.84 sec The following tests FAILED: 12 - kwsys.testSystemInformation (SEGFAULT) Errors while running CTest make: *** [test] Fehler 8 Exit 2 ... I traced it down to Source/kwsys/SystemInformation.cxx:1327 int fam=ifa-ifa_addr-sa_family; In my case, ifa-ifa_addr happens to be NULL. Changing this line to int fam=-1; if (ifa-ifa_addr) fam=ifa-ifa_addr-sa_family; cures it. Regards Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ctest on cmake build
Am Freitag, 17. Mai 2013 um 18:40:44, schrieb Rolf Eike Beer e...@sf-mail.de Kornel Benko wrote: Calling ctest after the last commit 5e993a2822e48c5d84b5bf01aad52ff5068cb5ea. The output is: ... Start 298: CMake.GetPrerequisites 298/299 Test #298: CMake.GetPrerequisites ... Passed0.67 sec Start 299: CMake.CheckSourceTree 299/299 Test #299: CMake.CheckSourceTree Passed0.08 sec 99% tests passed, 4 tests failed out of 299 Label Time Summary: Label1= 0.06 sec Label2= 0.06 sec Total Test time (real) = 757.62 sec The following tests FAILED: 258 - CTestTestMemcheckDummyPurify (Failed) 259 - CTestTestMemcheckDummyValgrind (Failed) 264 - CTestTestMemcheckDummyValgrindPrePost (Failed) 267 - CTestTestMemcheckDummyValgrindIgnoreMemcheck (Failed) Errors while running CTest ### This is on ubuntu 12.04, 64 bit. Should I send more info? Yes, please run that tests with -V and send me the output. Eike Sent privately. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ctest on cmake build
Am Freitag, 17. Mai 2013 um 19:59:14, schrieb Rolf Eike Beer e...@sf-mail.de Kornel Benko wrote: Calling ctest after the last commit 5e993a2822e48c5d84b5bf01aad52ff5068cb5ea. The output is: ... Start 298: CMake.GetPrerequisites 298/299 Test #298: CMake.GetPrerequisites ... Passed0.67 sec Start 299: CMake.CheckSourceTree 299/299 Test #299: CMake.CheckSourceTree Passed0.08 sec 99% tests passed, 4 tests failed out of 299 Label Time Summary: Label1= 0.06 sec Label2= 0.06 sec Total Test time (real) = 757.62 sec The following tests FAILED: 258 - CTestTestMemcheckDummyPurify (Failed) 259 - CTestTestMemcheckDummyValgrind (Failed) 264 - CTestTestMemcheckDummyValgrindPrePost (Failed) 267 - CTestTestMemcheckDummyValgrindIgnoreMemcheck (Failed) Errors while running CTest ### This is on ubuntu 12.04, 64 bit. Should I send more info? This error happens because the way these tests are configured is different from how they were before. Previously they had their source in the source dir, and their build in the build dir. But since the CMakeLists.txt and similar files of all these tests were nearly identical this has changed. Now the source tree is in the build dir and this tests do an in-source build there. You have used the same build dir before, and it still points to the (now gone) source location in the source tree. So just wipe the directories of these subtests (i.e. the stuff in /usr/BUILD/BuildCmakeGit/Tests/CTestTestMemcheck) and rerun these tests, they should work then. Eike I tried, but now even more tests are failing. I will try on really clean build tree. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ctest on cmake build
Am Freitag, 17. Mai 2013 um 20:34:45, schrieb Kornel Benko kor...@lyx.org Am Freitag, 17. Mai 2013 um 19:59:14, schrieb Rolf Eike Beer e...@sf-mail.de Kornel Benko wrote: Calling ctest after the last commit 5e993a2822e48c5d84b5bf01aad52ff5068cb5ea. The output is: ... Start 298: CMake.GetPrerequisites 298/299 Test #298: CMake.GetPrerequisites ... Passed0.67 sec Start 299: CMake.CheckSourceTree 299/299 Test #299: CMake.CheckSourceTree Passed0.08 sec 99% tests passed, 4 tests failed out of 299 Label Time Summary: Label1= 0.06 sec Label2= 0.06 sec Total Test time (real) = 757.62 sec The following tests FAILED: 258 - CTestTestMemcheckDummyPurify (Failed) 259 - CTestTestMemcheckDummyValgrind (Failed) 264 - CTestTestMemcheckDummyValgrindPrePost (Failed) 267 - CTestTestMemcheckDummyValgrindIgnoreMemcheck (Failed) Errors while running CTest ### This is on ubuntu 12.04, 64 bit. Should I send more info? This error happens because the way these tests are configured is different from how they were before. Previously they had their source in the source dir, and their build in the build dir. But since the CMakeLists.txt and similar files of all these tests were nearly identical this has changed. Now the source tree is in the build dir and this tests do an in-source build there. You have used the same build dir before, and it still points to the (now gone) source location in the source tree. So just wipe the directories of these subtests (i.e. the stuff in /usr/BUILD/BuildCmakeGit/Tests/CTestTestMemcheck) and rerun these tests, they should work then. Eike I tried, but now even more tests are failing. I will try on really clean build tree. On a clean rebuild all tests pass now. Thanks. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] dpkg-shlibdeps
I am using CPACK with set(CPACK_DEBIAN_PACKAGE_DEBUG ON) There is one offending output CPackDeb Debug: dpkg-shlibdeps version is Looking into CPackDeb.cmake, the regex for getting the version searches 'dpkg-shlibdeps version ([0-9]+\\.[0-9]+\\.[0-9]+)' from output of 'dpkg-shlibdeps --version'. But in my case (ubuntu 12.10), this is not matching, since the command returns 'Debian dpkg-shlibdeps Version 1.16.7. ...' Could the regex please be replaced by 'dpkg-shlibdeps [vV]ersion ([0-9]+\\.[0-9]+\\.[0-9]+)' ? This is cmake version 3.0.20140511-g17c650 Kornel signature.asc Description: This is a digitally signed message part. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] dpkg-shlibdeps
Am Montag, 19. Mai 2014 um 12:59:31, schrieb Nils Gladitz nilsglad...@gmail.com On 05/19/2014 12:50 PM, Kornel Benko wrote: I am using CPACK with set(CPACK_DEBIAN_PACKAGE_DEBUG ON) There is one offending output CPackDeb Debug: dpkg-shlibdeps version is Looking into CPackDeb.cmake, the regex for getting the version searches 'dpkg-shlibdeps version ([0-9]+\\.[0-9]+\\.[0-9]+)' from output of 'dpkg-shlibdeps --version'. But in my case (ubuntu 12.10), this is not matching, since the command returns 'Debian dpkg-shlibdeps Version 1.16.7. ...' Could the regex please be replaced by 'dpkg-shlibdeps [vV]ersion ([0-9]+\\.[0-9]+\\.[0-9]+)' ? This is cmake version 3.0.20140511-g17c650 Looks like the whole string is localized e.g. Norwegian: Debian %s versjon %s.\n. Yes, you are right. My localization was German. Perhaps the whole non numeric prefix should be skipped. +1 Nils Kornel signature.asc Description: This is a digitally signed message part. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [ANNOUNCE] CMake 3.0.0 Released.
Am Dienstag, 10. Juni 2014 um 17:14:31, schrieb Robert Maynard robert.mayn...@kitware.com On behalf of myself, Ken, Bill, Brad, David, Alex, Eike, Steve, Zach, Ben, Peter, Nils, and the rest of the CMake team from all around the world, we are pleased to announce that CMake 3.0.0 is now available for download at: http://www.cmake.org/files/v3.0/?C=M;O=D Running tests I got some errors: The following tests FAILED: 344 - RunCMake.CommandLine (Failed) 348 - CTestTestMemcheckDummyPurify (Failed) 349 - CTestTestMemcheckDummyValgrind (Failed) 354 - CTestTestMemcheckDummyValgrindPrePost (Failed) 357 - CTestTestMemcheckDummyValgrindIgnoreMemcheck (Failed) 395 - CMake.If (Failed) Errors while running CTest Test RunCMake.CommandLine: ... E_sleep-one-tenth - FAILED: actual-err Unknown sleep time format 0.1. Setting env LC_ALL=C, this test pass. The same is valid for the other memcheck tests. E.g. test CTestTestMemcheckDummyPurify (without setting LC_ALL): Test Fail Reason: Required regular expression not found.Regex=[ 1/1 MemCheck #1: RunCMake \.+ Passed +[0-9]+\.[0-9]+ sec ## The test 'CMake.If' fails with Guessing configuration NoConfig No tests were found!!!' ## Kornel signature.asc Description: This is a digitally signed message part. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [ANNOUNCE] CMake 3.0.0 Released.
Am Mittwoch, 11. Juni 2014 um 11:55:47, schrieb Nils Gladitz nilsglad...@gmail.com On 11.06.2014 10:52, Kornel Benko wrote: Am Dienstag, 10. Juni 2014 um 17:14:31, schrieb Robert Maynard robert.mayn...@kitware.com On behalf of myself, Ken, Bill, Brad, David, Alex, Eike, Steve, Zach, Ben, Peter, Nils, and the rest of the CMake team from all around the world, we are pleased to announce that CMake 3.0.0 is now available for download at: http://www.cmake.org/files/v3.0/?C=M;O=D Running tests I got some errors: The following tests FAILED: 344 - RunCMake.CommandLine (Failed) 348 - CTestTestMemcheckDummyPurify (Failed) 349 - CTestTestMemcheckDummyValgrind (Failed) 354 - CTestTestMemcheckDummyValgrindPrePost (Failed) 357 - CTestTestMemcheckDummyValgrindIgnoreMemcheck (Failed) 395 - CMake.If (Failed) Errors while running CTest Were you testing git master rather than 3.0? Master. Sorry for my ignorance. The issues seem to have been introduced by 5d360f23fa5616004ffa813914336e5810d1f42b. Which is not in 3.0. Nils Kornel signature.asc Description: This is a digitally signed message part. -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Missing CPACK_PACKAGE_CONTACT in test for CPackComponentsPrefix
Hi, testing new cmake, I get ctest error for the call # ctest -R CPackComponentsPrefix This is the relevant part in LastTest.log ... CPack: Install projects CPack: - Run preinstall target for: CPackComponentsPrefix CPack: - Install project: CPackComponentsPrefix CPack: Create package CMake Error at /usr/src/cmake/cmake/Modules/CPackDeb.cmake:386 (message): CPackDeb: Debian package requires a maintainer for a package, set CPACK_PACKAGE_CONTACT or CPACK_DEBIAN_PACKAGE_MAINTAINER Call Stack (most recent call first): /usr/src/cmake/cmake/Modules/CPackDeb.cmake:507 (cpack_deb_prepare_package_vars) CPack Error: Error while execution CPackDeb.cmake ... Adding line set(CPACK_PACKAGE_CONTACT someContact) in Tests/CPackComponentsPrefix/CMakeLists.txt cures the testcase for me. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Wrong cxx-extension flags
I have 2 compilers installed. The attached minimal CMakeLists.txt example shows everything OK if using the compiler at standard place. -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11 -- Configuring done -- Generating done -- Build files have been written to: /usr2/kornel/tmp/cmake But setting for alternative compiler (on clean build dir) env{CXX} => /usr/local/gcc6.1/bin/g++ env{CC} => /usr/local/gcc6.1/bin/gcc I get following output: -- The C compiler identification is GNU 6.1.0 -- The CXX compiler identification is GNU 6.1.0 -- Check for working C compiler: /usr/local/gcc6.1/bin/gcc -- Check for working C compiler: /usr/local/gcc6.1/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/local/gcc6.1/bin/g++ -- Check for working CXX compiler: /usr/local/gcc6.1/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11 -- Configuring done -- Generating done -- Build files have been written to: /usr2/kornel/tmp/cmake I expected here "-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=c++14". My cmake version is "cmake version 3.6.20160714-ga6bd0" Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Wrong cxx-extension flags
Am Donnerstag, 14. Juli 2016 um 13:35:06, schrieb Brad King <brad.k...@kitware.com> > On 07/14/2016 01:13 PM, Kornel Benko wrote: > > -- The CXX compiler identification is GNU 6.1.0 > > -- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=gnu++11 > > I expected here "-- CMAKE_CXX11_EXTENSION_COMPILE_OPTION = -std=c++14". > > That is the option for C++11 with extensions. See > CMAKE_CXX14_EXTENSION_COMPILE_OPTION for C++14 with extensions. > Both of these are internal table entries for CMake's generators > and not meant for direct use by projects. > > What are you actually trying to do? > > -Brad I was trying to compile lyx with QT5.7. The effect was, that the compilation failed. Searching for a reason I found that the flags in the flag.cmake files were mismatched. Here one example: # CMAKE generated file: DO NOT EDIT! # Generated by "Unix Makefiles" Generator, CMake Version 3.6 # compile CXX with /usr/local/gcc6.1/bin/g++ CXX_FLAGS = -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing -O0 -g3 -D_DEBUG -DBOOST_USER_CONFIG="" -fPIC --std=gnu++11 ... Therefore I started searching, where the extra ' --std=gnu++11' came from, and found it in Modules/Compiler/GNU-CXX.cmake. To verify, I made the output of this variable. To be clear, I did not want to do anything with the variable CMAKE_CXX14_EXTENSION_COMPILE_OPTION. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Wrong cxx-extension flags
Am Donnerstag, 14. Juli 2016 um 14:36:43, schrieb Brad King> In lyx I see the > > development/cmake/modules/FindCXX11Compiler.cmake I had to reread. Yes, I know this file too. There is set the '-std=c++14'. But I am asking about '-std=gnu++11'. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Wrong cxx-extension flags
Am Donnerstag, 14. Juli 2016 um 14:36:43, schrieb Brad King <brad.k...@kitware.com> > On 07/14/2016 01:59 PM, Kornel Benko wrote: > > I was trying to compile lyx with QT5.7. > > ... > > found that the flags in the flag.cmake files were mismatched. > > > > Therefore I started searching, where the extra ' --std=gnu++11' came > > from, and found it in Modules/Compiler/GNU-CXX.cmake. > > It appears there but only in a table. Other settings are required > to get the table entry to be used. See the CXX_STANDARD target > property: > > https://cmake.org/cmake/help/v3.6/prop_tgt/CXX_STANDARD.html > > Unless you or the project is setting that (perhaps via the > CMAKE_CXX_STANDARD variable) then CMake won't add any flags. > > In lyx I see the > > development/cmake/modules/FindCXX11Compiler.cmake No, this file is only used for QT4. The new cmake-files from QT5.7 are somehow responsible that this happens. If I compile with QT5.6 (which also has files like Qt5CoreConfig.cmake) no such problem occurs. > source file that adds such flags. Please ask them about it. I know, I am one of the creators. But, as already said, this is not the case here. > -Brad Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Wrong cxx-extension flags
Am Donnerstag, 14. Juli 2016 um 15:27:00, schrieb Brad King <brad.k...@kitware.com> > On 07/14/2016 02:48 PM, Kornel Benko wrote: > > I am asking about '-std=gnu++11'. > On 07/14/2016 02:45 PM, Kornel Benko wrote: > > The new cmake-files from QT5.7 are somehow responsible that this happens. > > The file `lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake` in Qt 5.7 contains: > > set_property(TARGET Qt5::Core PROPERTY INTERFACE_COMPILE_FEATURES > cxx_decltype) > > This tells CMake that dependents of this library need to be compiled as > at least C++11. This causes `-std=gnu++11` to be added automatically. Thanks Brad, that was what I was searching for. > What you can do is not add your own flag and instead do > > set(CMAKE_CXX_STANDARD 14) > > or set the CXX_STANDARD property of specific targets. That tells CMake > to build as C++14 so it will add -std=gnu++14. If you don't want the > extensions then also set > > set(CMAKE_CXX_EXTENSIONS OFF)l I did this, as it seemed least invasive. But now, instead of '-std=gnu++1' I got '-std=c++11' which is not better. Of course, since QT5.7 explicitly requires C++11 features, we don't need C++14. > Relevant docs: > > https://cmake.org/cmake/help/v3.6/manual/cmake-compile-features.7.html > https://cmake.org/cmake/help/v3.6/variable/CMAKE_CXX_STANDARD.html > https://cmake.org/cmake/help/v3.6/variable/CMAKE_CXX_EXTENSIONS.html > > -Brad Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Wrong cxx-extension flags
Am Donnerstag, 14. Juli 2016 um 16:06:17, schrieb Brad King <brad.k...@kitware.com> > On 07/14/2016 03:59 PM, Kornel Benko wrote: > >> What you can do is not add your own flag and instead do > >> > >> set(CMAKE_CXX_STANDARD 14) > >> set(CMAKE_CXX_EXTENSIONS OFF) > > > > I did this, as it seemed least invasive. > > But now, instead of '-std=gnu++1' I got '-std=c++11' which is not better. > > Of course, since QT5.7 explicitly requires C++11 features, we don't need > > C++14. > > I don't quite follow here. What flag to you want to get? I meant we don't need to test for c++14. > Don't add your own flag explicitly. Some combination of > the above settings can get the flag you need. I have to stick also with older cmake versions, so bear with me. Nonetheless, I tested some combinations already, and it all looks good. > -Brad Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Problem with created debian package
All of sudden, cmake(cpack) started producing wrong debian packages for one project. This is the output of debian package manager: dpkg: warning: downgrading lyx24 from 2.4.0-50424git-g3a4b233 to 2.4.0-50422git-gd6fb2ab (Reading database ... 422667 files and directories currently installed.) Preparing to unpack lyx24-2.4.0-50422git-Linux.deb ... Unpacking lyx24 (2.4.0-50422git-gd6fb2ab) over (2.4.0-50424git-g3a4b233) ... dpkg: error processing archive lyx24-2.4.0-50422git-Linux.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: lyx24-2.4.0-50422git-Linux.deb Analysing the data.tar.gz gives no hint. What helps is a sequence of commands using the system's 'tar'. # ar xv lyx24-2.4.0-50422git-Linux.deb data.tar.gz # sudo tar axf data.tar.gz # tar cf data.tar ./usr # gzip -f data.tar # ar rv lyx24-2.4.0-50422git-Linux.deb data.tar.gz Now everything is OK. Other projects do not show this behaviour. This is cmake 3.10.20171229-g3e1f5b11, but the same happens with earlier version. Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Problem with created debian package
Am Freitag, 29. Dezember 2017 um 22:25:53, schrieb Domen Vrankar <domen.vran...@gmail.com> > 2017-12-29 14:20 GMT+01:00 Kornel Benko <kor...@lyx.org>: > > > All of sudden, cmake(cpack) started producing wrong debian packages for > > one project. > > > > Did the project change in some way or was it the packaging environment that > changed? > I'd like to know a bit more details even if the solution below works to > determine if this was a regression in CPack or something else. Not that I were aware of. > > > This is the output of debian package manager: > > > > dpkg: warning: downgrading lyx24 from 2.4.0-50424git-g3a4b233 to > > 2.4.0-50422git-gd6fb2ab > > (Reading database ... 422667 files and directories currently > > installed.) > > Preparing to unpack lyx24-2.4.0-50422git-Linux.deb ... > > Unpacking lyx24 (2.4.0-50422git-gd6fb2ab) over > > (2.4.0-50424git-g3a4b233) ... > > dpkg: error processing archive lyx24-2.4.0-50422git-Linux.deb > > (--install): > > corrupted filesystem tarfile - corrupted package archive > > dpkg-deb: error: subprocess paste was killed by signal (Broken > > pipe) > > Errors were encountered while processing: > > lyx24-2.4.0-50422git-Linux.deb > > > > Analysing the data.tar.gz gives no hint. What helps is a sequence of > > commands using the system's 'tar'. > > > > # ar xv lyx24-2.4.0-50422git-Linux.deb data.tar.gz > > # sudo tar axf data.tar.gz > > # tar cf data.tar ./usr > > # gzip -f data.tar > > # ar rv lyx24-2.4.0-50422git-Linux.deb data.tar.gz > > > > Now everything is OK. > > Other projects do not show this behaviour. > > This is cmake 3.10.20171229-g3e1f5b11, but the same happens with earlier > > version. > > > > I'm surprised that this fixed the problem but from what you're describing > I'd say that some paths in the data tarball are too long for the paxr > version of tar to handle correctly (this is the default tar that is used by > CPack and debian packages as it is the most portable one). > If I'm right you could: > > 1) shorten the file paths in the archive > 2) use gnu tar instead by setting CPACK_DEBIAN_ARCHIVE_TYPE to gnutar Thanks, this is really nice. Meanwhile I found out what was going wrong. The package manager seems to not understand the way some filenames containing non-ascii chars are coded by cpack. I prepared a minimal example showing the effect here. 1.) Create a dir and copy the attached to it 2.) mkdir build; cd bild 3.) cmake .. -DCPACK_BINARY_DEB:BOOL=ON 4.) sudo dpkg -i wrongfilename-0.1.1-Linux.deb (Reading database ... 422665 files and directories currently installed.) Preparing to unpack wrongfilename-0.1.1-Linux.deb ... Unpacking wrongfilename (0.1.1) ... dpkg: error processing archive wrongfilename-0.1.1-Linux.deb (--install): corrupted filesystem tarfile - corrupted package archive Errors were encountered while processing: wrongfilename-0.1.1-Linux.deb > See > https://cmake.org/cmake/help/v3.10/module/CPackDeb.html#variable:CPACK_DEBIAN_ARCHIVE_TYPE > > Regards, > Domen Kornel signature.asc Description: This is a digitally signed message part. cmake_minimum_required(VERSION 2.6.4) project(wrongfilename) set(FN "novýsúbor.txt") install(FILES ${FN} DESTINATION "share") set(CPACK_PACKAGE_CONTACT "Kornel.Benko") include(CPack) -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Moc-test errors
Am Dienstag, 4. Juni 2019, 15:16:43 CEST schrieb Sebastian Holtermann: > Hello Kornel. > > > Recent tries to test cmake yield to errors for following tests: > > 582 - Qt5Autogen.MocIncludeRelaxed (Failed) > > 583 - Qt5Autogen.MocIncludeStrict (Failed) > > 584 - Qt5Autogen.MocSkipSource (Failed) > > > > Compiled master branch of http://cmake.org/cmake.git > > > > As en example, here the log-snippet for Qt5Autogen.MocIncludeRelaxed: > > > > [ 75%] Linking CXX executable mocIncludeRelaxed > > CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: > > In function `SObjCExtra::qt_static_metacall(QObject*, QMetaObject::Call, > > int, void**)': > > SObjCExtra.cpp:(.text+0x134): multiple definition of > > `SObjCExtra::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)' > > CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xa3a): > > first defined here > > CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o:(.data.rel.ro+0x0): > > multiple definition of `SObjCExtra::staticMetaObject' > > CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:(.data.rel.ro+0x2c0): > > first defined here > > CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: > > In function `SObjCExtra::metaObject() const': > > SObjCExtra.cpp:(.text+0x14a): multiple definition of > > `SObjCExtra::metaObject() const' > > CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xa50): > > first defined here > > CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: > > In function `SObjCExtra::qt_metacast(char const*)': > > SObjCExtra.cpp:(.text+0x192): multiple definition of > > `SObjCExtra::qt_metacast(char const*)' > > CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xa98): > > first defined here > > CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: > > In function `SObjCExtra::qt_metacall(QMetaObject::Call, int, void**)': > > SObjCExtra.cpp:(.text+0x1e2): multiple definition of > > `SObjCExtra::qt_metacall(QMetaObject::Call, int, void**)' > > CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xae8): > > first defined here > > collect2: error: ld returned 1 exit status > > We changed the format of AutogenInfo.cmake lately. > Possibly old versions of AutogenInfo.cmake files were left from > previous CMake builds and tests. > > Please try > - `make rebuild_cache` and run the tests again or > - do a clean build of the master branch and test again. > > -Sebastian Sure, rebuild_cache was the first I tried. The test-errors remain even in the master tree of today. Performing now on a clean build ... #ctest -R Qt5Autogen.Moc Test project /BUILD/BUILDMint18/BuildCmakeGit Guessing configuration NoConfig Start 553: Qt5Autogen.MocOnly 1/8 Test #553: Qt5Autogen.MocOnly ... Passed2.04 sec Start 554: Qt5Autogen.MocOptions 2/8 Test #554: Qt5Autogen.MocOptions Passed1.40 sec Start 576: Qt5Autogen.MocCMP0071 3/8 Test #576: Qt5Autogen.MocCMP0071 Passed2.48 sec Start 577: Qt5Autogen.MocIncludeRelaxed 4/8 Test #577: Qt5Autogen.MocIncludeRelaxed .***Failed4.37 sec Start 578: Qt5Autogen.MocIncludeStrict 5/8 Test #578: Qt5Autogen.MocIncludeStrict ..***Failed4.24 sec Start 579: Qt5Autogen.MocSkipSource 6/8 Test #579: Qt5Autogen.MocSkipSource .***Failed2.99 sec Start 580: Qt5Autogen.MocMacroName 7/8 Test #580: Qt5Autogen.MocMacroName .. Passed1.95 sec Start 581: Qt5Autogen.MocOsMacros 8/8 Test #581: Qt5Autogen.MocOsMacros ... Passed0.56 sec 63% tests passed, 3 tests failed out of 8 Total Test time (real) = 20.09 sec The following tests FAILED: 577 - Qt5Autogen.MocIncludeRelaxed (Failed) 578 - Qt5Autogen.MocIncludeStrict (Failed) 579 - Qt5Autogen.MocSkipSource (Failed) Errors while running CTest So, no change here. Kornel signature.asc Description: This is a digitally signed message part. -- 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:
Re: [cmake-developers] Moc-test errors
Am Donnerstag, 6. Juni 2019, 14:02:33 CEST schrieb Kornel Benko: > Am Dienstag, 4. Juni 2019, 16:05:25 CEST schrieb Sebastian Holtermann: > > > The following tests FAILED: > > > 577 - Qt5Autogen.MocIncludeRelaxed (Failed) > > > 578 - Qt5Autogen.MocIncludeStrict (Failed) > > > 579 - Qt5Autogen.MocSkipSource (Failed) > > > Errors while running CTest > > > > > > > Okay, it looks like SKIP_AUTOMOC doesn't work properly. > > Can you please post the output of > > > > - `ctest -R Qt5Autogen.MocSkip -VV` > > - `cat > > Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocA_autogen.dir/AutogenInfo.cmake` > > - `cat > > Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocB_autogen.dir/AutogenInfo.cmake` > > OK, attached. > BTW, with todays compilation (master branch) also some qt4-moc-tests are failing. This starts to be itching ... # ctest -R Autogen.Moc ... The following tests FAILED: 577 - Qt5Autogen.MocIncludeRelaxed (Failed) 578 - Qt5Autogen.MocIncludeStrict (Failed) 579 - Qt5Autogen.MocSkipSource (Failed) 615 - Qt4Autogen.MocIncludeRelaxed (Failed) 616 - Qt4Autogen.MocIncludeStrict (Failed) 617 - Qt4Autogen.MocSkipSource (Failed) Errors while running CTest Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Moc-test errors
Am Dienstag, 4. Juni 2019, 16:05:25 CEST schrieb Sebastian Holtermann: > > The following tests FAILED: > > 577 - Qt5Autogen.MocIncludeRelaxed (Failed) > > 578 - Qt5Autogen.MocIncludeStrict (Failed) > > 579 - Qt5Autogen.MocSkipSource (Failed) > > Errors while running CTest > > > > Okay, it looks like SKIP_AUTOMOC doesn't work properly. > Can you please post the output of > > - `ctest -R Qt5Autogen.MocSkip -VV` > - `cat > Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocA_autogen.dir/AutogenInfo.cmake` > - `cat > Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocB_autogen.dir/AutogenInfo.cmake` OK, attached. Kornel UpdateCTestConfiguration from :/BUILD/BUILDMint18/BuildCmakeGit/DartConfiguration.tcl Parse Config file:/BUILD/BUILDMint18/BuildCmakeGit/DartConfiguration.tcl Add coverage exclude regular expressions. Add coverage exclude: XCode Add coverage exclude: /Source/(cm|kw)sys/ Add coverage exclude: /CMakeFiles/CMakeTmp/ Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src SetCTestConfiguration:CMakeCommand:/usr/bin/cmake UpdateCTestConfiguration from :/BUILD/BUILDMint18/BuildCmakeGit/DartConfiguration.tcl Parse Config file:/BUILD/BUILDMint18/BuildCmakeGit/DartConfiguration.tcl Test project /BUILD/BUILDMint18/BuildCmakeGit Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end test 579 Start 579: Qt5Autogen.MocSkipSource 579: Test command: /BUILD/BUILDMint18/BuildCmakeGit/bin/ctest "--build-and-test" "/usr/src/cmake/cmake/Tests/QtAutogen/MocSkipSource" "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource" "--build-generator" "Unix Makefiles" "--build-project" "MocSkipSource" "--build-exe-dir" "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource" "--force-new-ctest-process" "--build-options" "-DCMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make" "-DQT_TEST_VERSION=5" "-DCMAKE_BUILD_TYPE=" "-DCMAKE_AUTOGEN_VERBOSE=1" "-DQT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake-qt4" 579: Test timeout computed to be: 1500 579: Internal cmake changing into directory: /BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource 579: CMake output == 579: Configuring done 579: Generating done 579: Build files have been written to: /BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource 579: End CMake output == 579: Change Dir: /BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource 579: 579: Run Clean Command:/usr/bin/make clean 579: 579: Run Build Command(s):/usr/bin/make && [ 2%] Generating moc_qItemD.cpp 579: [ 5%] Generating moc_qItemA.cpp 579: [ 7%] Generating moc_qItemB.cpp 579: [ 10%] Generating moc_qItemC.cpp 579: [ 12%] Automatic MOC and UIC for target skipMocB 579: AutoGen: Refreshing parse cache because it doesn't exist. 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemA.hpp" 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemD.hpp" 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemC.hpp" 579: AutoGen: Parsing "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/moc_qItemA.cpp" 579: AutoGen: Parsing "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/moc_qItemC.cpp" 579: AutoGen: Parsing "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/moc_qItemB.cpp" 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemA.cpp" 579: AutoGen: Parsing "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/moc_qItemD.cpp" 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemC.cpp" 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/skipMoc.cpp" 579: AutoGen: Parsing "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemD.cpp" 579: AutoMoc: Generating "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/skipMocB_autogen/include/qItemC.moc", because it doesn't exist, from "/usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemC.cpp" 579: /usr/lib/x86_64-linux-gnu/qt5/bin/moc -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I/usr/include/c++/5 -I/usr/include/x86_64-linux-gnu/c++/5 -I/usr/include/c++/5/backward -I/usr/lib/gcc/x86_64-linux-gnu/5/include -I/usr/local/include -I/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed -I/usr/include/x86_64-linux-gnu -I/usr/include -DQT_CORE_LIB -DQT_NO_DEBUG -o /BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/skipMocB_autogen/include/qItemC.moc /usr2/src/cmake/cmake/Tests/QtAutogen/MocSkipSource/qItemC.cpp 579: AutoMoc: Generating "/BUILD/BUILDMint18/BuildCmakeGit/Tests/Qt5Autogen/MocSkipSource/skipMocB_autogen/EWIEGA46WW/moc_qItemD.cpp", because it doesn't exist, from
[cmake-developers] Moc-test errors
Recent tries to test cmake yield to errors for following tests: 582 - Qt5Autogen.MocIncludeRelaxed (Failed) 583 - Qt5Autogen.MocIncludeStrict (Failed) 584 - Qt5Autogen.MocSkipSource (Failed) Compiled master branch of http://cmake.org/cmake.git As en example, here the log-snippet for Qt5Autogen.MocIncludeRelaxed: [ 75%] Linking CXX executable mocIncludeRelaxed CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: In function `SObjCExtra::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)': SObjCExtra.cpp:(.text+0x134): multiple definition of `SObjCExtra::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)' CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xa3a): first defined here CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o:(.data.rel.ro+0x0): multiple definition of `SObjCExtra::staticMetaObject' CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:(.data.rel.ro+0x2c0): first defined here CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: In function `SObjCExtra::metaObject() const': SObjCExtra.cpp:(.text+0x14a): multiple definition of `SObjCExtra::metaObject() const' CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xa50): first defined here CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: In function `SObjCExtra::qt_metacast(char const*)': SObjCExtra.cpp:(.text+0x192): multiple definition of `SObjCExtra::qt_metacast(char const*)' CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xa98): first defined here CMakeFiles/mocIncludeRelaxed.dir/usr/src/cmake/cmake/Tests/QtAutogen/MocInclude/SObjCExtra.cpp.o: In function `SObjCExtra::qt_metacall(QMetaObject::Call, int, void**)': SObjCExtra.cpp:(.text+0x1e2): multiple definition of `SObjCExtra::qt_metacall(QMetaObject::Call, int, void**)' CMakeFiles/mocIncludeRelaxed.dir/mocIncludeRelaxed_autogen/mocs_compilation.cpp.o:mocs_compilation.cpp:(.text+0xae8): first defined here collect2: error: ld returned 1 exit status In case it matters: gcc: 5.4.0 QT: 5.6.1 OS: ubuntu 16.04 cmake called with cmake /usr/src/cmake/cmake \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DCMAKE_USE_OPENSSL:BOOL=ON \ -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=OFF \ -DBUILD_QtDialog:BOOL=ON \ -DBUILD_CursesDialog:BOOL=OFF \ -DBUILD_DOCUMENTATION=ON \ -DSPHINX_MAN=ON \ -DCMAKE_USE_OPENSSL=ON \ -DCMAKE_USE_SYSTEM_CURL=OFF \ -DCPACK_BINARY_DEB:BOOL=ON \ -DCMAKE_MAN_DIR=/share/man Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Moc-test errors
Am Donnerstag, 6. Juni 2019, 18:01:09 CEST schrieb Sebastian Holtermann: > > > BTW, with todays compilation (master branch) also some qt4-moc-tests are > > failing. > > This starts to be itching ... > > > > > > # ctest -R Autogen.Moc > > ... > > The following tests FAILED: > > 577 - Qt5Autogen.MocIncludeRelaxed (Failed) > > 578 - Qt5Autogen.MocIncludeStrict (Failed) > > 579 - Qt5Autogen.MocSkipSource (Failed) > > 615 - Qt4Autogen.MocIncludeRelaxed (Failed) > > 616 - Qt4Autogen.MocIncludeStrict (Failed) > > 617 - Qt4Autogen.MocSkipSource (Failed) > > Errors while running CTest > > > > Kornel > > I was able to reproduce the issue. It appears when the CMake sources > are in a path that contains symbolic links. > Please see issue https://gitlab.kitware.com/cmake/cmake/issues/19346 > > -Sebastian > Right, the sources are addressed with /usr/src/cmake/cmake, but /usr/src/cmake is symbolic link to /usr2/src/cmake. Thanks for the pointer. Kornel signature.asc Description: This is a digitally signed message part. -- 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: https://cmake.org/mailman/listinfo/cmake-developers