[CMake] Creating package

2012-05-26 Thread Kornel Benko
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

2012-05-26 Thread Kornel Benko
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

2012-05-26 Thread Kornel Benko
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

2012-05-27 Thread Kornel Benko
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

2012-05-27 Thread Kornel Benko
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

2012-05-27 Thread Kornel Benko
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

2012-06-26 Thread Kornel Benko
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

2012-07-04 Thread Kornel Benko
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

2012-07-05 Thread Kornel Benko
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?

2012-07-25 Thread Kornel Benko
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

2012-08-25 Thread Kornel Benko
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

2012-08-25 Thread Kornel Benko
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

2013-01-04 Thread Kornel Benko
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

2013-01-04 Thread Kornel Benko
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

2013-01-28 Thread Kornel Benko
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

2013-02-25 Thread Kornel Benko
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

2013-02-26 Thread Kornel Benko
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

2013-02-28 Thread Kornel Benko
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

2013-11-13 Thread Kornel Benko
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

2013-11-13 Thread Kornel Benko
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

2014-04-13 Thread Kornel Benko
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 ...

2014-06-27 Thread Kornel Benko
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()

2014-06-28 Thread Kornel Benko
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()

2014-06-28 Thread Kornel Benko
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

2014-08-28 Thread Kornel Benko
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

2014-08-28 Thread Kornel Benko
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

2015-12-10 Thread Kornel Benko
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

2018-07-13 Thread 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


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

2018-07-13 Thread Kornel Benko
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

2019-06-04 Thread Kornel Benko
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

2019-07-31 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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)

2012-06-05 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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

2012-06-05 Thread Kornel Benko
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

2012-06-06 Thread Kornel Benko
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

2012-06-11 Thread Kornel Benko
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

2012-06-11 Thread Kornel Benko
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

2012-06-17 Thread Kornel Benko

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

2012-06-17 Thread Kornel Benko
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

2012-10-15 Thread Kornel Benko
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

2012-11-08 Thread Kornel Benko
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

2012-11-08 Thread Kornel Benko
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

2013-05-17 Thread Kornel Benko
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

2013-05-17 Thread Kornel Benko
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

2013-05-17 Thread Kornel Benko
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

2014-05-19 Thread Kornel Benko
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

2014-05-19 Thread Kornel Benko
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.

2014-06-11 Thread Kornel Benko
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.

2014-06-11 Thread Kornel Benko
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

2015-05-07 Thread Kornel Benko
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

2016-07-14 Thread Kornel Benko
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

2016-07-14 Thread Kornel Benko
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

2016-07-14 Thread Kornel Benko
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

2016-07-14 Thread Kornel Benko
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

2016-07-14 Thread Kornel Benko
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

2016-07-14 Thread Kornel Benko
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

2017-12-29 Thread Kornel Benko
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

2017-12-29 Thread Kornel Benko
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

2019-06-04 Thread Kornel Benko
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

2019-06-06 Thread Kornel Benko
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

2019-06-06 Thread 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.

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

2019-06-04 Thread Kornel Benko
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

2019-06-06 Thread Kornel Benko
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