[CMake] Bug with FindQt4?

[Kurtis Nusbaum]

I'm deploying a Qt application which uses phonon on windows. For some
reason, the DeployQt4.cmake module wasn't finding the phonon_ds9 backend
plugin that is standard with windows installations of Qt4. More
specifically (and was I'm almost positive this was what was tripping up
DeployQt4), the QT_PHONON_DS9_PLUGIN_RELEASE variable was not set. I went
and looked at the FindQt4.cmake file and found this line (it's line 1062 on
cmake release 2.8,8):

set( QT_PHONON_BACKEND_PLUGINS phonon_qt7 )

phonon_qt7 is the phonon backend used exclusively on mac. Sure enough,
changing the line to

set( QT_PHONON_BACKEND_PLUGINS phonon_ds9 )

resulted in the variable QT_PHONON_DS9_PLUGIN_RELEASE and
QT_PHONON_DS9_PLUGIN_DEBUG being set to the correct libraries and DeployQt4
module finding the phonon_ds9 plugin and successfully bundling it with my
application. Is this a bug with FindQt4? If so, how can I go about getting
it fixed (I'm happy to create a patch myself if no one else wants to fix
it).

-- 
Peace, Love, and Source Code
-Kurtis
--

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] CPack : WM_SETTINGCHANGE broadcast

[Nicholas Yue]

Hi,

I understand from reading the following article

http://support.microsoft.com/kb/104011 



that one need to broadcast a WM_SETTINGSCHANGE for environment 
variable updated via the registry key to take effect in the current session


I have been able to update the registry and re-login in have the 
effect of updating the environment, using the information from the 
following URL


http://nsis.sourceforge.net/Docs/Chapter4.html 



However, I was unable to determine a way from within CPack to do a 
WM_SETTINGSCHANGE broadcast so that the user installing the software I 
am packaging not to have to log-out and log-in for the updated 
environment variable to take effect.


Is there a different approach ?

Regards

--
Nicholas Yue
Graphics - RenderMan, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
Management - Recruitment, career management
http://www.proceduralinsight.com/
http://au.linkedin.com/in/nicholasyue


--

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 self test fails on "Darwin - 9.8.0 - i386" with gcc47 and spaces in path

[Claus Klein]

done, now it works better.

Same with and without ninja!

Claus

On 27.05.2012, at 18:24, Richard Wackerbarth wrote:

You need to clean out your build tree. You have things left over  
from the previous builds using ninja.


Internal cmake changing into directory: /Users/clausklein/Downloads/ 
My Cmake Test/Tests/Architecture Error: cmake execution failed CMake  
Error: Error: generator : Unix Makefiles Does not match the  
generator used previously: Ninja Either remove the CMakeCache.txt  
file or choose a different binary directory.
Keep a separate build tree for Unix makefiles and for Ninja builds.  
You can use the same source tree if you wish.


Richard

On May 27, 2012, at 11:19 AM, Claus Klein wrote:


Hi Richard,

I have set it to i386.
I have Xcode 3.1 installed year ago to bootstrap macports.
I never use it!

This problems for example are caused that my gcc47 compiler is used  
to compile objectc++, but it is not build to do this!


All this errors are have the this kind of reason, none of them is  
caused from ninja.


And without ninja, I have more trouble as I want.

see http://open.cdash.org/viewTest.php?onlyfailed&buildid=2312582

// Regards
Claus




--

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 self test fails on "Darwin - 9.8.0 - i386" with gcc47 and spaces in path

[Claus Klein]

Hi Richard,

I have set it to i386.
I have Xcode 3.1 installed year ago to bootstrap macports.
I never use it!

This problems for example are caused that my gcc47 compiler is used to  
compile objectc++, but it is not build to do this!


All this errors are have the this kind of reason, none of them is  
caused from ninja.


And without ninja, I have more trouble as I want.

see http://open.cdash.org/viewTest.php?onlyfailed&buildid=2312582

// Regards
Claus


Run Build Command:/opt/local/bin/ninja
[1/2] Building CXX object CMakeFiles/ObjC++.dir/objc++.mm.o
FAILED: /opt/local/bin/c++ -MMD -MT CMakeFiles/ObjC++.dir/objc+ 
+.mm.o -MF CMakeFiles/ObjC++.dir/objc++.mm.o.d -o CMakeFiles/ObjC+ 
+.dir/objc++.mm.o -c /Users/clausklein/Downloads/cmake/Tests/ObjC++/ 
objc++.mm
/Users/clausklein/Downloads/cmake/Tests/ObjC++/objc++.mm:1:21: fatal  
error: iostream.h: No such file or directory

