Re: [CMake] CMake 2.8.2-rc2 ready for testing!
Alan wrote: > Isn't that the complete issue? My experience (under Wine, but the principle > is the same) is you must have mingw32-make.exe on your PATH in order for -G > "MinGW Makefiles" to work. So you will have to be careful of dependencies, > but you should be able to download and unpack mingw32-make.exe from the > normal SF location for that (under mingw) while keeping the normal MinGW gcc > compilers off your PATH (since you want to use the different compilers, > MinGW-W32 and MinGW-W64). I did not realize that cmake calls mingw32-make.exe, since the user has to call it explicitly after running cmake. But I see now. Cmake tries compiling as a part of finding the compilation tools. Your suggestion worked, for both W32 and W64. I used -G "MinGW Makefiles" for both cases. This also works with CMake 2.8 stable/release version. So I still cannot figure what's new in RC2 with respect to MinGW-W64. Since it works, there is no issue really. Just like CMake is able to distinguish different versions of Visual Studio, would it distinguish MinGW-32 with MinGW-64 also (which means either both would be in path simultaneously, or neither would be, and cmake picks the right one based on the generator specifed)? Let me know if so, and I'll be happy to test this. I have already reported missing mingw32-make.exe to MinGW-W64. Best regards - Alok --- > Date: Wed, 16 Jun 2010 19:32:32 -0700 > From: ir...@beluga.phys.uvic.ca > To: alokgo...@hotmail.com > CC: david.c...@kitware.com; cmake@cmake.org > Subject: Re: [CMake] CMake 2.8.2-rc2 ready for testing! > > On 2010-06-16 19:04-0700 Alok Govil wrote: > > > Hi all, > > > > I am unable to build using MinGW-W64, but chances are there would be some > > configuration issues. > > > > Here is how I am setup right now: > > > > 1. Download latest "automatic" builds (W64 and W32) from here: > > http://mingw-w64.sourceforge.net/ > > 2. Removed prefixes: For example, renamed file > > "x86_64-w64-mingw32-g++.exe" in the bin folder to "g++.exe". Am I not > > supposed to do this anymore? > > 3. Added CMake 2.8.2 RC2 as well as "one" of W64 and W32 to the path. > > 4. cmake . -G "MinGW Makefiles" // This could be wrong for W64, but > > fails for even W32. > > This step is where I get various errors from CMake. It works fine with > > normal MinGW. > > 5. Then I usually call "mingw32-make" but that is not even there in > > MinGW-W32 and MinGW-W64!! > > Isn't that the complete issue? My experience (under Wine, but the principle > is the same) is you must have mingw32-make.exe on your PATH in order for -G > "MinGW Makefiles" to work. So you will have to be careful of dependencies, > but you should be able to download and unpack mingw32-make.exe from the > normal SF location for that (under mingw) while keeping the normal MinGW gcc > compilers off your PATH (since you want to use the different compilers, > MinGW-W32 and MinGW-W64). > > Alan > __ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __ > > Linux-powered Science > __ _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ 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] CheckForPthreads.c
On 06/15/2010 05:07 PM, Kevin Fitch wrote:
> I have been converting an existing make based build system over to cmake,
> and overall I am loving it so far.
>
> I happened to run across CheckForPthreads.c, and was a little surprised to
> see that it was basically a classic example of racy code.
>
> The two spawned threads both increment res, which is then used as the return
> value of the whole program. So to prove to myself that this was a real
> issue, not just theoretical raciness, I compile the program, and ran it a
> couple million times on my linux box, and 7 of those two million runs
> returned 1 instead of 2. So the chance of screwup is quite small, but
> definitely non-zero.
Hi Kevin,
after having taken a look at CheckForPthreads.c, I would say you are
absolutely right: If C's postfix "++" operator isn't atomic - and AFAIK,
it isn't guaranteed to be - there's a certain probability for one thread
to intercept the other right at "res++" which may result in each thread
storing "1" to "res", so joining both threads isn't sufficient to ensure
a return value of "2". Actually, I can confirm that the program returns
a value of "1" sometimes. In connection with FindThreads.cmake relying
on "2" to indicate a working "pthread" option of the compiler, this is
definitive a bug, IMO - feel encouraged to file an appropriate report.
> Looking over the source I have a few questions:
> Should it protect the increment with a mutex?
The straightest measure to ensure proper functioning.
> Or, should it really just spawn 1 thread? Is there a point to the spawning
> two?
As far as I can see, one thread would be enough to prove the "pthread"
option, but this would also necessitate a change in FindThreads.cmake.
> Is there a purpose to all the prints?
Probably not since FindThreads.cmake doesn't catch them. Maybe, they
serve as a visual verification when the program is launched manually.
> What is the line "if(ac > 1000){return *av[0];}" there for? If it has a
> purpose that definitely deserves a comment.
A subtle joke we don't understand? ;)
> What about the "#if defined(__BEOS__)"... lines? The usleep will only be
> there on BEOS, but the comment on the usleep line mentions sun.
Perhaps, this means BEOS-on-SUN, but I don't know for sure.
Regards,
Michael
___
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 2.8.2-rc2 ready for testing!
On 2010-06-16 19:04-0700 Alok Govil wrote: Hi all, I am unable to build using MinGW-W64, but chances are there would be some configuration issues. Here is how I am setup right now: 1. Download latest "automatic" builds (W64 and W32) from here: http://mingw-w64.sourceforge.net/ 2. Removed prefixes: For example, renamed file "x86_64-w64-mingw32-g++.exe" in the bin folder to "g++.exe". Am I not supposed to do this anymore? 3. Added CMake 2.8.2 RC2 as well as "one" of W64 and W32 to the path. 4. cmake . -G "MinGW Makefiles" // This could be wrong for W64, but fails for even W32. This step is where I get various errors from CMake. It works fine with normal MinGW. 5. Then I usually call "mingw32-make" but that is not even there in MinGW-W32 and MinGW-W64!! Isn't that the complete issue? My experience (under Wine, but the principle is the same) is you must have mingw32-make.exe on your PATH in order for -G "MinGW Makefiles" to work. So you will have to be careful of dependencies, but you should be able to download and unpack mingw32-make.exe from the normal SF location for that (under mingw) while keeping the normal MinGW gcc compilers off your PATH (since you want to use the different compilers, MinGW-W32 and MinGW-W64). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science _ 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 2.8.2-rc2 ready for testing!
Hi David, You have raised the right concern. My intention is not to compare various MinGW builds but to understand how to configure Cmake 2.8.2 to build with MinGW-W64, since this support is being added to CMake. As it stands now, given lack of understanding of how to do this with CMake, I am unable to make CMake 2.8.2 RC2 do anything that CMake 2.8 stable cannot do on with respect to MinGW-W64. They both seem to do the same thing with both automatic (neither Cmake version works) and Sezero (both Cmake versions work) builds. I must be configuring something incorrectly. In other words, how is CMake team testing with MinGW64? Including where is it being downloaded from (since there is no "release" or "stable" build of it AFAIK). PS: I am ready to help wherever I can on this since I am interested in MinGW-W64 support. Best regards - Alok Date: Wed, 16 Jun 2010 22:18:34 -0400 Subject: Re: [CMake] CMake 2.8.2-rc2 ready for testing! From: david.c...@kitware.com To: alokgo...@hotmail.com CC: cmake@cmake.org On Wed, Jun 16, 2010 at 10:04 PM, Alok Govil wrote: Hi all, I am unable to build using MinGW-W64, but chances are there would be some configuration issues. Here is how I am setup right now: 1. Download latest "automatic" builds (W64 and W32) from here: http://mingw-w64.sourceforge.net/ 2. Removed prefixes: For example, renamed file "x86_64-w64-mingw32-g++.exe" in the bin folder to "g++.exe". Am I not supposed to do this anymore? 3. Added CMake 2.8.2 RC2 as well as "one" of W64 and W32 to the path. 4. cmake . -G "MinGW Makefiles" // This could be wrong for W64, but fails for even W32. This step is where I get various errors from CMake. It works fine with normal MinGW. 5. Then I usually call "mingw32-make" but that is not even there in MinGW-W32 and MinGW-W64!! Also of note: The following workaround works, even with the CMake 2.8 stable version. 1. Use Personal/Sezero builds from http://mingw-w64.sourceforge.net/ 2. Prefixes are already removed in Sezero builds. 3. Add only the "needed one" of W64 and W32 to the path. 4. cmake . -G "MinGW Makefiles" // Works for both W32 and W64 5. "mingw32-make" is present in both W32 and W64 builds. I would appreciate this more, on this list, in reply to this thread, at this time ... if it were at all clear to me that you were comparing a prior CMake release to the currently proposed CMake 2.8.2-rc2. Rather, it seems like you are comparing "latest" "automatic" builds of mingw-w64 to Personal/Sezero builds of mingw-w64. If you use CMake 2.8.2-rc2 with the Personal/Sezero builds, do you see a difference as compared to CMake 2.8.0 or 2.8.1 with the same Personal/Sezero builds? If this is a mingw-w64 issue, perhaps you could raise it on their mailing lists? Thanks,David Cole Best regards - Alok --- > Date: Wed, 16 Jun 2010 16:22:43 -0400 > From: david.c...@kitware.com > To: cmake@cmake.org > Subject: [CMake] CMake 2.8.2-rc2 ready for testing! > > The CMake 2.8.2 release candidate stream continues! > You can find the source and binaries here: > http://www.cmake.org/files/v2.8/. > > Since we switched to git, and a new workflow, we're > expecting to do more frequent releases. Because of > that, our release candidate phases will be shorter > than they have been historically. So, if you want to > test this out and ask for a fix, do it soon, or hold your > peace till the next release! > > Following is the list of changes in this release. > Since we switched to git, this list is now the > 'git log' one line summary written by the named > CMake developers. > > > Changes in CMake 2.8.2-rc2 (since 2.8.2-rc1) > > > Bill Hoffman (1): > Make sure libarchive uses cmzlib and not the system libz if found. > > Brad King (12): > Use forward slashes for objects in response files > Use platform variable for response file flag > Use response file for objects on MinGW and MSYS > Generalize CTest.Update* test dashboard script helpers > ctest_update: Support custom Git update command > ctest_update: Support Git upstream branch rewrites > Fix CMake data and doc paths in Cygwin package > Document scope of source file properties > Run CTest.NoNewline test using built CMake > Tru64: Place cmOStringStream vtable uniquely (#10541) > Enable BootstrapTest on MSYS > Tru64: Use full-path include directives in Makefiles (#10569) > > Christoph Watzl (1): > Fix nested source groups with VS 10 (#9863) > > Clinton Stimpson (2): > Support pthreads on irix. > Remove macro for querying qmake for qmake variables. > > David Cole (2): > Fix issue #10346. Error if SOURCE_DIR is empty. > Remove CTestTest3. > > Zach Mullen (1): > Extra coverage glob should subtract the explicitly defined excluded > files > > Chang
Re: [CMake] CMake 2.8.2-rc2 ready for testing!
On Wed, Jun 16, 2010 at 10:04 PM, Alok Govil wrote: > Hi all, > > I am unable to build using MinGW-W64, but chances are there would be some > configuration issues. > > Here is how I am setup right now: > > 1. Download latest "automatic" builds (W64 and W32) from here: > http://mingw-w64.sourceforge.net/ > 2. Removed prefixes: For example, renamed file > "x86_64-w64-mingw32-g++.exe" in the bin folder to "g++.exe". Am I not > supposed to do this anymore? > 3. Added CMake 2.8.2 RC2 as well as "one" of W64 and W32 to the path. > 4. cmake . -G "MinGW Makefiles" // This could be wrong for W64, but > fails for even W32. > This step is where I get various errors from CMake. It works fine > with normal MinGW. > 5. Then I usually call "mingw32-make" but that is not even there in > MinGW-W32 and MinGW-W64!! > > Also of note: The following workaround works, even with the CMake 2.8 > stable version. > > 1. Use Personal/Sezero builds from http://mingw-w64.sourceforge.net/ > 2. Prefixes are already removed in Sezero builds. > 3. Add only the "needed one" of W64 and W32 to the path. > 4. cmake . -G "MinGW Makefiles" // Works for both W32 and W64 > 5. "mingw32-make" is present in both W32 and W64 builds. > I would appreciate this more, on this list, in reply to this thread, at this time ... if it were at all clear to me that you were comparing a prior CMake release to the currently proposed CMake 2.8.2-rc2. Rather, it seems like you are comparing "latest" "automatic" builds of mingw-w64 to Personal/Sezero builds of mingw-w64. If you use CMake 2.8.2-rc2 with the Personal/Sezero builds, do you see a difference as compared to CMake 2.8.0 or 2.8.1 with the same Personal/Sezero builds? If this is a mingw-w64 issue, perhaps you could raise it on their mailing lists? Thanks, David Cole > Best regards - Alok > > --- > > > Date: Wed, 16 Jun 2010 16:22:43 -0400 > > From: david.c...@kitware.com > > To: cmake@cmake.org > > Subject: [CMake] CMake 2.8.2-rc2 ready for testing! > > > > > The CMake 2.8.2 release candidate stream continues! > > You can find the source and binaries here: > > http://www.cmake.org/files/v2.8/. > > > > Since we switched to git, and a new workflow, we're > > expecting to do more frequent releases. Because of > > that, our release candidate phases will be shorter > > than they have been historically. So, if you want to > > test this out and ask for a fix, do it soon, or hold your > > peace till the next release! > > > > Following is the list of changes in this release. > > Since we switched to git, this list is now the > > 'git log' one line summary written by the named > > CMake developers. > > > > > > Changes in CMake 2.8.2-rc2 (since 2.8.2-rc1) > > > > > > Bill Hoffman (1): > > Make sure libarchive uses cmzlib and not the system libz if found. > > > > Brad King (12): > > Use forward slashes for objects in response files > > Use platform variable for response file flag > > Use response file for objects on MinGW and MSYS > > Generalize CTest.Update* test dashboard script helpers > > ctest_update: Support custom Git update command > > ctest_update: Support Git upstream branch rewrites > > Fix CMake data and doc paths in Cygwin package > > Document scope of source file properties > > Run CTest.NoNewline test using built CMake > > Tru64: Place cmOStringStream vtable uniquely (#10541) > > Enable BootstrapTest on MSYS > > Tru64: Use full-path include directives in Makefiles (#10569) > > > > Christoph Watzl (1): > > Fix nested source groups with VS 10 (#9863) > > > > Clinton Stimpson (2): > > Support pthreads on irix. > > Remove macro for querying qmake for qmake variables. > > > > David Cole (2): > > Fix issue #10346. Error if SOURCE_DIR is empty. > > Remove CTestTest3. > > > > Zach Mullen (1): > > Extra coverage glob should subtract the explicitly defined excluded files > > > > Changes in CMake 2.8.2-rc1 (since 2.8.1): > > - Build on Tru64 (#10542) > > - Build on mingw-w64 > > - Build on old Sun (#10550, #10543) > > - CPack: Add native BZip2 support > > - CPack: Set compression type in RPM spec (#10363) > > - CPack: Try harder to initialize staging directory (#10793) > > - CTest: Add --stop-time argument > > - CTest: Cost data with '-j' > > - CTest: Fix memory report > > - CTest: Glob for uncovered files during coverage tests > > - CTest: Option to specify cdash server > > - CTest: PHP Coverage support > > - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd > > - CTest: Report failure in Update.xml > > - CTest: Submit author email in Update.xml > > - CTest: Teach ctest_update about Git submodules > > - CTest: Teach ctest_update to handle Git upstream branch rewrites > > - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) > > - Do not list file names during 'cmake -E tar xz' > > - Documentation: Comply with "XHTML 1.0 Strict" > > - Documentation: Fix typo in CMAKE_
Re: [CMake] CMake 2.8.2-rc2 ready for testing!
Hi all, I am unable to build using MinGW-W64, but chances are there would be some configuration issues. Here is how I am setup right now: 1. Download latest "automatic" builds (W64 and W32) from here: http://mingw-w64.sourceforge.net/ 2. Removed prefixes: For example, renamed file "x86_64-w64-mingw32-g++.exe" in the bin folder to "g++.exe". Am I not supposed to do this anymore? 3. Added CMake 2.8.2 RC2 as well as "one" of W64 and W32 to the path. 4. cmake . -G "MinGW Makefiles" // This could be wrong for W64, but fails for even W32. This step is where I get various errors from CMake. It works fine with normal MinGW. 5. Then I usually call "mingw32-make" but that is not even there in MinGW-W32 and MinGW-W64!! Also of note: The following workaround works, even with the CMake 2.8 stable version. 1. Use Personal/Sezero builds from http://mingw-w64.sourceforge.net/ 2. Prefixes are already removed in Sezero builds. 3. Add only the "needed one" of W64 and W32 to the path. 4. cmake . -G "MinGW Makefiles" // Works for both W32 and W64 5. "mingw32-make" is present in both W32 and W64 builds. Best regards - Alok --- > Date: Wed, 16 Jun 2010 16:22:43 -0400 > From: david.c...@kitware.com > To: cmake@cmake.org > Subject: [CMake] CMake 2.8.2-rc2 ready for testing! > > The CMake 2.8.2 release candidate stream continues! > You can find the source and binaries here: > http://www.cmake.org/files/v2.8/. > > Since we switched to git, and a new workflow, we're > expecting to do more frequent releases. Because of > that, our release candidate phases will be shorter > than they have been historically. So, if you want to > test this out and ask for a fix, do it soon, or hold your > peace till the next release! > > Following is the list of changes in this release. > Since we switched to git, this list is now the > 'git log' one line summary written by the named > CMake developers. > > > Changes in CMake 2.8.2-rc2 (since 2.8.2-rc1) > > > Bill Hoffman (1): > Make sure libarchive uses cmzlib and not the system libz if found. > > Brad King (12): > Use forward slashes for objects in response files > Use platform variable for response file flag > Use response file for objects on MinGW and MSYS > Generalize CTest.Update* test dashboard script helpers > ctest_update: Support custom Git update command > ctest_update: Support Git upstream branch rewrites > Fix CMake data and doc paths in Cygwin package > Document scope of source file properties > Run CTest.NoNewline test using built CMake > Tru64: Place cmOStringStream vtable uniquely (#10541) > Enable BootstrapTest on MSYS > Tru64: Use full-path include directives in Makefiles (#10569) > > Christoph Watzl (1): > Fix nested source groups with VS 10 (#9863) > > Clinton Stimpson (2): > Support pthreads on irix. > Remove macro for querying qmake for qmake variables. > > David Cole (2): > Fix issue #10346. Error if SOURCE_DIR is empty. > Remove CTestTest3. > > Zach Mullen (1): > Extra coverage glob should subtract the explicitly defined excluded > files > > Changes in CMake 2.8.2-rc1 (since 2.8.1): > - Build on Tru64 (#10542) > - Build on mingw-w64 > - Build on old Sun (#10550, #10543) > - CPack: Add native BZip2 support > - CPack: Set compression type in RPM spec (#10363) > - CPack: Try harder to initialize staging directory (#10793) > - CTest: Add --stop-time argument > - CTest: Cost data with '-j' > - CTest: Fix memory report > - CTest: Glob for uncovered files during coverage tests > - CTest: Option to specify cdash server > - CTest: PHP Coverage support > - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd > - CTest: Report failure in Update.xml > - CTest: Submit author email in Update.xml > - CTest: Teach ctest_update about Git submodules > - CTest: Teach ctest_update to handle Git upstream branch rewrites > - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) > - Do not list file names during 'cmake -E tar xz' > - Documentation: Comply with "XHTML 1.0 Strict" > - Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291) > - Documentation: Fix typo in HAS_CXX docs (#10578) > - Documentation: More consistent command signatures > - Eclipse: Do not add INCLUDE to environment twice > - Enable extra CodeBlocks generator on Cygwin > - ExternalProject: Support .zip and .bz2 archives, MD5 verification > - ExternalProject: Reconfigure when args change (#10258) > - ExternalProject: Support Git, SVN username/password > - FindCurses: Fix for cygwin ncurses package > - FindHSPELL: Version support > - FindJava: Error if version is not found only when REQUIRED > - FindJava: Support runtime and development components (#9840) > - FindKDE4: Prefer kdeconfig results over system paths > - FindMPEG: Check for 'vo' library > - FindPNG:
[CMake] CMake 2.8.2-rc2 ready for testing!
The CMake 2.8.2 release candidate stream continues! You can find the source and binaries here: http://www.cmake.org/files/v2.8/. Since we switched to git, and a new workflow, we're expecting to do more frequent releases. Because of that, our release candidate phases will be shorter than they have been historically. So, if you want to test this out and ask for a fix, do it soon, or hold your peace till the next release! Following is the list of changes in this release. Since we switched to git, this list is now the 'git log' one line summary written by the named CMake developers. Changes in CMake 2.8.2-rc2 (since 2.8.2-rc1) Bill Hoffman (1): Make sure libarchive uses cmzlib and not the system libz if found. Brad King (12): Use forward slashes for objects in response files Use platform variable for response file flag Use response file for objects on MinGW and MSYS Generalize CTest.Update* test dashboard script helpers ctest_update: Support custom Git update command ctest_update: Support Git upstream branch rewrites Fix CMake data and doc paths in Cygwin package Document scope of source file properties Run CTest.NoNewline test using built CMake Tru64: Place cmOStringStream vtable uniquely (#10541) Enable BootstrapTest on MSYS Tru64: Use full-path include directives in Makefiles (#10569) Christoph Watzl (1): Fix nested source groups with VS 10 (#9863) Clinton Stimpson (2): Support pthreads on irix. Remove macro for querying qmake for qmake variables. David Cole (2): Fix issue #10346. Error if SOURCE_DIR is empty. Remove CTestTest3. Zach Mullen (1): Extra coverage glob should subtract the explicitly defined excluded files Changes in CMake 2.8.2-rc1 (since 2.8.1): - Build on Tru64 (#10542) - Build on mingw-w64 - Build on old Sun (#10550, #10543) - CPack: Add native BZip2 support - CPack: Set compression type in RPM spec (#10363) - CPack: Try harder to initialize staging directory (#10793) - CTest: Add --stop-time argument - CTest: Cost data with '-j' - CTest: Fix memory report - CTest: Glob for uncovered files during coverage tests - CTest: Option to specify cdash server - CTest: PHP Coverage support - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd - CTest: Report failure in Update.xml - CTest: Submit author email in Update.xml - CTest: Teach ctest_update about Git submodules - CTest: Teach ctest_update to handle Git upstream branch rewrites - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) - Do not list file names during 'cmake -E tar xz' - Documentation: Comply with "XHTML 1.0 Strict" - Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291) - Documentation: Fix typo in HAS_CXX docs (#10578) - Documentation: More consistent command signatures - Eclipse: Do not add INCLUDE to environment twice - Enable extra CodeBlocks generator on Cygwin - ExternalProject: Support .zip and .bz2 archives, MD5 verification - ExternalProject: Reconfigure when args change (#10258) - ExternalProject: Support Git, SVN username/password - FindCurses: Fix for cygwin ncurses package - FindHSPELL: Version support - FindJava: Error if version is not found only when REQUIRED - FindJava: Support runtime and development components (#9840) - FindKDE4: Prefer kdeconfig results over system paths - FindMPEG: Check for 'vo' library - FindPNG: Support png 1.4 versioned lib names (#10551) - FindPkgConfig: Add QUIET keyword to pkgconfig macros (see #10469) - FindZLIB: GnuWin32 support, version support (#5588) - FindwxWidget: Fix CXX flag parsing (#10209) - Fix .pdb name attribute in VS project files (#10614) - Fix CodeBlocks to work with Fortran-only - Fix VS 2010 custom commands (#10503) - Fix VS 6 support for COMPILE_DEFINITIONS_MINSIZEREL (#10700) - Fix cross-compiling from Linux to iPhone (#10526) - Fix documentation typos - Fix g95 Fortran compiler support - Fix uname masking in file(WRITE) and write_file (#10789) - GetPrerequisites: Provide an override hook - Handle non-ASCII terminators in file(STRINGS) - Module fixes: FindPythonLibs, FindQt4, FindX11, FindwxWidgets - PathScale Fortran compiler tool detection - Qt4 OpenGL framework fix - Qt4ConfigDependentSettings.cmake Qt4Macros.cmake UseQt4.cmake - Recognize ARM ABI/EABI with GNU compilers - Recognize Clang compiler - Search basic directories on "Generic" platform - Set MSVC* variables consistently on all generators, and test - Support SunPro C++ 5.11 on Linux (new compiler) - Support VS 10 Express (related to #10670) - Support compression with 'cmake -E tar' - Support multiple arguments in CC,CXX,FC environment variables - Support per-configuration librarian flags (#10768) - Support per-platform initial ASM language flags (#10577) - Use Fortran ABI detection results conservatively - Use libarchive to replace the unmaintained libtar - UseQt4: Support QtMultimedia (#10675) - bootstrap: Fix make too
Re: [CMake] plugin dependencies and TARGET_LINK_LIBRARIES()
On Wednesday 16 Jun 2010 8:51:27 am you wrote: > On Tuesday 15 Jun 2010 11:32:17 pm Andreas Pakulat wrote: > > On 15.06.10 22:18:04, Kishore wrote: > > > How do i inform cmake when building a module that it depends on another > > > module? Does cmake need to even know that? > > > > > > I am building a plugin based qt application (my first time with > > > plugins) and my situlation like with many other applications is that > > > plugin A depends on plugin B. In my application i take care to load > > > plugin B before A. However, loading plugin A fails complaining that it > > > could not resolve links which are in B. plugin B which only depends on > > > the application loads fine. > > > > > > Now, everything works fine if i declare that plugin A depends on B > > > using the TARGET_LINK_LIBRARIES() function. But for this to work, i > > > have to declare both A and B as SHARED instead of MODULE libraries. > > > > > > What is the right way to go? > > > > Thats not a real plugin system, plugins don't link against other plugins > > directly. Your options are: > > > > - extract the code from B that you need in A into the shared lib (that > > > > you should already have) that both A and B (and your application) link > > against > > This i could do... > > > - provide an interface header from B and a way in your app for a plugin > > > > to get a pointer to such an interface. Then provide the necessary api > > functions you need in A in that interface as pure virtual. That way A > > can use this virtual interface to get at the B functions without > > directly linking against it. > > This I don't fully understand. If A depends in B which would mean that it > extends functionality in B, it would have to call some methods in B. No? > > In my implementation, I have a base class in B that has some pure virtual > functions that are implemented by a class in A. On loading A it registers a > factory object declaring availability of a certain functionality. The > registration API resides in B. > > Apparently, I do not properly understand the concept of one plugin > depending on another. This post has been moved to the more appropriate qt-interest mailing list. -- Cheers! Kishore ___ 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] PROJECT_GROUP
>From the bug Description at http://public.kitware.com/Bug/view.php?id=3796: Visual Studio has "Solution Folders" for grouping Projects (i.e. build targets). Large software projects would benefit from this feature. I suppose the appropriate command would be PROJECT_GROUP, to parallel SOURCE_GROUP. Visual studio also calls them 'filters'. They let you organize your projects into logical groups in the IDE which don't necessarily reflect the layout on disk, for example: Arbitration Arbiters Static Lib Includes\ *.h Src\ *.cpp Arbiters Unit Tests Mocks\ Mock*.* Tests\ Test*.* Cache Cache Static Lib Includes\ *.h Src\ *.cpp Cache Dynamic Lib Includes\ *.h Src\ *.cpp Resources\ *.res Where 'Arbitration' and 'Cache' are simply containers for the projects within them. Once you have a bunch of projects, it makes it easier to navigate when you can group them. I'm really looking forward to this feature being included. Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of James Bigler Sent: Wednesday, June 16, 2010 11:11 AM To: David Cole Cc: cmake Subject: Re: [CMake] PROJECT_GROUP So what is PROJECT_GROUP then? I don't see it in the help pages in branch 'next'. James On Tue, Jun 15, 2010 at 10:29 AM, David Cole wrote: The patch in issue #3796 has not been applied to the CMake 'next' branch yet. I think it is too late to consider for the 2.8.2 release, but it could easily be in for the release after that if it's acceptable as-is. (And somebody pushes it to next for testing on the dashboards...) However, it would be nice to generalize that feature so that it works with Xcode in addition to Visual Studio. There's a note in the bug to that effect. Thanks, David On Tue, Jun 15, 2010 at 4:09 AM, Aeschbacher, Fabrice wrote: Hi, Will the nice PROJECT_GROUP feature described here: http://public.kitware.com/Bug/view.php?id=3796 be in this release? Regards, Fabrice Aeschbacher > > I am happy to announce that CMake 2.8.2 has entered the release > candidate stage! You can find the source and binaries here: > http://www.cmake.org/files/v2.8/. > > Following is the list of changes in this release. (If you notice > something missing please let me know and I will add it to the official > release when 2.8.2 is finalized.) > > Changes in CMake 2.8.2 RC 1 (since CMake 2.8.1) > - Build on Tru64 (#10542) > - Build on mingw-w64 > - Build on old Sun (#10550, #10543) > - CPack: Add native BZip2 support > - CPack: Set compression type in RPM spec (#10363) > - CPack: Try harder to initialize staging directory (#10793) > - CTest: Add --stop-time argument > - CTest: Cost data with '-j' > - CTest: Fix memory report > - CTest: Glob for uncovered files during coverage tests > - CTest: Option to specify cdash server > - CTest: PHP Coverage support > - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd > - CTest: Report failure in Update.xml > - CTest: Submit author email in Update.xml > - CTest: Teach ctest_update about Git submodules > - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) > - Do not list file names during 'cmake -E tar xz' > - Documentation: Comply with "XHTML 1.0 Strict" > - Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291) > - Documentation: Fix typo in HAS_CXX docs (#10578) > - Documentation: More consistent command signatures > - Eclipse: Do not add INCLUDE to environment twice > - Enable extra CodeBlocks generator on Cygwin > - ExternalProject: Support .zip and .bz2 archives, MD5 verification > - ExternalProject: Reconfigure when args change (#10258) > - ExternalProject: Support Git, SVN username/password > - FindCurses: Fix for cygwin ncurses package > - FindHSPELL: Version support > - FindJava: Error if version is not found only when REQUIRED > - FindJava: Support runtime and development components (#9840) > - FindKDE4: Prefer kdeconfig results over system paths > - FindMPEG: Check for 'vo' library > - FindPNG: Support png 1.4 versioned lib names (#10551) > - FindPkgConfig: Add QUIET keyword to pkgconfig macros (see #10469) > - FindZLIB: GnuWin32 support, version support (#5588) > - FindwxWidget: Fix CXX flag parsing (#10209) > - Fix .pdb name attribute in VS project files (#10614) > - Fix CodeBlocks to work with Fortran-only > - Fix VS 2010 custom commands (#10503) > - Fix VS 6 support
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
Hi Bill: I suspect the questions below got lost in the stack of e-mail over last weekend. Anyhow, I am still very much interested in the answers since all questions concern possible limitations in the MinGW/MSYS/CMake/Wine platform, and I am currently putting together a writeup of that platform in Wiki form. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Forwarded message -- Date: Fri, 11 Jun 2010 10:52:31 -0700 (PDT) From: Alan W. Irwin To: Bill Hoffman Cc: cmake Mailing List Subject: Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine On 2010-06-10 22:24-0400 Bill Hoffman wrote: GetShortPath calls GetShortPathName. From http://bugs.winehq.org/show_bug.cgi?id=22286 it appears the point of Clint's patch was to eliminate a specific and well-known hash collision on Wine caused by GetShortPathName, but from all the on-going uses of GetShortPath within CMake shown above, I am concerned there might be other wine name collisions lurking about with cmake causing other issues (e.g., the wine issue I mentioned before where part of the CMake log messages were not being sent to the log file). To address those potential issues, is there a simple way to reduce or eliminate the use of GetShortPath from the CMake code or else replace the call to GetShortPathName within GetShortPath by something else? No, I don't think there is an easy way to get rid of these calls... I am sure there are good reasons, but could you let me know why CMake needs to call GetShortPathName (indirectly via GetShortPath) any more? I have no Windows experience other than this (so far brief) foray into Wine, but I thought long file names were now standard on Windows. I suppose one thing you could try is do have an ifdef wine, and when you call GetShortPath make it a no-opp. Paths with spaces will likely fail, but it would be a good way to see if this is causing other problems. That is a good idea. Since I am only using this particular CMake source tree for Wine, I inserted this into the GetShortPath code: std::cerr << "Aborting after call to SystemTools::GetShortPath with path ="; std::cerr << path; exit(1); My C++ skills are limited so I hope this is a reasonable way to exit the code if there is any attempt to use GetShortPath. Under Wine I built cmake with that change, and then used that version to build cmake again (using the "MinGW Makefiles" generator) with no issues. I then tried ctest under Wine for that cmake build as follows wine ctest -j4 >& ctest.out Some of the tests failed (which I also verified by running them singly). For the "Unhandled page fault" ones below, they hung rather then ever reaching the stage where the summary line was given. Start 16: kwsys.testProcess-4 wine: Unhandled page fault on write access to 0x at address 0x4015e0 (thread 001f), starting debugger... Start 17: kwsys.testProcess-5 wine: Unhandled page fault on write access to 0x at address 0x4015e0 (thread 0018), starting debugger... 22/153 Test #22: CommandLineTest ..***Timeout 1500.34 sec Start 114: CTestTestCrash wine: Unhandled page fault on write access to 0x at address 0x4013da (thread 0036), starting debugger... 123/153 Test #121: CTestTestFailedSubmit-ftp ..***Failed Required regular expression not found.Regex=[(Problems when submitting via S*CP|Error message was: ([Cc]ould *n.t resolve host|[Cc]ould *n.t connect to host|The requested URL returned error|libcurl was built with SSL disabled. https: not supported)|Submission method .xmlrpc. not compiled into CTest|Submission successful) ] 52.66 sec [...] 151/153 Test #150: CMake.GetPrerequisites .***Exception: SegFault292.82 sec 152/153 Test #126: Fortran ***Failed 405.16 sec It does appear that none of these failures have anything to do with GetShortPath if I aborted that possibility correctly above. I don't know for sure, but my guess is the Fortran error is due to https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2981639&group_id=2435 which is a complete showstopper for compiling Fortran 95 source code with MinGW gfortran on Wine. To help understand the above timeout error, my experience with the wine development environment is it is quite sluggish compared to the Linux development environment. For example, the MSYS 'ls' command requires 0.244 seconds to comp
Re: [CMake] PROJECT_GROUP
So what is PROJECT_GROUP then? I don't see it in the help pages in branch 'next'. James On Tue, Jun 15, 2010 at 10:29 AM, David Cole wrote: > The patch in issue #3796 has not been applied to the CMake 'next' branch > yet. I think it is too late to consider for the 2.8.2 release, but it could > easily be in for the release after that if it's acceptable as-is. (And > somebody pushes it to next for testing on the dashboards...) > > However, it would be nice to generalize that feature so that it works with > Xcode in addition to Visual Studio. There's a note in the bug to that > effect. > > > > Thanks, > David > > > > On Tue, Jun 15, 2010 at 4:09 AM, Aeschbacher, Fabrice < > fabrice.aeschbac...@siemens.com> wrote: > >> Hi, >> >> Will the nice PROJECT_GROUP feature described here: >> >> http://public.kitware.com/Bug/view.php?id=3796 >> >> be in this release? >> >> Regards, >> Fabrice Aeschbacher >> >> > >> > I am happy to announce that CMake 2.8.2 has entered the release >> > candidate stage! You can find the source and binaries here: >> > http://www.cmake.org/files/v2.8/. >> > >> > Following is the list of changes in this release. (If you notice >> > something missing please let me know and I will add it to the official >> > release when 2.8.2 is finalized.) >> > >> > Changes in CMake 2.8.2 RC 1 (since CMake 2.8.1) >> > - Build on Tru64 (#10542) >> > - Build on mingw-w64 >> > - Build on old Sun (#10550, #10543) >> > - CPack: Add native BZip2 support >> > - CPack: Set compression type in RPM spec (#10363) >> > - CPack: Try harder to initialize staging directory (#10793) >> > - CTest: Add --stop-time argument >> > - CTest: Cost data with '-j' >> > - CTest: Fix memory report >> > - CTest: Glob for uncovered files during coverage tests >> > - CTest: Option to specify cdash server >> > - CTest: PHP Coverage support >> > - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd >> > - CTest: Report failure in Update.xml >> > - CTest: Submit author email in Update.xml >> > - CTest: Teach ctest_update about Git submodules >> > - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) >> > - Do not list file names during 'cmake -E tar xz' >> > - Documentation: Comply with "XHTML 1.0 Strict" >> > - Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291) >> > - Documentation: Fix typo in HAS_CXX docs (#10578) >> > - Documentation: More consistent command signatures >> > - Eclipse: Do not add INCLUDE to environment twice >> > - Enable extra CodeBlocks generator on Cygwin >> > - ExternalProject: Support .zip and .bz2 archives, MD5 verification >> > - ExternalProject: Reconfigure when args change (#10258) >> > - ExternalProject: Support Git, SVN username/password >> > - FindCurses: Fix for cygwin ncurses package >> > - FindHSPELL: Version support >> > - FindJava: Error if version is not found only when REQUIRED >> > - FindJava: Support runtime and development components (#9840) >> > - FindKDE4: Prefer kdeconfig results over system paths >> > - FindMPEG: Check for 'vo' library >> > - FindPNG: Support png 1.4 versioned lib names (#10551) >> > - FindPkgConfig: Add QUIET keyword to pkgconfig macros (see #10469) >> > - FindZLIB: GnuWin32 support, version support (#5588) >> > - FindwxWidget: Fix CXX flag parsing (#10209) >> > - Fix .pdb name attribute in VS project files (#10614) >> > - Fix CodeBlocks to work with Fortran-only >> > - Fix VS 2010 custom commands (#10503) >> > - Fix VS 6 support for COMPILE_DEFINITIONS_MINSIZEREL (#10700) >> > - Fix cross-compiling from Linux to iPhone (#10526) >> > - Fix documentation typos >> > - Fix g95 Fortran compiler support >> > - Fix uname masking in file(WRITE) and write_file (#10789) >> > - GetPrerequisites: Provide an override hook >> > - Handle non-ASCII terminators in file(STRINGS) >> > - Module fixes: FindPythonLibs, FindQt4, FindX11, FindwxWidgets >> > - PathScale Fortran compiler tool detection >> > - Qt4 OpenGL framework fix >> > - Qt4ConfigDependentSettings.cmake Qt4Macros.cmake UseQt4.cmake >> > - Recognize ARM ABI/EABI with GNU compilers >> > - Recognize Clang compiler >> > - Search basic directories on "Generic" platform >> > - Set MSVC* variables consistently on all generators, and test >> > - Support SunPro C++ 5.11 on Linux (new compiler) >> > - Support VS 10 Express (related to #10670) >> > - Support compression with 'cmake -E tar' >> > - Support multiple arguments in CC,CXX,FC environment variables >> > - Support per-configuration librarian flags (#10768) >> > - Support per-platform initial ASM language flags (#10577) >> > - Use Fortran ABI detection results conservatively >> > - Use libarchive to replace the unmaintained libtar >> > - UseQt4: Support QtMultimedia (#10675) >> > - bootstrap: Fix make tool detection (#10544) >> > - cmake-gui: Add simple grouped view >> > - cmake-gui: Support build tree under symlink (#9975) >> > - Cleanup modules FindASPELL, FindAVIFile, FindBZip2, FindDart, >> > FindEXPAT, FindGCCXML, FindGLU, FindHSPELL, FindJasper, FindLibX
[CMake] CTEST_BUILD_COMMAND conflicts with CTEST_BUILD_TARGET (was Re: 0009835: ctest --help-property CTEST_BUILD_TARGET)
I finally got everything working with cmake 2.8.1, there is just one glitch, one cannot set CTEST_BUILD_COMMAND for CTEST_BUILD_TARGET to work. I added a bug report here: http://cmake.org/Bug/view.php?id=10838 I simply had to comment out my setting: #SET (CTEST_BUILD_COMMAND "make -i") HTH On Tue, Jun 15, 2010 at 2:19 AM, David Cole wrote: > Never mind. I just read the subject line > > You mean this one, right? > http://public.kitware.com/Bug/view.php?id=9835 > > > On Mon, Jun 14, 2010 at 8:17 PM, David Cole wrote: >> What bug are you referring to? >> >> >> On Mon, Jun 14, 2010 at 12:58 PM, wrote: >>> Hi there, >>> >>> I reported a bug a couple of month back, which apparently was fixed with >>> "Closing this since the new TARGET option for CTEST_BUILD is well >>> documented." >>> >>> I am looking at the git web interface of ctest_build: >>> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestBuildCommand.h;h=228067e44c0bc5ef98cf6b21e2a47e3ba93d29ba;hb=HEAD >>> >>> I cannot find mention of neither CTEST_BUILD + TARGET nor >>> CTEST_BUILD_TARGET. >>> >>> Could someone please point me to the documentation that is reference in the >>> bug report ? >>> >>> Thanks ! >>> -- >>> Mathieu >>> >>> >>> ___ >>> 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 >>> >> > -- Mathieu ___ 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] vcproj2cmake.rb script: announcing new version / hosting questions
Hi, On Mon, Jun 14, 2010 at 05:00:47PM +0200, Andreas Mohr wrote: > On Mon, Jun 14, 2010 at 09:54:58AM -0400, Bill Hoffman wrote: > > To be compatible with CMake, I would say a BSD license would be the > > best. gitorious might be a good starting place. We tried the converter > > here, and it created some odd CMAKE_BUILD_TYPE stuff in the CMake files, > > that looked like it would not work with the IDE generators. > > CMAKE_BUILD_TYPE is NOT used for IDE project files. > > Ah, right. > That would perhaps need a solution like the (in)famous > if(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE) > which I've been using at several other places but didn't think of > correcting when working on this area of the original script. > (to be fair, I haven't attempted a full-circle conversion to .vcproj on > Windows yet) > > Thinking more about it, I'm not quite sure how to reach 100% > preservation of original .vcproj content this way (when doing a > full-circle conversion, that is). > After all in an original .vcproj file there are full configurations for > Debug, Release etc. (which the user then selects in the IDE). > Thus the converted CMakeLists.txt would _somehow_ have to contain the > same entire content, like it now does with our - quite obviously insufficient > - > CMAKE_BUILD_TYPE branching. I've spent some time analyzing this, and indeed there of course is a clean way to isolate this from single-configuration generators' CMAKE_BUILD_TYPE stuff, e.g. by defining per-configuration settings such as set_property(TARGET ... COMPILE_DEFINITIONS_MINSIZEREL ...) **HOWEVER**, well, in fact it's all falling apart after all: "[CMake] Add configuration support to include_directories()": http://www.mail-archive.com/cmake@cmake.org/msg18270.html is the #1 reason that a full round-trip .vcproj --> CMakeLists.txt --> .vcproj will _NOT_ retain all project content satisfactorily (i.e. we will have to make the hard choice of hard-coding _either_ the Release _or_ the Debug .vcproj Configuration's AdditionalIncludeDirectories setting in the resulting converted CMakeLists.txt), since there isn't a per-configuration include_directories() setup yet (at least according to that thread's discussion). Houston... Hmm, create bug report? Andreas Mohr ___ 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] NCurses issues with OS X 10.6.3 and ccmake
On Tue, 15 Jun 2010 18:05:06 -0400, Michael Jackson said: >Just FYI that Apple released the OS X 10.6.4 update today that among >other things _should_ have fixed the messed up ncurses library that >stopped the arrow keys from working with ccmake. > As usual use the usual update mechanisms that Apple provides. If >anyone _does_ update could you post back to the list to verify that >the curses problem is either fixed or still remains broken. I can confirm it's fixed. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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] vcproj2cmake.rb script: announcing new version / hosting questions
On Tue, Jun 15, 2010 at 11:10:37AM +0200, Jesper Eskilson wrote: > On 06/14/2010 05:00 PM, Andreas Mohr wrote: > >> Frankly the entire distinction between CMAKE_CONFIGURATION_TYPES >> and CMAKE_BUILD_TYPE remains one of the more confusing things, >> as can be witnessed in several confused postings about this topic. >> (but I'm afraid that's just the way it is - there's nothing to be >> improved about these mechanisms since they're likely just doing what they >> should) > > The biggest annoyment I have with CMake is the fact the the makefile > generators don't support building multiple configurations in the same > build tree. Not sure if it would be practical to fix, though. Well, myself I'm not sure whether this is what I would want. I'd say it's a _feature_ that a Debug configuration is fully isolated from any other configuration. After all when packaging stuff you (normally) wouldn't want to ship many differing configurations in the same Gordian Knot. What's so problematic about having isolated build directories (out-of-tree) for multiple configurations? OTOH if one _is_ focussing on having multiple configurations shipped within the same installer package (for whatever reason - say different variants shipped in the same codebase), then this IMHO not so useful feature is legitimate after all. Andreas Mohr ___ 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: removing NSI "Install Options" and "Choose Start Menu Folder" pages from installation wizard
I am trying to remove the "Install Options" and "" page from the install script. The "Install Options" is not required since I do not plan on adding this project installation directory to the system PATH environment variable. Also since I am installing a static library I don't see the need for adding a Start Menu entry. I was wondering if anyone had code example that would help me. Stephen ___ 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 2.8.2 RC1 <-> Visual Studio Express
Am Mittwoch, den 16.06.2010, 06:56 -0400 schrieb David Cole: > On Wed, Jun 16, 2010 at 1:26 AM, Micha Renner > wrote: > There still some problems with the Express version of VS > I started the gui-version of CMake and generated the solution > files > (empty build directory). No errors. > > First run in the IDE generates a lot of CMake errors (see > appendix). > > > CMake should not have to re-run during a build like this... Oh no, this is exactly what I need. See my posts yesterday. > Is your project available as open source so that we can download it > and try it here? Or could you send me a zip of your source tree > off-list, if possible? Done > There must be something else going on with the CMake files in this > project to see a result like this. > > > > Another hit on the F7 key: Most errors are gone. > Okay, I can live with this, others may be not. > > A bad point is what happens, if there is change in the script > files. > - the IDE saves all files (ok) > - CMake starts (ok) > - the compiler/linker starts and works with the old solution > files > - the new generated solution files are loaded in the IDE (too > late). > > The problems with the filter-files are gone, very good, but > there are > still the problems with the reloading of solution files if > they are not > changed. I know this is an old problem, but it still exists. > > > Since Visual Studio Express does not support macros, the > auto-reload-during-build macros that CMake supplies are not involved > in this scenario. Because of this fact, the workflow of "staying in > the native build tool" after the first CMake run is never going to > work well with the Express editions of VS. This old problem is still > going to exist, and it's just going to get older. Okay, now I understand. We have had this point alredy, but now it is clear. > > > Therefore, I would strongly recommend exiting VS Express prior to > running CMake, running cmake or cmake-gui standalone without VS > Express running, and then re-launching VS Express to build. This is an emergency nail only, but it is okay. > > > Or: upgrade to a paid version of VS so that the macros have a chance > to work. I think there will be more Express users in the future. Greetings Micha ___ 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] Combining projects made by several CMake solutions into 1 solution
On 6/15/10 11:13 PM, ben...@cs.its.ac.id wrote: Hi, I'm currently using some projects that solutions are built from CMake. They are Delta 3D, Open Scene Graph, osgOcean, and dtOcean. So what I wanted is to combine a few of those projects into one solution so I don't have to make them separately and for better organization. I know that I also must include the ALL_BUILD and ZERO_CHECK projects so that the IDE won't have to rebuild the projects all the time. But can one ZERO_CHECK work for projects from different solutions? BTW, my IDE is Visual C++ 2005. Thanks in advance. Fare thee well, Bawenang R. P. P. Take a look here: this might serve your needs. http://cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject Ryan -- Ryan Pavlik Human-Computer Interaction Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com/ ___ 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 2.8.2 RC1 <-> Visual Studio Express
On Wed, Jun 16, 2010 at 1:26 AM, Micha Renner wrote: > There still some problems with the Express version of VS > I started the gui-version of CMake and generated the solution files > (empty build directory). No errors. > > First run in the IDE generates a lot of CMake errors (see appendix). > CMake should not have to re-run during a build like this... Is your project available as open source so that we can download it and try it here? Or could you send me a zip of your source tree off-list, if possible? There must be something else going on with the CMake files in this project to see a result like this. > Another hit on the F7 key: Most errors are gone. > Okay, I can live with this, others may be not. > > A bad point is what happens, if there is change in the script files. > - the IDE saves all files (ok) > - CMake starts (ok) > - the compiler/linker starts and works with the old solution files > - the new generated solution files are loaded in the IDE (too late). > > The problems with the filter-files are gone, very good, but there are > still the problems with the reloading of solution files if they are not > changed. I know this is an old problem, but it still exists. > Since Visual Studio Express does not support macros, the auto-reload-during-build macros that CMake supplies are not involved in this scenario. Because of this fact, the workflow of "staying in the native build tool" after the first CMake run is never going to work well with the Express editions of VS. This old problem is still going to exist, and it's just going to get older. Therefore, I would strongly recommend exiting VS Express prior to running CMake, running cmake or cmake-gui standalone without VS Express running, and then re-launching VS Express to build. Or: upgrade to a paid version of VS so that the macros have a chance to work. HTH, David > Greetings > > Micha > > > ___ > 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