compilation terminated.
ninja: build stopped: subcommand failed.

#

Run Build Command:/opt/local/bin/ninja
[1/4] Building C object CMakeFiles/foo.dir/foo.c.o
[2/4] Linking C static library libfoo.a
[3/4] Building C object CMakeFiles/bar.dir/bar.c.o
FAILED: /opt/local/bin/gcc   -arch ppc -isysroot /Developer/SDKs/ 
MacOSX10.5.sdk -MMD -MT CMakeFiles/bar.dir/bar.c.o -MF CMakeFiles/ 
bar.dir/bar.c.o.d -o CMakeFiles/bar.dir/bar.c.o   -c /Users/clausklein/ 
Downloads/cmake/Tests/Architecture/bar.c

gcc: error: unrecognized option '-arch'
ninja: build stopped: subcommand failed.



On 27.05.2012, at 15:06, Richard Wackerbarth wrote:

The first thing that I notice is that you do not seem to have Xcode  
4 installed.
Since your compiler does not handle ppc code, you need to set  
CMAKE_OSX_ARCHITECTURES to keep your compiler happy.


Also, I readily cannot tell from the dashboard if you are using  
ninja. Please use Unix makefiles first so that we can sort out  
problems related to your compiler installation. Then, once you have  
those issues addressed, we can take a look at ninja.


Richard

On May 27, 2012, at 7:21 AM, Claus Klein wrote:


I have uploaded my test result:
http://open.cdash.org/viewTest.php?onlyfailed&buildid=2312336
Claus




--

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] the list parameter passed to function

[Marmot Ken]

Sorry.  Copy-paste error kicks my ass.

 Output expected :

  SRC_LIST : ./a.cpp;./c.cpp;./main.cpp
  src_list_in : ./a.cpp;./c.cpp;./main.cpp

Now i got the solution.

invoke the function like this :

  AUX_SOURCE_DIRECTORY( . SRC_LIST  )
  MESSAGE( SRC_LIST  " : ${SRC_LIST} " )

  Append_headers_to_src_list( SRC_LIST  "${SRC_LIST}"
${CMAKE_SOURCE_DIR}/include/test  )

Question is :
   Why?

2012/5/22 Petr Kmoch 

> Hi,
>
> try as I might, I can't see a difference between the output and
> expected output. Perhaps a copy-paste error?
>
> Petr
>
> On Tue, May 22, 2012 at 3:07 AM, Marmot Ken  wrote:
> > here is the function :
> >
> > FUNCTION( Append_headers_to_src_list  src_list_out src_list_in
> > header_file_path_in )
> > MESSAGE( src_list_in  " : ${src_list_in}" )
> > FILE( GLOB_RECURSE TEMP_LIST ${header_file_path_in}/*.h )
> > SET( ${src_list_out} ${src_list_in} ${TEMP_LIST} PARENT_SCOPE )
> > ENDFUNCTION( Append_headers_to_src_list
> >
> >
> > here is the place where the function is invoked:
> >
> > AUX_SOURCE_DIRECTORY( . SRC_LIST  )
> > MESSAGE( SRC_LIST  " : ${SRC_LIST} " )
> >
> > Append_headers_to_src_list( SRC_LIST  ${SRC_LIST}
> > ${CMAKE_SOURCE_DIR}/include/test  )
> >
> > here is output ：
> >
> > SRC_LIST : ./a.cpp;./c.cpp;./main.cpp
> > src_list_in : ./a.cpp
> >
> > Output expected :
> >
> > SRC_LIST : ./a.cpp;./c.cpp;./main.cpp
> > src_list_in : ./a.cpp
> >
> > Ｑｕｅｓｔｉｏｎ：
> >   <1>  how to get expected Output ?
> > <2>  why ?
> >
> > Thanks.
> >
> > --
> >
> > 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
>
--

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 self test fails on "Darwin - 9.8.0 - i386" with gcc47 and spaces in path

[Claus Klein]

I have uploaded my test result:
http://open.cdash.org/viewTest.php?onlyfailed&buildid=2312336
Claus

On 27.05.2012, at 12:10, Claus Klein wrote:


Hi all,

while testing the ninja generator I created a reference binary tree  
with gmake an gcc47 installed with macports.


I created a new empty dir with

mkdir "/Users/clausklein/Downloads/My Cmake Test"
and created the makefiles with a build scripts.

It seems that the spaces in CWD makes trouble while make test?


No space problem!

/Users/clausklein/Downloads/CmakeBuildDir/bin/ctest "--build-and-test"  
"/Users/clausklein/Downloads/cmake/Tests/CommandLineTest" "/Users/ 
clausklein/Downloads/CmakeBuildDir/Tests/CommandLineTest" "--build-two- 
config" "--build-generator" "Ninja" "--build-makeprogram" "/opt/local/ 
bin/gmake" "--build-project" "CommandLineTest" "--test-command"  
"CommandLineTest"


The --build-makeprogram is wrong!

--

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

[Kornel Benko]

Am Sonntag, 27. Mai 2012 um 13:50:37, schrieb Eric Noulard 

> 2012/5/27 Kornel Benko :
> > Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard 
> > 
> > [ 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 self build with ninja works on Darwin, but a view tests fail

[Claus Klein]

Ok,
done.

see http://open.cdash.org/viewTest.php?onlyfailed&buildid=2312368
Claus

On 27.05.2012, at 12:36, Richard Wackerbarth wrote:


Claus,

Can you try to set this up to submit to the dashboard?

Since you think that many of the problems are not related to Ninja,  
please also try it without using ninja, but rather Unix makefiles  
and everything else the same. It will be interesting to see what  
fails under those conditions. Again, submitting to the dashboard is  
a better way to document the particulars of the failure.


Richard

On May 27, 2012, at 5:26 AM, Claus Klein wrote:
Only a view tests fails, but most of the problems are NOT caused by  
ninja.


It seems, that while testing, cmake on Darwin use options only  
valid for old native apple gcc?


But I use gcc47 installed with macports!


--

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

[Eric Noulard]

2012/5/27 Kornel Benko :
> Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard 
> 
> [ 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?

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.

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
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

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 self build with ninja works on Darwin, but a view tests fail

[Claus Klein]

Hi Richard,

do you mean I shall do:

"make Experimental"
# or
"ninja Experimental"

ot my binary dir?

Claus


On 27.05.2012, at 12:36, Richard Wackerbarth wrote:


Claus,

Can you try to set this up to submit to the dashboard?

Since you think that many of the problems are not related to Ninja,  
please also try it without using ninja, but rather Unix makefiles  
and everything else the same. It will be interesting to see what  
fails under those conditions. Again, submitting to the dashboard is  
a better way to document the particulars of the failure.


Richard

On May 27, 2012, at 5:26 AM, Claus Klein wrote:
Only a view tests fails, but most of the problems are NOT caused by  
ninja.


It seems, that while testing, cmake on Darwin use options only  
valid for old native apple gcc?


But I use gcc47 installed with macports!


--

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

[Kornel Benko]

Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard 

[ 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] cmake self build with ninja works on Darwin, but a view tests fail

[Richard Wackerbarth]

Claus,

Can you try to set this up to submit to the dashboard?

Since you think that many of the problems are not related to Ninja, please also 
try it without using ninja, but rather Unix makefiles and everything else the 
same. It will be interesting to see what fails under those conditions. Again, 
submitting to the dashboard is a better way to document the particulars of the 
failure.

Richard

On May 27, 2012, at 5:26 AM, Claus Klein wrote:
> Only a view tests fails, but most of the problems are NOT caused by ninja.
> 
> It seems, that while testing, cmake on Darwin use options only valid for old 
> native apple gcc?
> 
> But I use gcc47 installed with macports!
--

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] Selectively adding source files and compiling assembly sources

[Johannes Bauer]

Hi list,

I'm a total beginner to CMake as a developer (although I've used it in
the past for other projects before). Now I'm starting by converting a
rather large Automake-Project to CMake. I'm doing it from scratch.

In the project, executables and a shared library are created from the
same objects. Which objects are chosen, however, depends on the
configuration. For example consider the following sources:

featurea/obj1.c
featurea/obj2.c
featurea/obj3.c
featureb/obj1.c
featureb/obj2.c
featureb/obj3.c
common.c

let's say I want to create a executable only from common.c, but it
should also compile and link featurea/*.c if the option WITH_A is set
and should also compile and link featureb/*.c if the option WITH_B is
set. These I've specified in the CMakeLists file:

option(WITH_A "Enable FOO support" ON)
option(WITH_B "Enable BAR component" OFF)

However, I see no way of adding features to the "add_executable" option
after it has been specified (something like add_source or the likes).
How can this be done?

Another problem I've run into is that the project has some assembly
files ("*.s"), which even though I specify them in the add_executables
command are just ignored (leading to unresolved symbols, of course, at
link time). Any pointers for this?

And is it maybe possible (not dramatic if it isn't) to group options
into subgroups so they're easier to configure using cmake-gui? There is
a "Grouped" checkbox, but it only uses the string representation (i.e.
FOO_BAR is group FOO, subitem BAR) and allows only one level of nesting.
Something like configuration of the linux kernel (with multiple levels
of configuration) maybe?

Best regards,
Joe
--

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] cmake self build with ninja works on Darwin, but a view tests fail

[Claus Klein]

Hi all,

I tried to build cmake with ninja generator enabled and build cmake  
itself with ninja.


Nice, it works ;-))

Only a view tests fails, but most of the problems are NOT caused by  
ninja.


It seems, that while testing, cmake on Darwin use options only valid  
for old native apple gcc?


But I use gcc47 installed with macports!

Here is my test script:

#!/bin/sh

MAKECOMMAND=/opt/local/bin/ninja

set -x
set -e

/usr/local/bin/cmake -G Ninja -DCMAKE_TEST_GENERATOR:STRING="Ninja" \
-DCMAKE_TEST_MAKEPROGRAM:FILEPATH="${MAKECOMMAND}" - 
DCMAKE_ENABLE_NINJA:BOOL="ON" \

-DBUILD_CursesDialog:BOOL="OFF" -DBUILD_QtDialog:BOOL="OFF" \
-DMAKECOMMAND:STRING="${MAKECOMMAND} -d stats" \
../cmake

time ${MAKECOMMAND} clean

# Cleaning... 783 files.

time ${MAKECOMMAND} -d stats

# + /opt/local/bin/ninja -d stats
# ...
# [405/405] Generating ../Docs/cmake.txt
# metriccount   avg (us)total (ms)
# .ninja parse  2   5540.5  11.1
# canonicalize str  29860.3 1.0
# canonicalize path 29860.2 0.5
# lookup node   29860.1 0.4
# .ninja_log load   1   5449.0  5.4
# node stat 10145.2 5.3
# depfile load  378 7.8 2.9
#
# path->node hash load 0.73 (1131 entries / 1543 buckets)
#
# real  1m55.262s
# user  3m1.512s
# sys   0m26.803s

time ${MAKECOMMAND} -d stats -d explain

# + /opt/local/bin/ninja -d stats -d explain
# ninja: no work to do.
# metriccount   avg (us)total (ms)
# .ninja parse  2   5645.0  11.3
# canonicalize str  29860.3 1.0
# canonicalize path 10624   0.2 1.9
# lookup node   10624   0.2 2.1
# .ninja_log load   1   4944.0  4.9
# node stat 15656.9 10.8
# depfile load  378 52.419.8
#
# path->node hash load 0.55 (1682 entries / 3079 buckets)
#
# real  0m0.057s
# user  0m0.030s
# sys   0m0.023s


exit


${MAKECOMMAND} test

# Total Test time (real) = 860.22 sec

# The following tests FAILED:
#54 - ExportImport (Failed)
#59 - Architecture (Failed)
#61 - Qt4Deploy (Failed)
#83 - BuildDepends (Failed)
#93 - CPackComponentsForAll-DragNDrop-IgnoreGroup (Failed)
#94 - CPackComponentsForAll-DragNDrop-AllInOne (Failed)
#96 - X11 (Failed)
#   128 - BundleTest (Failed)
#   129 - CFBundleTest (Failed)
#   130 - ObjC++ (Failed)
#   230 - CMake.CheckSourceTree (Failed)
# Errors while running CTest
# ninja: build stopped: subcommand failed.


I have prepared a small patch to fix the X11 test.

For the others, I need  your help please.
I attach the logs of my manually started tests as info.

With regards
Claus




TestsX11HelloWorldX11.patch
Description: Binary data


#54 - ExportImport (Failed)

cd /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport
claus-kleins-macbook-pro:ExportImport clausklein$ ninja
[2/5] Generating ExportProject
loading initial cache file 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/InitialCache.cmake
Internal cmake changing into directory: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Export
 CMake output ==
Configuring
Configuring done
Generating
Generating done
Build files have been written to: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Export
 End CMake output ==
Change Dir: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Export

Run Build Command:/opt/local/bin/ninja install
[1/1] Install the project...
-- Install configuration: ""
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/bin/testExe1-4
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/bin/testExe1
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/lib/libtestLib1.a
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/lib/libtestLib2.a
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/bin/testExe2
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/lib/libtestLib3lib.1.2.dylib
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/lib/libtestLib3lib.3.dylib
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/Frameworks/testLib4.framework
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/Frameworks/testLib4.framework/Versions
-- Installing: 
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/ExportImport/Root/Frameworks/testLib4.framework/Versions/A
-- Installing: 
/Use

[CMake] cmake self test fails on "Darwin - 9.8.0 - i386" with gcc47 and spaces in path

[Claus Klein]

Hi all,

while testing the ninja generator I created a reference binary tree  
with gmake an gcc47 installed with macports.


I created a new empty dir with

mkdir "/Users/clausklein/Downloads/My Cmake Test"
and created the makefiles with a build scripts.

It seems that the spaces in CWD makes trouble while make test?

#!/bin/sh

MAKECOMMAND=/opt/local/bin/gmake

set -x
set -e

/usr/local/bin/cmake -G "Eclipse CDT4 - Unix Makefiles" - 
DCMAKE_TEST_GENERATOR:STRING="Ninja" \
-DCMAKE_TEST_MAKEPROGRAM:FILEPATH="${MAKECOMMAND}" - 
DCMAKE_ENABLE_NINJA:BOOL="ON" \

-DBUILD_CursesDialog:BOOL="OFF" -DBUILD_QtDialog:BOOL="OFF" \
-DMAKECOMMAND:STRING="${MAKECOMMAND} --ignore-errors --no-builtin- 
rules" \

../cmake

time ${MAKECOMMAND} --silent --no-builtin-rules -B

# real  3m34.380s
# user  2m57.410s
# sys   0m29.289s

time ${MAKECOMMAND} --silent --no-builtin-rules

# real  0m1.911s
# user  0m1.060s
# sys   0m0.746s


# exit


${MAKECOMMAND} --no-builtin-rules test
# ...
# 56% tests passed, 104 tests failed out of 236
#
# Label Time Summary:
# Label1=   0.07 sec
# Label2=   0.07 sec
#
# Total Test time (real) = 584.77 sec
#
# The following tests FAILED:
#24 - CommandLineTest (Failed)
#25 - FindPackageTest (Failed)
#26 - FindModulesExecuteAll (Failed)
#27 - StringFileTest (Failed)
#28 - TryCompile (Failed)
#29 - TarTest (Failed)
#30 - SystemInformation (Failed)
#31 - MathTest (Failed)
#32 - Simple (Failed)
#33 - PreOrder (Failed)
#35 - FortranOnly (Failed)
#36 - VSGNUFortran (Failed)
#37 - COnly (Failed)
#38 - CxxOnly (Failed)
#39 - IPO (Failed)
#40 - OutDir (Failed)
#41 - ObjectLibrary (Failed)
#42 - NewlineArgs (Failed)
#43 - SetLang (Failed)
#44 - ExternalOBJ (Failed)
#45 - LoadCommand (Failed)
#46 - LinkDirectory (Failed)
#47 - LinkLanguage (Failed)
#48 - LinkLine (Failed)
#49 - MacroTest (Failed)
#50 - FunctionTest (Failed)
#51 - ReturnTest (Failed)
#52 - Properties (Failed)
#53 - Assembler (Failed)
#54 - SourceGroups (Failed)
#55 - Preprocess (Failed)
#56 - ExportImport (Failed)
#57 - Unset (Failed)
#58 - PolicyScope (Failed)
#61 - Architecture (Failed)
#62 - BundleUtilities (Failed)
#63 - Qt4Deploy (Failed)
#66 - Module.CheckTypeSize (Failed)
#67 - Module.GenerateExportHeader (Failed)
#68 - LinkFlags-prepare (Failed)
#75 - SubProject (Failed)
#76 - SubProject-Stage2 (Failed)
#77 - Framework (Failed)
#78 - TargetName (Failed)
#79 - LibName (Failed)
#80 - CustComDepend (Failed)
#81 - ArgumentExpansion (Failed)
#82 - CustomCommand (Failed)
#83 - CustomCommandWorkingDirectory (Failed)
#84 - OutOfSource (Failed)
#85 - BuildDepends (Failed)
#86 - SimpleInstall (Failed)
#87 - SimpleInstall-Stage2 (Failed)
#88 - CPackComponents (Failed)
#89 - CPackComponentsForAll-ZIP-default (Failed)
#90 - CPackComponentsForAll-ZIP-OnePackPerGroup (Failed)
#91 - CPackComponentsForAll-ZIP-IgnoreGroup (Failed)
#92 - CPackComponentsForAll-ZIP-AllInOne (Failed)
#93 - CPackComponentsForAll-DragNDrop-default (Failed)
#94 - CPackComponentsForAll-DragNDrop-OnePackPerGroup (Failed)
#95 - CPackComponentsForAll-DragNDrop-IgnoreGroup (Failed)
#96 - CPackComponentsForAll-DragNDrop-AllInOne (Failed)
#97 - CPackTestAllGenerators (Failed)
#98 - X11 (Failed)
#   102 - LoadedCommandOneConfig (Failed)
#   103 - complex (Failed)
#   104 - complexOneConfig (Failed)
#   105 - Example (Failed)
#   106 - Environment (Failed)
#   107 - QtAutomoc (Failed)
#   108 - ExternalProject (Failed)
#   109 - TutorialStep1 (Failed)
#   110 - TutorialStep2 (Failed)
#   111 - TutorialStep3 (Failed)
#   112 - TutorialStep4 (Failed)
#   113 - TutorialStep5 (Failed)
#   114 - TutorialStep6 (Failed)
#   115 - TutorialStep7 (Failed)
#   116 - testing (Failed)
#   117 - wrapping (Failed)
#   118 - qtwrapping (Failed)
#   119 - testdriver1 (Failed)
#   120 - testdriver2 (Failed)
#   121 - testdriver3 (Failed)
#   122 - Dependency (Failed)
#   123 - JumpWithLibOut (Failed)
#   124 - JumpNoLibOut (Failed)
#   125 - Plugin (Failed)
#   126 - linkorder1 (Failed)
#   127 - linkorder2 (Failed)
#   128 - SubDirSpaces (Failed)
#   129 - SubDir (Failed)
#   130 - CheckCompilerRelatedVariables (Failed)
#   131 - BundleTest (Failed)
#   132 - CFBundleTest (Failed)
#   133 - ObjC++ (Failed)
#   134 - BundleGeneratorTest (Failed)
#   140 - TestsWorkingDirectory (Failed)
#   163 - CMakeCommands.target_link_li

Re: [CMake] Creating package

[Eric Noulard]

2012/5/27 Kornel Benko :
>
>> > 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'

That's what I suspected.
There is some conflicting default setup between "system libarchive"
and "system tar command".

> 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.

Thanks you for digging this up,
I'll have a more close look at CPackDeb code because there should
be some "BSD tar" code inside the cmCPackDebGenerator.cxx which is supposed
to enhance tar portability issue.

This code is NOT using libarchive but obviously some part of CPackDeb
is using cmake -E tar / libarchive.

I'll try to either always use libarchive with "enforced" options
(which may not be the same as the one used by cmake -E tar)
or always use the builtin BSD tar.

>> 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 :)

Don't be afraid :-]
I don't want to push away the bug report but CMake source code
convey inside its source tree some external libraries (libarchive, zlib etc...)
in order to be able to:
   1) have greater portability
   2) have less 'external' dependencies (in fact there is almost none)
   3) ease testing on various platform in a consistent way.

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...

May be we should add a test (in CMake test suite) that

1) create tar using cmake -E tar
and untar it using system tar
2) create a tar using system tar
and untar it using cmake -E tar

That could help us (and packager if they run the CMake test suite)  to
catch this kind of issue.
Currently there is a "TarTest" (see /Tests/TarTest
but it's "only" testing whether if the cmake -E tar command is able to
work with itself.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

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

[Kornel Benko]

Am Samstag, 26. Mai 2012 um 22:02:19, schrieb Eric Noulard 

> 2012/5/26 Kornel Benko :
> > Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko 
> >> Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard 
> >> 
> >> > 2012/5/26 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.
> >> >
> >> > 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