Re: [cmake-developers] CMake bug tracker discussion
2010/12/9 David Cole david.c...@kitware.com: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I would personally vote for keeping both. I'd like to keep ML bug related activities for: 1) Having preliminary discussion like Is this a bug or not? If it is a feature request is it worth a formal request ...? 2) Public poll directed to people who seldom browse the bug tracker. Then use the tracker: 1) When we are sure (with or without discussion) that the issue is a bug or a feature request. 2) Because one NEEDS to keep track of changes, bug fixes etc... So my opinion is that BOTH are mandatory, including the usage of the ML for bug handling but may be some common usage rules may be advertised. Now I agree that may be the systematic handling of bugs filed into the tracker has to be improved but I think it already started. As external free-time contributor to CMake I was granted commit right when CMake was using CVS, it's even more easy now with git since I can autonomously commit patches to next branch (see CMake workflow http://www.cmake.org/Wiki/CMake/Git) which is regularly (once a week) merged to master by Kitware. I do get (I don't remember since when) a copy of each new bug entered in the tracker so that I can (autonomously) assign those bugs to myself if do think I can handle it. If I cannot (not enough time or not my expertise zone) but I'm interested in the bug I do add myself to the monitor list and may add some personal comments to the bug report. So to comment to Pau remark: Maybe you could start by having some people from outside of Kitware (apart from Alex ;-) ) help with triaging bugs and commit patches and not-too-complex features. I'll try to do that myself but I'm far away from Alex efficiency :-] May be helping the bug triage would be nice, may be some people may search the bug tracker for unassigned and oldish bugs and send some list of such bugs from time to time on the cmake-developer ML? I know that some Kitware people do that (searching the Bug Tracker) from time to time but I do not know if it is systematic nor periodic :-) May be opening a Wiki page with the list of CMake developers (Kitware and outsiders) with their domain of CMake expertise may help triage volunteer to contact them about the unassigned and oldish bug? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 7:19 PM, Eric Noulard eric.noul...@gmail.com wrote: 2010/12/9 David Cole david.c...@kitware.com: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I would personally vote for keeping both. I'd like to keep ML bug related activities for: 1) Having preliminary discussion like Is this a bug or not? If it is a feature request is it worth a formal request ...? 2) Public poll directed to people who seldom browse the bug tracker. Then use the tracker: 1) When we are sure (with or without discussion) that the issue is a bug or a feature request. 2) Because one NEEDS to keep track of changes, bug fixes etc... So my opinion is that BOTH are mandatory, including the usage of the ML for bug handling but may be some common usage rules may be advertised. Now I agree that may be the systematic handling of bugs filed into the tracker has to be improved but I think it already started. As external free-time contributor to CMake I was granted commit right when CMake was using CVS, it's even more easy now with git since I can autonomously commit patches to next branch (see CMake workflow http://www.cmake.org/Wiki/CMake/Git) which is regularly (once a week) merged to master by Kitware. I do get (I don't remember since when) a copy of each new bug entered in the tracker so that I can (autonomously) assign those bugs to myself if do think I can handle it. We added that a couple months ago to raise awareness of new bugs being entered to the mailing list community. If I cannot (not enough time or not my expertise zone) but I'm interested in the bug I do add myself to the monitor list and may add some personal comments to the bug report. So to comment to Pau remark: Maybe you could start by having some people from outside of Kitware (apart from Alex ;-) ) help with triaging bugs and commit patches and not-too-complex features. I'll try to do that myself but I'm far away from Alex efficiency :-] May be helping the bug triage would be nice, may be some people may search the bug tracker for unassigned and oldish bugs and send some list of such bugs from time to time on the cmake-developer ML? This is a great idea. Is there anybody out there on these mailing lists that would like to contribute simply by organizing bugs and communicating about them with the reporters and the developers involved? It would be good to have extra eyes and hands poking around in the oldish and unassigned... I know that some Kitware people do that (searching the Bug Tracker) from time to time but I do not know if it is systematic nor periodic :-) As of our new release procedures since switching to git, we're doing this at least once every patch release of CMake, which we hope to keep going on a quarterly basis (4x a year) moving forward. May be opening a Wiki page with the list of CMake developers (Kitware and outsiders) with their domain of CMake expertise may help triage volunteer to contact them about the unassigned and oldish bug? I don't think this is necessary. We can use the mailing list for this function. And/or simply add notes in the bugs. Reporters, assignees and interested monitors all get notified by email already as notes are added to bugs. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Again, thanks for your input. This is one of the things that's really nice about working with the CMake community. You are for the most part, a bunch of thoughtful, deliberately spoken folk, whose opinion I value very highly. Thanks, David Cole ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Simultaneous --build-and-test and CDash submission
Hi,
I have unit tests configured for CDash submissions. Submissions do work if I
issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test phase -
build info is missing and configure info shows only 3 lines despite removal of
CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this to work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental --build-and-test
. . --build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although it
submission is achieved the CDash contents is the same as with the original two
commands.
So my question is how to achieve CDash submission with 'scratch' configure info
(just as if cmake was invoked on clean environment), build info (compilation
warnings and such) and test results by issueing single command ?
Thanks for help,
Wojtek
--
Księgowa radzi: Jak załozyć firmę w 15 minut?
http://linkint.pl/f2842
___
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] Simultaneous --build-and-test and CDash submission
On 9-12-2010 at 10:13, in message mwkqnalvczcgriuir...@oodl,
Wojciech Migda
wojtek.g...@interia.pl wrote:
Hi,
I have unit tests configured for CDash submissions. Submissions do
work if I
issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test
phase
- build info is missing and configure info shows only 3 lines despite
removal
of CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this
to work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental
--build-and-test . . --build-generator 'Unix Makefiles'
--build-makeprogram
`which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which
clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although
it
submission is achieved the CDash contents is the same as with the
original
two commands.
So my question is how to achieve CDash submission with 'scratch'
configure
info (just as if cmake was invoked on clean environment), build info
(compilation warnings and such) and test results by issueing single
command ?
Thanks for help,
Wojtek
Hi Wojtek,
If I understand you correctly, then you would in fact like to run ctest
without cmake. You can do that, be you'll need some plumbing (i.e. a
small ctest-script) to get ctest going. I think you'll find
http://www.cmake.org/Wiki/CTest:Using_CTEST_and_CDASH_without_CMAKE
useful.
Hope this helps,
Marcel Loose.
___
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] Did anyone manage to get incremental linking working with NMake generator?
Thanks Bill for the trick. Unfortunately this works only for exe targets. It doesn't work for dll's. Moreover, before the link command there is this output: Visual Studio Non-Incremental Link Below you have the verbose build output (regardless if it's the first, 2nd, etc). Maybe this helps. Linking CXX shared library zorba_simplestore.dll cd C:\Users\Gabriel\Work\28msec\zorba\builds\debug10\src C:\Program Files\CMake 2.8\bin\cmake.exe -E vs_link_dll C:\PROGRA~1\MICROS~2.0\VC\bin\link.exe /nologo @CMakeFiles\zorba_simplestore.dir\objects1.rsp @C:\Users\Gabriel\AppData\Local\Temp\nm565E.tmp *Visual Studio Non-Incremental Link* LINK: C:\PROGRA~1\MICROS~2.0\VC\bin\link.exe /nologo @CMakeFiles\zorba_simplestore.dir\objects1.rsp /out:zorba_simplestore.dll /implib:zorba_simplestore.lib /pdb:C:\U sers\Gabriel\Work\28msec\zorba\builds\debug10\src\zorba_simplestore.pdb /dll /version:1.5 /STACK:1000 /machine:X86 /debug C:\Users\Gabriel\Work\28msec\tools \curl_7_19_3\libcurl_imp.lib C:\Users\Gabriel\Work\28msec\tools\tidy\lib\tidy.lib C:\Users\Gabriel\Work\28msec\tools\iconv\lib\iconv.lib C:\Users\Gabriel\Work\2 8msec\tools\icu_4_4_1_src\lib\icuuc.lib C:\Users\Gabriel\Work\28msec\tools\icu_4_4_1_src\lib\icuin.lib C:\Users\Gabriel\Work\28msec\tools\icu_4_4_1_src\lib\icud t.lib C:\Users\Gabriel\Work\28msec\tools\libxml2\lib\libxml2.lib C:\Users\Gabriel\Work\28msec\tools\xerces-c-3.1.1-x86-windows-vc-10.0\lib\xerces-c_3.lib C:\Use rs\Gabriel\Work\28msec\tools\libxml2\lib\libxml2.lib ..\external\json\json.lib wsock32.lib C:\Users\Gabriel\Work\28msec\tools\xerces-c-3.1.1-x86-windows-vc-10.0 \lib\xerces-c_3.lib wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST *LINK : zorba_simplestore.dll not found or not built by the last incremental link; performing full link* Creating library zorba_simplestore.lib and object zorba_simplestore.exp MT: C:/Program Files/Microsoft SDKs/Windows/v7.0A/bin/mt.exe /nologo /manifest zorba_simplestore.dll.manifest /outputresource:zorba_simplestore.dll;#2 cd C:\Users\Gabriel\Work\28msec\zorba\builds\debug10 On Thu, Dec 9, 2010 at 5:10 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 12/8/2010 10:18 PM, Bill Hoffman wrote: On 12/8/2010 4:21 PM, Gabriel Petrovay wrote: Yes I did. That is why I am wrote this post. Regardless of previous build. I always get: LINK : examples.exe not found or not built by the last incremental link; performing full link Try a make VERBOSE=1 with the /incremental:yes on, and post the results of the second build that should be incremental. Never mind, I have reproduced the problem. It seems like the incremental linking is broken for VS 2010 nmake. To get it to work, you have to do add /INCREMENTAL:YES to CMAKE_EXE_LINKER_FLAGS_DEBUG, you get a warning but it does the correct thing with mt and the incremental linking: [ 75%] Built target simpleLib Scanning dependencies of target Simple [100%] Building CXX object CMakeFiles/Simple.dir/simple.cxx.obj simple.cxx Linking CXX executable Simple.exe LINK : warning LNK4224: /INCREMENTAL:YES is no longer supported; ignored [100%] Built target Simple I will have to figure out a new way to add incremental linking to VS2010. -Bill -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.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] Platform differences for ExternalProject_add URL
On Wed, Dec 8, 2010 at 5:17 PM, KC Jones kc.jo...@skype.net wrote: [resending since the original seems to have never made it to the list.] I'm using ExternalProject_add in a script that builds various libraries I depend on, and I'm running into platform differences when attempting to download a source archive from a sourceforge URL. Sounds like a bug to me. But I'm also guessing that sourceforge may be redirecting the URL get request, which may account for the problems on Linux -- and there may be better ways for me to get my task done. The following unexpurgated CMakeLists.txt works on Mac (10.6.4), but the download fails (0byte result) on Linux (Ubuntu 10.04): -- cmake_minimum_required(VERSION 2.8) include(ExternalProject) ExternalProject_Add( poco-1.3.6 PREFIX poco URL http://downloads.sourceforge.net/project/poco/sources/poco-1.3.6/poco-1.3.6p2.tar.gz CONFIGURE_COMMAND ../poco-1.3.6/configure --no-tests --no-samples --omit=Util,Net,Crypto,NetSSL_OpenSSL,Data,Data/SQLite,Data/ODBC,Data/MySQL,Zip BUILD_COMMAND make ) -- Any words of wisdom for a cmake newbie? KC Jones kc.jo...@skype.net SkypeId: bernalkc ___ 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 What version of cmake are you using? ( 'cmake --version' and send us the output ) We added follow redirect flags to the file(DOWNLOAD command in this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef491f78218e255339278656bf6dc26073fef264 ...which first appeared in CMake 2.8.2. If you're using 2.8.0 or 2.8.1, just upgrade to the latest version (2.8.3) and it should work for you. HTH, David ___ 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] Simultaneous --build-and-test and CDash submission
On Thu, Dec 9, 2010 at 4:13 AM, Wojciech Migda wojtek.g...@interia.pl wrote:
Hi,
I have unit tests configured for CDash submissions. Submissions do work if I
issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test phase -
build info is missing and configure info shows only 3 lines despite removal
of CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this to work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental
--build-and-test . . --build-generator 'Unix Makefiles' --build-makeprogram
`which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although it
submission is achieved the CDash contents is the same as with the original
two commands.
So my question is how to achieve CDash submission with 'scratch' configure
info (just as if cmake was invoked on clean environment), build info
(compilation warnings and such) and test results by issueing single command ?
Thanks for help,
Wojtek
--
Księgowa radzi: Jak załozyć firmę w 15 minut?
http://linkint.pl/f2842
___
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
How about this?
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# run an Experimental dashboard
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest -D Experimental
Running an Experimental dashboard should execute configure, build and
test steps and submit the results to the CDash server. The initial
configure is necessary to configure some of the files that ctest reads
to know, for example, where the CDash server is.
HTH,
David
___
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] Get diagnostics when FIND_XXX fails
Hi all, Is there a way to get useful diagnostics when, e.g., FIND_PATH() fails. I would like to be able to get a message like: Failed to find myheader.h, while searching the following directories: /foo /bar /baz. Now, I often find myself browsing a FindXXX.cmake file when it fails to find some file, and try to understand why it couldn't find it. This is not as easy as it sounds, due to the fact that the FIND_XXX command have a quite a number of options, like HINTS and PAHTS, which makes it quite hard to figure out which directories have been searched. As a last resort I sometimes use strace, but this is IMHO really not the way it should be. Best regards, Marcel Loose. ___ 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] Did anyone manage to get incremental linking working with NMake generator?
On 12/9/2010 5:26 AM, Gabriel Petrovay wrote: Thanks Bill for the trick. Unfortunately this works only for exe targets. It doesn't work for dll's. Moreover, before the link command there is this output: Visual Studio Non-Incremental Link If it says that then the /INCREMENTAL flag is not being used. You have to set the CMAKE_SHARED_LINKER_FLAGS_DEBUG flag for this to work with dlls, may also want to set this one: CMAKE_MODULE_LINKER_FLAGS_DEBUG. -Bill ___ 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] Problem using Lahey Fortran Compiler
Hello everybody, I would like to build a Fortran static library using the Lahey Fortran Compiler. When building my project with the following command: cmake -G NMake Makefiles -D CMAKE_Fortran_COMPILER=lf95 .. --debug-trycompile the build crash with the following starting line: -- The Fortran compiler identification is unknown -- Check for working Fortran compiler: C:/LF9556/Bin/lf95.exe -- Check for working Fortran compiler: C:/LF9556/Bin/lf95.exe -- broken CMake Error at C:/CMake2.8/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:40 (MESSAGE): The Fortran compiler C:/LF9556/Bin/lf95.exe is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Datas/Eclipse_Projects/Fortran/crysfml/build/lf95_release/CMakeFiles/CMakeTmp So it seems that the building was not able to even pass the testing step. What I do not understand is: - why the compiler identification is unknown as Lahey compiler is normally supported by CMake ? Is it really supported ? - why the test crashed as when I go to the CMakeTmp directory and run explicitely the compilation of the test program (BTW a simple hello world) the compilation works ? any idea thansks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Simultaneous --build-and-test and CDash submission
So my question is how to achieve CDash submission with 'scratch' configure info (just as if cmake was invoked on clean environment), build info (compilation warnings and such) and test results by issueing single command ? Thanks for help, Wojtek Hi Wojtek, If I understand you correctly, then you would in fact like to run ctest without cmake. You can do that, be you'll need some plumbing (i.e. a small ctest-script) to get ctest going. I think you'll find http://www.cmake.org/Wiki/CTest:Using_CTEST_and_CDASH_without_CMAKE useful. Hope this helps, Marcel Loose. I don't have anything against calling cmake along the way - I just hoped ctest can take care of that by itself allowing just single ctest invocation. Wojtek -- Zasypalo Twoje miasto? Zobacz zdjecia http://linkint.pl/f289f ___ 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] Simultaneous --build-and-test and CDash submission
Użytkownik napisał(a):
From:
Subject: Re: [CMake] Simultaneous --build-and-test and CDash submission
To: Wojciech Migda ;
On Thu, Dec 9, 2010 at 4:13 AM, Wojciech Migda wrote:
Hi,
I have unit tests configured for CDash submissions. Submissions do work if
I issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test phase
- build info is missing and configure info shows only 3 lines despite
removal of CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this to work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental
--build-and-test . . --build-generator 'Unix Makefiles' --build-makeprogram
`which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although it
submission is achieved the CDash contents is the same as with the original
two commands.
So my question is how to achieve CDash submission with 'scratch' configure
info (just as if cmake was invoked on clean environment), build info
(compilation warnings and such) and test results by issueing single command
?
Thanks for help,
Wojtek
--
Księgowa radzi: Jak załozyć firmę w 15 minut?
http://linkint.pl/f2842
___
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
How about this?
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# run an Experimental dashboard
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest -D Experimental
Running an Experimental dashboard should execute configure, build and
test steps and submit the results to the CDash server. The initial
configure is necessary to configure some of the files that ctest reads
to know, for example, where the CDash server is.
HTH,
David
Thank you David - I got the compilation warnings to appear in the CDash listing.
In addition, can sth be done with the Configure Output ? In CDash it goes like
this (all 3 lines):
-- Configuring done
-- Generating done
-- Build files have been written to: foo_location
whilst I'd like to have it in full, like when CMake is initially invoked, e.g:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
... snip
Thanks,
Wojtek
---
Nadal nie wiesz, co wybrac na prezent?
Sprawdz nasz poradnik http://linkint.pl/f2885
http://linkint.pl/f2885
___
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] Simultaneous --build-and-test and CDash submission
On Thu, Dec 9, 2010 at 10:44 AM, Wojciech Migda wojtek.g...@interia.pl wrote:
Użytkownik napisał(a):
From:
Subject: Re: [CMake] Simultaneous --build-and-test and CDash submission
To: Wojciech Migda ;
On Thu, Dec 9, 2010 at 4:13 AM, Wojciech Migda wrote:
Hi,
I have unit tests configured for CDash submissions. Submissions do work if
I issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test
phase - build info is missing and configure info shows only 3 lines
despite removal of CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this to
work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental
--build-and-test . . --build-generator 'Unix Makefiles'
--build-makeprogram `which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although it
submission is achieved the CDash contents is the same as with the original
two commands.
So my question is how to achieve CDash submission with 'scratch' configure
info (just as if cmake was invoked on clean environment), build info
(compilation warnings and such) and test results by issueing single
command ?
Thanks for help,
Wojtek
--
Księgowa radzi: Jak załozyć firmę w 15 minut?
http://linkint.pl/f2842
___
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
How about this?
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# run an Experimental dashboard
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest -D Experimental
Running an Experimental dashboard should execute configure, build and
test steps and submit the results to the CDash server. The initial
configure is necessary to configure some of the files that ctest reads
to know, for example, where the CDash server is.
HTH,
David
Thank you David - I got the compilation warnings to appear in the CDash
listing.
In addition, can sth be done with the Configure Output ? In CDash it goes
like this (all 3 lines):
-- Configuring done
-- Generating done
-- Build files have been written to: foo_location
whilst I'd like to have it in full, like when CMake is initially invoked, e.g:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
... snip
Thanks,
Wojtek
---
Nadal nie wiesz, co wybrac na prezent?
Sprawdz nasz poradnik http://linkint.pl/f2885
http://linkint.pl/f2885
You can do it all in one step with ctest, but you have to write a
ctest -S script, and call that... Inside it, you can do a configure
from scratch using the ctest_configure(...) command. Then you'll see
all the configure output submitted to the dashboard.
Poke around the wiki and the mailing list for ctest -S script
documentation. (Go with a new style script that uses the commands
'ctest_configure' and 'ctest_build' and 'ctest_test'.) Maybe somebody
else has time to chime in and give you more details.
Cheers,
David
___
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] General LABELS questions
Hi,
I'm trying to get LABELS/Subprojects working, having read this
http://www.kitware.com/blog/home/post/11 and this
http://www.kitware.com/blog/home/post/11
1. It is unclear to me whether to have LABELS working I must use CTest script
(-S) or I can achieve that simply by editing of CMakeLists.txt,
CTestConfig.cmake, CTestCustom.cmake.
2. Once I get LABELS working is it possible to browse results in CDash by
LABEL, e.g. see all submissions with given label attached, but not having
SubProject named after LABEL ?
I've reached a point where in the tests summary CDash shows expected label
along each testcase, e.g:
Name;Status;Time (s);Labels
foo_test;Passed;0.01;MY_LABEL
However, in the Experimental submissions section Labels column in empty: (none).
Same with Subproject created with a name MY_LABEL being a child of the project
within I make submission.
I have a library target named MY_LABEL, for which I set:
set_property(TARGET MY_LABEL PROPERTY LABELS MY_LABEL)
for each testcase $tc added with ADD_TEST I set:
set_property(TEST ${tc} PROPERTY LABELS MY_LABEL)
Thank you,
Wojtek
--
Japonia czy Niemcy?
Tutaj znajdziesz samochody z całego świata!
Sprawdź http://linkint.pl/f288b
___
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] providing library information, what's the cmake way
At this point of the discussion, I think that we need someone else to
join. We both have made strong points for our viewpoints, and neither of
us has a perfect solution.
On Sunday 05 December 2010 12:48:49 Michael Hertling wrote:
On 12/01/2010 05:57 PM, Johannes Zarl wrote:
On 12/01/2010 at 16:06, Michael Hertling mhertling at online.de
wrote:
These variables are well-known and officially recommended for
component- less packages only. Nobody bothered to write
recommendations for component-packages yet.
${CMAKE_ROOT}/Modules/readme.txt mentions the XXX_YYY_EXECUTABLE and
XXX_YY_{LIBRARY,INCLUDE_DIR} variables explicitly, and IMO, wordings
as YYY tool that comes with XXX or YY library that is part of the
XXX system allow the general terms tool and part to be applied
smoothly to the components of a package. Furthermore, the component-
specific variables like XXX_FIND_COMPONENTS are handled also, so I
do believe that this file is relevant for multi-component packages,
too, including the XXX_{LIBRARIES,INCLUDE_DIRS} variables. However,
variables like XXX_YYY_{LIBRARIES,INCLUDE_DIRS} are not mentioned
at all, i.e. there're completely new and should be well founded.
IMO the wording is ambiguous. When I read it, it was obvious to me that
the XXX_YYY_LIBRARIES etc. are to be defined. To quote readme.txt:
XXX_EXECUTABLE Where to find the XXX tool.
XXX_YYY_EXECUTABLE Where to find the YYY tool that comes with XXX.
I assumed XXX_YYY_EXECUTABLE as an example, so that not every variable
has to be mentioned a second time in its component-specific form.
Now that I heard your interpretation and reread readme.txt, it fits the
description just as well.
Anyway, the ${CMAKE_ROOT}/Modules/readme.txt doesn't handle multi-
component packages thouroughly, so I would greatly appreciate any
improvements to decrease ambiguities/uncertainties and to reach a
consensus. For this reason, I regret that we haven't seen further
opinions on this topic, in particular because pretty much every
non-trivial package could make good use of a components-aware
find module or config file.
As I have written above, I totally agree.
The problem is that FPHSA simply wasn't created with components in
mind. As worthwhile as code-reuse is, it's not a goal in itself.
Rather than jump through hoops in order to reuse the existing
interface, IMO one should create a good interface for the more
complex use-case at hand.
To apply FPHSA to a component and, thus, re-use existing code, I just
need to define two variables; this is not jumping through hoops.
Setting a specific variable for its side-effects before calling a
function makes a truly bad interface-style for me. Regardless of the
outcome of this discussion, I'll create a patch for the FPHSA module
introducing the component-keyword (once, I have time, whenever that is;
a totally different topic is whether the patch will be included to
cmake).
Suppose you have components YYY and ZZZ with ZZZ depending on YYY.
When handling ZZZ in the find module, there's a certain probability
that you must access the YYY stuff, so one would like to have the
XXX_YYY_FOUND variable already defined at this time.
This is a sensible assumption, and should be supported by a component-
aware FPHSA...
With the
FPCHSA, the components' FOUND variables are defined in one go at the
module's end; hence, one has to check YYY's availability by oneself
when it's needed for ZZZ, and FPCHSA will do the same work once more
later.
Well, there currently does not exist a single line of code for a
component-aware FPHSA. If it were to be implemented like this, There
wouldn't be much incentive to use it.
Instead, IMO, it's convenient to check a component's presence
right after the relevant variables have received their values, and
for this purpose, FPHSA is entirely sufficient.
Apart from the whole defining-variables-for-side-effect thing, yes.
Still this would benefit from component-awareness:
...
FPHSA(XXX XXX_LIBRARIES XXX_INCLUDE_DIRS)
#detect component YYY
FPHSA(XXX COMPONENT YYY XXX_YYY_FOO XXX_YYY_BAR)
...
find_package( XXX COMPONENTS YYY)
target_link_libraries(foo ${YYY_LIBRARIES})
find_package( XXX COMPONENTS ZZZ)
target_link_libraries(bar ${ZZZ_LIBRARIES})
At this point, I just realised that I was being inconsistent. After
all, the components do depend on the whole package. So
YYY_LIBRARIES should also contain XXX_LIBRARIES.
If I understand correctly, you intend to populate XXX_YYY_LIBRARIES,
e.g., with its own value XXX_YYY_LIBRARY *and all* its prerequisite
components' values, too? If so, you will end up with many repeatedly
mentioned libraries on the link command line unless there're hardly
any inter-component dependencies. Suppose ZZZ depends on YYY, so
I have to admit that I didn't encounter a use-case with inter-component
dependencies before this discussion, so my thoughts on this might be
called developing.
Re: [CMake] test property COST not working in cmake 2.8.3?
Ok I've added a link to this thread and the patch below to the bug:
http://www.vtk.org/Bug/view.php?id=11561
Without feedback from anyone, I will assume that I have done an awesome,
production-ready job and will await the call for patches to add to CMake
2.8.4.
Thanks,
tyler
On Tue, Dec 07, 2010 at 09:37:09PM -0800, Tyler Roscoe wrote:
In the process of attempting to fix this, I learned a lot of stuff about
how COST is handled that I've never encountered in the docs. Am I
missing something?
Here are some notes I made about the behavior of COST in CTest. If
others find them useful, I'd be happy to put them in the Wiki if someone
could nominate an appropriate place.
- Any COST property you set on a test is only a starting point. CTest
calculates an average cost value for a test each time that test is
run. This value is cached in Testing/Temporary/CTestCostData.txt.
- Tests that fail are also stored in
Testing/Temporary/CTestCostData.txt. On the next run, these tests have
their cost set to the maximum to insure that they are run first. I
believe this factors into later averaging, so that tests that fail more
frequently run earlier than tests that faill less frequently.
So, my solution. I've tried to implement Zach's suggested middle
ground.
For non-parallel CTest runs:
- The run failed tests first behavior is disabled to prevent failed
tests from clobbering their given COST property.
- The stored values in CTestCostData.txt are not used.
- As long as std::sort() is stable, the COST for each test should remain
0 and the tests should run in the order encountered in CMakeLists.txt.
For parallel CTest runs, failed tests run first and the moving average
is calculated and used. I think it makes sense that if you ask for tests
to run in parallel, you probably don't care so much about the order
(modulo test dependencies) so it is more reasonable to throw out the
COST data provided by the CMakeLists.txt.
I'm not really a C++ dev so please let me know if I'm way off base.
This patch appears to solve my immediate problem but if it can be
included upstream that is better for everyone.
The patch is against the 2.8.3 release.
I've also included a simple CMakeLists.txt for testing and verifying
behavior. Unpatched ctest 2.8.3 runs the tests in reverse order. Patched
ctest runs them according to COST.
##
### PATCH
##
--- ./Source/CTest/cmCTestMultiProcessHandler.cxx.orig 2010-12-07
15:31:57.091228582 -0800
+++ ./Source/CTest/cmCTestMultiProcessHandler.cxx 2010-12-07
19:59:11.115740666 -0800
@@ -434,9 +434,14 @@
if(index == -1) continue;
this-Properties[index]-PreviousRuns = prev;
- if(this-Properties[index] this-Properties[index]-Cost == 0)
+ // When not running in parallel mode, don't clobber test's cost with
+ // running average.
+ if(this-ParallelLevel 1)
{
-this-Properties[index]-Cost = cost;
+if(this-Properties[index] this-Properties[index]-Cost == 0)
+ {
+ this-Properties[index]-Cost = cost;
+ }
}
}
// Next part of the file is the failed tests
@@ -475,20 +480,23 @@
{
SortedTests.push_back(i-first);
-//If the test failed last time, it should be run first, so max the cost
-if(std::find(this-LastTestsFailed.begin(),
- this-LastTestsFailed.end(),
- this-Properties[i-first]-Name)
- != this-LastTestsFailed.end())
+//If the test failed last time, it should be run first, so max the cost.
+//Only do this for parallel runs; in non-parallel runs, avoid clobbering
+//the test's original cost.
+if(this-ParallelLevel 1)
{
- this-Properties[i-first]-Cost = FLT_MAX;
+ if(std::find(this-LastTestsFailed.begin(),
+ this-LastTestsFailed.end(),
+ this-Properties[i-first]-Name)
+ != this-LastTestsFailed.end())
+{
+this-Properties[i-first]-Cost = FLT_MAX;
+}
}
}
- if(this-ParallelLevel 1)
-{
+
TestComparator comp(this);
std::sort(SortedTests.begin(), SortedTests.end(), comp);
-}
}
//-
##
### TEST CASE
##
cmake_minimum_required(VERSION 2.8)
project(p)
enable_testing()
# Add in reverse order to make sure COST rather than order of add_test()
# commands really controls execution order.
add_test (i_should_run_fifth ${CMAKE_COMMAND} -E echo i should run fifth)
set_tests_properties (i_should_run_fifth PROPERTIES COST -100)
add_test (i_should_run_fourth ${CMAKE_COMMAND} -E echo i should run fourth)
set_tests_properties (i_should_run_fourth PROPERTIES COST -1)
add_test (i_should_run_third ${CMAKE_COMMAND} -E echo i
Re: [CMake] test property COST not working in cmake 2.8.3?
On Thu, Dec 9, 2010 at 12:04 PM, Tyler Roscoe ty...@cryptio.net wrote:
Ok I've added a link to this thread and the patch below to the bug:
http://www.vtk.org/Bug/view.php?id=11561
Without feedback from anyone, I will assume that I have done an awesome,
production-ready job and will await the call for patches to add to CMake
2.8.4.
Thanks,
tyler
On Tue, Dec 07, 2010 at 09:37:09PM -0800, Tyler Roscoe wrote:
In the process of attempting to fix this, I learned a lot of stuff about
how COST is handled that I've never encountered in the docs. Am I
missing something?
Here are some notes I made about the behavior of COST in CTest. If
others find them useful, I'd be happy to put them in the Wiki if someone
could nominate an appropriate place.
- Any COST property you set on a test is only a starting point. CTest
calculates an average cost value for a test each time that test is
run. This value is cached in Testing/Temporary/CTestCostData.txt.
- Tests that fail are also stored in
Testing/Temporary/CTestCostData.txt. On the next run, these tests have
their cost set to the maximum to insure that they are run first. I
believe this factors into later averaging, so that tests that fail more
frequently run earlier than tests that faill less frequently.
So, my solution. I've tried to implement Zach's suggested middle
ground.
For non-parallel CTest runs:
- The run failed tests first behavior is disabled to prevent failed
tests from clobbering their given COST property.
- The stored values in CTestCostData.txt are not used.
- As long as std::sort() is stable, the COST for each test should remain
0 and the tests should run in the order encountered in CMakeLists.txt.
For parallel CTest runs, failed tests run first and the moving average
is calculated and used. I think it makes sense that if you ask for tests
to run in parallel, you probably don't care so much about the order
(modulo test dependencies) so it is more reasonable to throw out the
COST data provided by the CMakeLists.txt.
I'm not really a C++ dev so please let me know if I'm way off base.
This patch appears to solve my immediate problem but if it can be
included upstream that is better for everyone.
The patch is against the 2.8.3 release.
I've also included a simple CMakeLists.txt for testing and verifying
behavior. Unpatched ctest 2.8.3 runs the tests in reverse order. Patched
ctest runs them according to COST.
##
### PATCH
##
--- ./Source/CTest/cmCTestMultiProcessHandler.cxx.orig 2010-12-07
15:31:57.091228582 -0800
+++ ./Source/CTest/cmCTestMultiProcessHandler.cxx 2010-12-07
19:59:11.115740666 -0800
@@ -434,9 +434,14 @@
if(index == -1) continue;
this-Properties[index]-PreviousRuns = prev;
- if(this-Properties[index] this-Properties[index]-Cost == 0)
+ // When not running in parallel mode, don't clobber test's cost
with
+ // running average.
+ if(this-ParallelLevel 1)
{
-this-Properties[index]-Cost = cost;
+if(this-Properties[index] this-Properties[index]-Cost ==
0)
+ {
+ this-Properties[index]-Cost = cost;
+ }
}
}
// Next part of the file is the failed tests
@@ -475,20 +480,23 @@
{
SortedTests.push_back(i-first);
-//If the test failed last time, it should be run first, so max the
cost
-if(std::find(this-LastTestsFailed.begin(),
- this-LastTestsFailed.end(),
- this-Properties[i-first]-Name)
- != this-LastTestsFailed.end())
+//If the test failed last time, it should be run first, so max the
cost.
+//Only do this for parallel runs; in non-parallel runs, avoid
clobbering
+//the test's original cost.
+if(this-ParallelLevel 1)
{
- this-Properties[i-first]-Cost = FLT_MAX;
+ if(std::find(this-LastTestsFailed.begin(),
+ this-LastTestsFailed.end(),
+ this-Properties[i-first]-Name)
+ != this-LastTestsFailed.end())
+{
+this-Properties[i-first]-Cost = FLT_MAX;
+}
}
}
- if(this-ParallelLevel 1)
-{
+
TestComparator comp(this);
std::sort(SortedTests.begin(), SortedTests.end(), comp);
-}
}
//-
##
### TEST CASE
##
cmake_minimum_required(VERSION 2.8)
project(p)
enable_testing()
# Add in reverse order to make sure COST rather than order of add_test()
# commands really controls execution order.
add_test (i_should_run_fifth ${CMAKE_COMMAND} -E echo i should run fifth)
set_tests_properties (i_should_run_fifth PROPERTIES COST -100)
add_test
Re: [CMake] Did anyone manage to get incremental linking working with NMake generator?
On Thu, Dec 09, 2010 at 08:44:15AM -0500, Bill Hoffman wrote:
On 12/9/2010 5:26 AM, Gabriel Petrovay wrote:
Thanks Bill for the trick.
Unfortunately this works only for exe targets.
It doesn't work for dll's. Moreover, before the link command there is
this output: Visual Studio Non-Incremental Link
If it says that then the /INCREMENTAL flag is not being used. You have
to set the CMAKE_SHARED_LINKER_FLAGS_DEBUG flag for this to work with
dlls, may also want to set this one: CMAKE_MODULE_LINKER_FLAGS_DEBUG.
Haven't been following this thread closely, but changing the handling of
/INCREMENTAL is a pain, at least in VS 2005 and 2008. Here is some code
we use to *disable* /INCREMENTAL. With a little creativity, you could
probably use this to forcibly *enable* /INCREMENTAL :):
# Disable incremental linking when BUILD_code_quality is enabled as it
# causes problems with code coverage builds.
#
# These link flags are baked in when Windows-cl.cmake is loaded. Thus,
# we have to alter several variables. See: How to turn off incremental
# linking for MSVC Debug and RelWithDebInfo targets?
# http://www.cmake.org/pipermail/cmake/2010-February/035174.html
#
# Example from OpenSceneGraph:
#
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.6.0/CMakeLists.txt
#
# Also remove /EDITANDCONTINUE, which is incompatible with
# /INCREMENTAL:NO.
foreach (flag_type EXE MODULE SHARED)
string (REPLACE INCREMENTAL:YES INCREMENTAL:NO flag_tmp
${CMAKE_${flag_type}_LINKER_FLAGS_DEBUG})
string (REPLACE /EDITANDCONTINUE flag_tmp
${CMAKE_${flag_type}_LINKER_FLAGS_DEBUG})
set (CMAKE_${flag_type}_LINKER_FLAGS_DEBUG /INCREMENTAL:NO
${flag_tmp} CACHE STRING Overriding default debug ${flag_type} linker flags.
FORCE)
mark_as_advanced (CMAKE_${flag_type}_LINKER_FLAGS_DEBUG)
endforeach ()
# Change /ZI to /Zi as /ZI implies /EDITANDCONTINUE, which is mutually
# exclusive with INCREMENTAL:NO as set above. Furthermore, this setting
# only applies to 32-bit Windows.
if (TP_PLATFORM MATCHES ${TP_WIN32})
string (REPLACE /ZI /Zi CMAKE_CXX_FLAGS_DEBUG
${CMAKE_CXX_FLAGS_DEBUG})
endif ()
# Disable this warning:
# warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other
# libs; use /NODEFAULTLIB:library
list (APPEND TP_COMMON_LINK_FLAGS_DEBUG /NODEFAULTLIB:MSVCRT)
hth,
tyler
___
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] Did anyone manage to get incremental linking working with NMake generator?
Haven't been following this thread closely, but changing the handling of /INCREMENTAL is a pain, at least in VS 2005 and 2008. Here is some code we use to *disable* /INCREMENTAL. With a little creativity, you could probably use this to forcibly *enable* /INCREMENTAL :): Thanks. I look into this for disabling incremental linking since it never works well for me and is more trouble than its worth.. John ___ 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] Problem using Lahey Fortran Compiler
On 12/09/2010 08:06 AM, pellegrini wrote: I would like to build a Fortran static library using the Lahey Fortran Compiler. [snip] - why the compiler identification is unknown as Lahey compiler is normally supported by CMake ? Is it really supported ? As of CMake 2.8.3 there is no support for this compiler. Adding support requires some platform information files in CMake's Modules directory. If you want to try it, the following should get you started. (1) CMake needs to be able to identify the compiler. If the compiler defines a preprocessor macro to identify it then add an entry to CMakeFortranCompilerId.F.in. Otherwise, add an entry to the CMAKE_Fortran_COMPILER_ID_VENDORS table in CMakeDetermineFortranCompiler.cmake. In either case, choose a short c-identifier-like string to serve as the id for the compiler, such as Lahey. (2) CMake needs to know the basic compiler flags. Generic cross-platform flags should go in Modules/Compiler/id-Fortran.cmake where id is the compiler id chosen in step 1. Windows-specific information should go in Modules/Platform/Windows-id-Fortran.cmake. See the information for other compilers for example. Feel free to ask me for help. If you get this working please send me the changes for inclusion in upstream CMake. - why the test crashed as when I go to the CMakeTmp directory and run explicitely the compilation of the test program (BTW a simple hello world) the compilation works ? The build tree created in CMakeTmp is optimized for internal CMake checks and is not meant for direct build on the command line. -Brad ___ 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] Platform differences for ExternalProject_add URL
On Dec 9, 2010, at 3:18 AM, David Cole wrote: What version of cmake are you using? I'm running 2.8.2 on Mac and 2.8.0 on Linux. So I downloaded / built / installed the latest 2.8.3 source on Linux. Now I'm getting error messages indicating libcurl does not support HTTPS: -- [ 0%] Performing download step (download, verify and extract) for 'poco-1.3.6' cd /home/kc/projects/uikit/build/lib/src /usr/local/bin/cmake -P /home/kc/projects/uikit/build/lib/src/poco-1.3.6-stamp/download-poco-1.3.6.cmake -- downloading... src='https://downloads.sourceforge.net/project/poco/sources/poco-1.3.6/poco-1.3.6p2.tar.gz' dst='/home/kc/projects/uikit/build/lib/src/poco-1.3.6p2.tar.gz' timeout='none' CMake Error at poco-1.3.6-stamp/download-poco-1.3.6.cmake:19 (message): error: downloading 'https://downloads.sourceforge.net/project/poco/sources/poco-1.3.6/poco-1.3.6p2.tar.gz' failed status_code: 1 status_string: unsupported protocol log: libcurl was built with SSL disabled, https: not supported! unsupported protocol -- So I double checked that I have the latest libcurl3 installed, and that I can hit that https url using curl on the command line (where I find that sourceforge is redirecting). So I'm stumped. Please advise. KC Jones kc.jo...@skype.net SkypeId: bernalkc ___ 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] Platform differences for ExternalProject_add URL
On Thu, Dec 9, 2010 at 1:43 PM, KC Jones kc.jo...@skype.net wrote: On Dec 9, 2010, at 3:18 AM, David Cole wrote: What version of cmake are you using? I'm running 2.8.2 on Mac and 2.8.0 on Linux. So I downloaded / built / installed the latest 2.8.3 source on Linux. Now I'm getting error messages indicating libcurl does not support HTTPS: -- [ 0%] Performing download step (download, verify and extract) for 'poco-1.3.6' cd /home/kc/projects/uikit/build/lib/src /usr/local/bin/cmake -P /home/kc/projects/uikit/build/lib/src/poco-1.3.6-stamp/download-poco-1.3.6.cmake -- downloading... src='https://downloads.sourceforge.net/project/poco/sources/poco-1.3.6/poco-1.3.6p2.tar.gz' dst='/home/kc/projects/uikit/build/lib/src/poco-1.3.6p2.tar.gz' timeout='none' CMake Error at poco-1.3.6-stamp/download-poco-1.3.6.cmake:19 (message): error: downloading 'https://downloads.sourceforge.net/project/poco/sources/poco-1.3.6/poco-1.3.6p2.tar.gz' failed status_code: 1 status_string: unsupported protocol log: libcurl was built with SSL disabled, https: not supported! unsupported protocol -- So I double checked that I have the latest libcurl3 installed, and that I can hit that https url using curl on the command line (where I find that sourceforge is redirecting). So I'm stumped. Please advise. KC Jones kc.jo...@skype.net SkypeId: bernalkc CMake builds its own curl, without ssl support by default, unless you point it to the system curl. You can rebuild CMake with the CMAKE_USE_OPENSSL ON if you have all the right supporting system libraries installed. Or you can figure out an http download site to use with the non-ssl builds... HTH, David ___ 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] Did anyone manage to get incremental linking working with NMake generator?
On 12/9/2010 12:32 PM, John Drescher wrote: Haven't been following this thread closely, but changing the handling of /INCREMENTAL is a pain, at least in VS 2005 and 2008. Here is some code we use to *disable* /INCREMENTAL. With a little creativity, you could probably use this to forcibly *enable* /INCREMENTAL :): Thanks. I look into this for disabling incremental linking since it never works well for me and is more trouble than its worth.. I find it to work very well. What trouble are you having with it? I have never had a problem with it, and it does save time. -Bill ___ 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] Did anyone manage to get incremental linking working with NMake generator?
On Thu, Dec 9, 2010 at 2:47 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 12/9/2010 12:32 PM, John Drescher wrote: Haven't been following this thread closely, but changing the handling of /INCREMENTAL is a pain, at least in VS 2005 and 2008. Here is some code we use to *disable* /INCREMENTAL. With a little creativity, you could probably use this to forcibly *enable* /INCREMENTAL :): Thanks. I look into this for disabling incremental linking since it never works well for me and is more trouble than its worth.. I find it to work very well. What trouble are you having with it? I have never had a problem with it, and it does save time. Bill, Sorry, I take that back, I just checked and I no longer have it disabled in either of my large projects. I remember having problems in the past (not sure what the were) before I used CMake (before June 2008) and that I always automatically disabled it in all visual studio builds. John ___ 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 2.8.4 release scheduled for next month
(copying a CMake developers email to the users list, just as an FYI to all the CMake users out here...) The CMake developers held a bug triage meeting yesterday, and here are some notes about it: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. Assuming changes are in by that time, and they all pass the 'Nightly Expected' dashboard the next day, Brad and I will merge them into 'master' on Tues. Jan. 11. Then, we'll be ready to build the rc1 on Wed., assuming nothing alarming in the 'Nightly 2.8 Release' dashboard section. After that point, we will not accept further changes for CMake 2.8.4 except for fixes for regressions and crashes. Closed: = We closed these because they are fixed long ago, they no longer apply, or we're just never going to do them: http://public.kitware.com/Bug/view.php?id=861 http://public.kitware.com/Bug/view.php?id=1048 http://public.kitware.com/Bug/view.php?id=1053 http://public.kitware.com/Bug/view.php?id=1063 http://public.kitware.com/Bug/view.php?id=1103 http://public.kitware.com/Bug/view.php?id=9968 Deferrals: = We decided to defer the following bugs to a future release because there is not enough time left to complete them before the scheduled date: http://public.kitware.com/Bug/view.php?id=115 http://public.kitware.com/Bug/view.php?id=8396 http://public.kitware.com/Bug/view.php?id=11445 Still in progress: = The remainder of the bugs that are still targeted for potential inclusion in 2.8.4 are listed on the roadmap: http://public.kitware.com/Bug/roadmap_page.php Thanks to all who slogged through the bug list with us yesterday. Looking forward to a solid 2.8.4 release first thing in 2011! Cheers, David ___ 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] OSX_BUNDLE_PLIST Use
I have the following CMake for code for an OS X Application:
SET(MACOSX_BUNDLE_INFO_STRING ${PROJECT_NAME}${DBG_EXTENSION},
Copyright 2010 BlueQuartz Software.)
SET(MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME})
SET(MACOSX_BUNDLE_GUI_IDENTIFIER ${PROJECT_NAME}${DBG_EXTENSION})
SET(MACOSX_BUNDLE_LONG_VERSION_STRING ${PROJECT_NAME}$
{DBG_EXTENSION} Version ${VERSION_STRING})
SET(MACOSX_BUNDLE_BUNDLE_NAME ${PROJECT_NAME}${DBG_EXTENSION})
SET(MACOSX_BUNDLE_SHORT_VERSION_STRING ${CMP_VERSION})
SET(MACOSX_BUNDLE_BUNDLE_VERSION ${CMP_VERSION})
SET(MACOSX_BUNDLE_COPYRIGHT Copyright 2010, BlueQuartz Software.
All Rights Reserved.)
configure_file(${QHDFViewer_SOURCE_DIR}/QHDFViewer.plist.in
${QHDFViewer_BINARY_DIR}/QHDFViewer.plist)
set(MACOSX_BUNDLE_INFO_PLIST ${QHDFViewer_BINARY_DIR}/
QHDFViewer.plist)
message(STATUS MACOSX_BUNDLE_INFO_PLIST: $
{MACOSX_BUNDLE_INFO_PLIST})
SET(${PROJECT_NAME}_PROJECT_SRCS ${${PROJECT_NAME}_PROJECT_SRCS}
${PROJECT_RESOURCES_DIR}/Icons/icns/
${PROJECT_NAME}.icns
${QHDFViewer_SOURCE_DIR}/
hdf5file.icns)
SET_SOURCE_FILES_PROPERTIES(${ICON_FILE_PATH} PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
SET_SOURCE_FILES_PROPERTIES(${QHDFViewer_SOURCE_DIR}/hdf5file.icns
PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
But the final application does not have my custom plist installed
instead having the default plist that cmake would normally generate.
How exactly should I be setting a custom plist file?
Thanks
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
___
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.4 release scheduled for next month
So are you ready to start collecting candidate bugs for 2.8.4? I nominate this one! http://www.vtk.org/Bug/view.php?id=11561 Thanks, tyler On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. ___ 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.4 release scheduled for next month
Is the fix for the following bug included: http://www.cmake.org/Bug/view.php?id=4068 If not, when would this bug fixed, because a fix is already attached and the bug is open since 2006-11-23 Thanks in advance Best Regards NoRulez Am 09.12.2010 um 21:57 schrieb Tyler Roscoe ty...@cryptio.net: So are you ready to start collecting candidate bugs for 2.8.4? I nominate this one! http://www.vtk.org/Bug/view.php?id=11561 Thanks, tyler On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. ___ 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] OSX_BUNDLE_PLIST Use
I'll answer my own stupid question:
if (APPLE)
set_target_properties(${QHDFViewer_EXE_NAME} PROPERTIES
MACOSX_BUNDLE_INFO_PLIST ${QHDFViewer_BINARY_DIR}/
QHDFViewer.plist)
endif()
Didn't notice that MACOSX_BUNDLE_INFO_PLIST was a property and NOT a
variable. Working now. Sorry for the noise.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Dec 9, 2010, at 3:51 PM, Michael Jackson wrote:
I have the following CMake for code for an OS X Application:
SET(MACOSX_BUNDLE_INFO_STRING ${PROJECT_NAME}${DBG_EXTENSION},
Copyright 2010 BlueQuartz Software.)
SET(MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME})
SET(MACOSX_BUNDLE_GUI_IDENTIFIER ${PROJECT_NAME}${DBG_EXTENSION})
SET(MACOSX_BUNDLE_LONG_VERSION_STRING ${PROJECT_NAME}$
{DBG_EXTENSION} Version ${VERSION_STRING})
SET(MACOSX_BUNDLE_BUNDLE_NAME ${PROJECT_NAME}${DBG_EXTENSION})
SET(MACOSX_BUNDLE_SHORT_VERSION_STRING ${CMP_VERSION})
SET(MACOSX_BUNDLE_BUNDLE_VERSION ${CMP_VERSION})
SET(MACOSX_BUNDLE_COPYRIGHT Copyright 2010, BlueQuartz Software.
All Rights Reserved.)
configure_file(${QHDFViewer_SOURCE_DIR}/QHDFViewer.plist.in
${QHDFViewer_BINARY_DIR}/QHDFViewer.plist)
set(MACOSX_BUNDLE_INFO_PLIST ${QHDFViewer_BINARY_DIR}/
QHDFViewer.plist)
message(STATUS MACOSX_BUNDLE_INFO_PLIST: $
{MACOSX_BUNDLE_INFO_PLIST})
SET(${PROJECT_NAME}_PROJECT_SRCS ${${PROJECT_NAME}_PROJECT_SRCS}
${PROJECT_RESOURCES_DIR}/Icons/icns/
${PROJECT_NAME}.icns
${QHDFViewer_SOURCE_DIR}/
hdf5file.icns)
SET_SOURCE_FILES_PROPERTIES(${ICON_FILE_PATH} PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
SET_SOURCE_FILES_PROPERTIES(${QHDFViewer_SOURCE_DIR}/hdf5file.icns
PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
But the final application does not have my custom plist installed
instead having the default plist that cmake would normally generate.
How exactly should I be setting a custom plist file?
Thanks
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
___
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.4 release scheduled for next month
On Thu, Dec 9, 2010 at 3:57 PM, Tyler Roscoe ty...@cryptio.net wrote: So are you ready to start collecting candidate bugs for 2.8.4? I nominate this one! http://www.vtk.org/Bug/view.php?id=11561 Thanks, tyler No: we were ready to start collecting candidate bugs a month and a half ago. That list is now what you see on the roadmap page: http://public.kitware.com/Bug/roadmap_page.php That one might be able to get squeezed in... I'll double check with Zach Mullen to see what he thinks about it. If we select it for inclusion, it will appear on the roadmap page after we set its Target Version to 2.8.4. Thanks, David On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. ___ 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.4 release scheduled for next month
That one is assigned to Bill Hoffman and he will be looking at it sometime before Jan. 10. On Thu, Dec 9, 2010 at 4:04 PM, Roman Wüger noru...@me.com wrote: Is the fix for the following bug included: http://www.cmake.org/Bug/view.php?id=4068 If not, when would this bug fixed, because a fix is already attached and the bug is open since 2006-11-23 Thanks in advance Best Regards NoRulez Am 09.12.2010 um 21:57 schrieb Tyler Roscoe ty...@cryptio.net: So are you ready to start collecting candidate bugs for 2.8.4? I nominate this one! http://www.vtk.org/Bug/view.php?id=11561 Thanks, tyler On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. ___ 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 ___ 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.4 release scheduled for next month
On Thu, Dec 09, 2010 at 04:09:49PM -0500, David Cole wrote: No: we were ready to start collecting candidate bugs a month and a half ago. That list is now what you see on the roadmap page: http://public.kitware.com/Bug/roadmap_page.php Guess I got my wires crossed. I still believe the bug I reported is a regression, so maybe it can get through the gate regardless. Thanks, tyler ___ 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.4 release scheduled for next month
In lieu of a full fix to this bug, could the small improvement I've attached be included in the meantime? http://public.kitware.com/Bug/view.php?id=11445 http://public.kitware.com/Bug/view.php?id=11445Ryan On Thu, Dec 9, 2010 at 2:37 PM, David Cole david.c...@kitware.com wrote: (copying a CMake developers email to the users list, just as an FYI to all the CMake users out here...) The CMake developers held a bug triage meeting yesterday, and here are some notes about it: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. Assuming changes are in by that time, and they all pass the 'Nightly Expected' dashboard the next day, Brad and I will merge them into 'master' on Tues. Jan. 11. Then, we'll be ready to build the rc1 on Wed., assuming nothing alarming in the 'Nightly 2.8 Release' dashboard section. After that point, we will not accept further changes for CMake 2.8.4 except for fixes for regressions and crashes. Closed: = We closed these because they are fixed long ago, they no longer apply, or we're just never going to do them: http://public.kitware.com/Bug/view.php?id=861 http://public.kitware.com/Bug/view.php?id=1048 http://public.kitware.com/Bug/view.php?id=1053 http://public.kitware.com/Bug/view.php?id=1063 http://public.kitware.com/Bug/view.php?id=1103 http://public.kitware.com/Bug/view.php?id=9968 Deferrals: = We decided to defer the following bugs to a future release because there is not enough time left to complete them before the scheduled date: http://public.kitware.com/Bug/view.php?id=115 http://public.kitware.com/Bug/view.php?id=8396 http://public.kitware.com/Bug/view.php?id=11445 Still in progress: = The remainder of the bugs that are still targeted for potential inclusion in 2.8.4 are listed on the roadmap: http://public.kitware.com/Bug/roadmap_page.php Thanks to all who slogged through the bug list with us yesterday. Looking forward to a solid 2.8.4 release first thing in 2011! Cheers, David ___ 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 -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ 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.4 release scheduled for next month
On Thu, Dec 9, 2010 at 4:24 PM, Tyler Roscoe ty...@cryptio.net wrote: On Thu, Dec 09, 2010 at 04:09:49PM -0500, David Cole wrote: No: we were ready to start collecting candidate bugs a month and a half ago. That list is now what you see on the roadmap page: http://public.kitware.com/Bug/roadmap_page.php Guess I got my wires crossed. I still believe the bug I reported is a regression, so maybe it can get through the gate regardless. Thanks, tyler But asking now is better than asking 4 weeks from now. :-) So, if there are any other bugs folks are interested in that are not on the roadmap, please bring it up now... Thx, David ___ 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 bug tracker discussion
Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? David Cole Kitware, Inc. ___ 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 bug tracker discussion
Bug trackers make people accountable and make it easy for tasks to be delegated and tracked. BUT, someone has to take on the responsibility of assigning bugs as the come in and/or closing bugs/feature requests that aren't going to be developed on any time soon, thus keeping the number of bugs in the tracker manageable. On Thu, Dec 9, 2010 at 5:06 PM, David Cole david.c...@kitware.com wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? David Cole Kitware, Inc. ___ 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 bug tracker discussion
I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? I like the current system. Especially when you asked a few months ago for what bugs we really wanted to see addressed for the next release. John ___ 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 bug tracker discussion
On Thu, Dec 9, 2010 at 11:06 PM, David Cole david.c...@kitware.com wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. What do you say? Interestingly, a very related thread was recently started by a former KDE developer who is now a Mozilla developer: http://thread.gmane.org/gmane.comp.kde.devel.general/62171 My opinion: I like having both a mailing list and a bug tracker. However, I feel not enough attention is paid to the bug tracker. For instance, I requested a feature and provided a patch almost two years ago and I've heard nothing: http://public.kitware.com/Bug/view.php?id=8707 I guess it's an issue of not enough manpower. Given that Kitware does not make money directly from CMake, I understand you cannot invest in having people dedicated exclusively to this. Nokia is suffering a similar problem with Qt (it's just too big for them to maintain everything on every platform they support). Their (proposed) solution? Outsource some things to the community, i. e. let people not from Nokia work on stuff they want and have a loose acceptance policy. Maybe you could start by having some people from outside of Kitware (apart from Alex ;-) ) help with triaging bugs and commit patches and not-too-complex features. Also, having a public and clear roadmap and release dates is appreciated. I think 2.8.4 is the first release I actually know what is being worked on and when it is going to be released. I would like to know what the long-term vision and plans are: what platforms and languages would you would like to support, what fundamental changes you plan to make, what things you will never accept, what would you like to see but do not have/cannot justify the time/resources to do and would like the community to help you with, etc Oh, and one more request for the bugtracker, related to what I just said: a vote system, so that people can vote for features/bugfixes/etc they feel important. You may (or may not) be surprised to discover something is considered very important by a lot of people. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] R: CMake 2.8.4 release scheduled for next month
--- Gio 9/12/10, David Cole ha scritto: (copying a CMake developers email to the users list, just as an FYI to all the CMake users out here...) The CMake developers held a bug triage meeting yesterday, and here are some notes about it: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. Assuming changes are in by that time, and they all pass the 'Nightly Expected' dashboard the next day, Brad and I will merge them into 'master' on Tues. Jan. 11. Then, we'll be ready to build the rc1 on Wed., assuming nothing alarming in the 'Nightly 2.8 Release' dashboard section. After that point, we will not accept further changes for CMake 2.8.4 except for fixes for regressions and crashes. Closed: = We closed these because they are fixed long ago, they no longer apply, or we're just never going to do them: http://public.kitware.com/Bug/view.php?id=861 http://public.kitware.com/Bug/view.php?id=1048 http://public.kitware.com/Bug/view.php?id=1053 http://public.kitware.com/Bug/view.php?id=1063 http://public.kitware.com/Bug/view.php?id=1103 http://public.kitware.com/Bug/view.php?id=9968 Deferrals: = We decided to defer the following bugs to a future release because there is not enough time left to complete them before the scheduled date: http://public.kitware.com/Bug/view.php?id=115 http://public.kitware.com/Bug/view.php?id=8396 http://public.kitware.com/Bug/view.php?id=11445 Still in progress: = The remainder of the bugs that are still targeted for potential inclusion in 2.8.4 are listed on the roadmap: http://public.kitware.com/Bug/roadmap_page.php Thanks to all who slogged through the bug list with us yesterday. Looking forward to a solid 2.8.4 release first thing in 2011! Cheers, David any hope to solve http://public.kitware.com/Bug/view.php?id=10122 with the discussed change of policy for cygwin ? Regards Marco ___ 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 bug tracker discussion
On Thu, Dec 9, 2010 at 5:06 PM, David Cole david.c...@kitware.com wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I like the bug tracker. Even people that use it, however, know that hitting up the mailing list tends to improve the chance that the bug is actually researched and fixed. Also, sometimes it seems wrong to take an issue raised on the mailing list and force it into the bug tracker. It seems a little rude to the person that emailed about the issue because you might be asking them to deal with the rigmarole of creating a mantis account when they already went through the hassle of joining the mailing list and making the post. -- Philip Lowman ___ 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 bug tracker discussion
On 2010-12-09 17:06-0500 David Cole wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. I am glad you brought this subject up because there is a real problem engulfing CMake's bug tracker as we speak. It appears from the resolved category of CMake bugs on the bug tracker, that ~10 bugs were resolved (not necessarily fixed) in November, but that same month saw ~50 new bugs reported (to the cmake-devel mailing list). That ratio of 5 new bugs for every one resolved means the CMake bug tracker is rapidly being filled with unresolved issues with no hope of ever resolving them unless some substantial changes are made. Here are some ideas to help reduce that insanely unsustainable ratio of five down to a sustainable unity. 1. Reduce the number of new bug reports. a. My guess is lots of those new bug reports are noise due to misunderstanding of how to use CMake (despite what I consider to be outstanding documentation). So reduce the numbers by strongly suggesting that all potential bugs should be discussed first on the mailing list (with [BUG?] in the subject line to draw attention to it) to make sure they really are bugs before writing up a bug report. b. Avoid using the bug tracker whenever possible, e.g., quick and obvious fixes. I have experienced other organizations which demanded everything go to the bugtracker where posting to the bugtracker became the point rather than actually fixing bugs. In other words, bug trackers have been used by some organizations as an excuse for inaction on bugs! This is clearly not the case with the CMake developers (I just this morning had one of my discussed bugs fixed without going through the bug tracker), but I feel strongly about that important pitfall of bugtrackers so I brought it up explicitly here. It should be emphasized that bug trackers can play an important role for the more difficult fixes that take a lot of experimentation and thought to get right, but in my view creating a bug report on a bug tracker has an obvious cost for the reporter and for the bug triage team afterward so should be avoided for the simple stuff. 2. Increase the resources you spend on resolving bugs in the bug tracker. a. More community involvement, e.g., encourage a community bugfix team whose principal job was to do the first-level bug triage such as investigating the questions of whether it is a well-posed bug report (e.g., is there enough information in the bug report), is the issue reproducible, and ultimately is it a real bug or not. And if not, members of that team would have the power to close the bug as not a bug. b. A modest increase in Kitware resources devoted to bug fixing. This is obviously a judgement call that is up to Kitware, but if I had a say in Kitware's allocation of resources, this is how I would argue for these additional resources. Kitware doesn't get direct money for their CMake development efforts, but CMake is an enormous boost to their reputation which presumably translates to more commercial success through their paid-for products. The bottom line is ultimately it hurts Kitware's reputation if their CMake bugtracker is filled to the brim with unresolved issues so some increase in Kitware resources as well as encouraging community involvement is warranted to help deal with the current bad situation. In sum, I agree with the others who have posted on this question that you need both mailing-list discussion of all bugs and the bugtracker. My additional ideas beyond that general idea are (1) you should encourage mailing list discussion to make sure a CMake problem some user is having is really due to a bug, and (b) make a conscious effort to make quick fixes when those are warranted, and (c) encourage use of the bug tracker only for the more difficult issues where there is obviously no quick fix. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming
Re: [CMake] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 7:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-12-09 17:06-0500 David Cole wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. I am glad you brought this subject up because there is a real problem engulfing CMake's bug tracker as we speak. It appears from the resolved category of CMake bugs on the bug tracker, that ~10 bugs were resolved (not necessarily fixed) in November, but that same month saw ~50 new bugs reported (to the cmake-devel mailing list). That ratio of 5 new bugs for every one resolved means the CMake bug tracker is rapidly being filled with unresolved issues with no hope of ever resolving them unless some substantial changes are made. A couple of points to alleviate (or at least reduce your concerns) about this trend. (1) It's not as bad as you think based on November alone. In the last 365 days, 589 bugs have been opened and 341 have been resolved. Net increase in open bugs of 248 over the last year. So ratio of new-bugs:resolved-bugs is actually about 1.7:1. (2) Having spent much of my own time perusing bugs in the CMake bug tracker, I can tell you that the 0.7 over the 1 that makes up that 1.7:1 ratio are noise or duplication or just not worth anyone's time. So the ratio is more even than you think, and I don't think we need a major adjustment in this respect. I've gotta digest the rest of what you said. Maybe more reply to come later. :-) Thanks for the input, David Here are some ideas to help reduce that insanely unsustainable ratio of five down to a sustainable unity. 1. Reduce the number of new bug reports. a. My guess is lots of those new bug reports are noise due to misunderstanding of how to use CMake (despite what I consider to be outstanding documentation). So reduce the numbers by strongly suggesting that all potential bugs should be discussed first on the mailing list (with [BUG?] in the subject line to draw attention to it) to make sure they really are bugs before writing up a bug report. b. Avoid using the bug tracker whenever possible, e.g., quick and obvious fixes. I have experienced other organizations which demanded everything go to the bugtracker where posting to the bugtracker became the point rather than actually fixing bugs. In other words, bug trackers have been used by some organizations as an excuse for inaction on bugs! This is clearly not the case with the CMake developers (I just this morning had one of my discussed bugs fixed without going through the bug tracker), but I feel strongly about that important pitfall of bugtrackers so I brought it up explicitly here. It should be emphasized that bug trackers can play an important role for the more difficult fixes that take a lot of experimentation and thought to get right, but in my view creating a bug report on a bug tracker has an obvious cost for the reporter and for the bug triage team afterward so should be avoided for the simple stuff. 2. Increase the resources you spend on resolving bugs in the bug tracker. a. More community involvement, e.g., encourage a community bugfix team whose principal job was to do the first-level bug triage such as investigating the questions of whether it is a well-posed bug report (e.g., is there enough information in the bug report), is the issue reproducible, and ultimately is it a real bug or not. And if not, members of that team would have the power to close the bug as not a bug. b. A modest increase in Kitware resources devoted to bug fixing. This is obviously a judgement call that is up to Kitware, but if I had a say in Kitware's allocation of resources, this is how I would argue for these additional resources. Kitware doesn't get direct money for their CMake development efforts, but CMake is an enormous boost to their reputation which presumably translates to more commercial success through their paid-for products. The bottom line is ultimately it hurts Kitware's reputation if their CMake bugtracker is filled to the brim with
Re: [CMake] [cmake-developers] CMake bug tracker discussion
2010/12/9 David Cole david.c...@kitware.com: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I would personally vote for keeping both. I'd like to keep ML bug related activities for: 1) Having preliminary discussion like Is this a bug or not? If it is a feature request is it worth a formal request ...? 2) Public poll directed to people who seldom browse the bug tracker. Then use the tracker: 1) When we are sure (with or without discussion) that the issue is a bug or a feature request. 2) Because one NEEDS to keep track of changes, bug fixes etc... So my opinion is that BOTH are mandatory, including the usage of the ML for bug handling but may be some common usage rules may be advertised. Now I agree that may be the systematic handling of bugs filed into the tracker has to be improved but I think it already started. As external free-time contributor to CMake I was granted commit right when CMake was using CVS, it's even more easy now with git since I can autonomously commit patches to next branch (see CMake workflow http://www.cmake.org/Wiki/CMake/Git) which is regularly (once a week) merged to master by Kitware. I do get (I don't remember since when) a copy of each new bug entered in the tracker so that I can (autonomously) assign those bugs to myself if do think I can handle it. If I cannot (not enough time or not my expertise zone) but I'm interested in the bug I do add myself to the monitor list and may add some personal comments to the bug report. So to comment to Pau remark: Maybe you could start by having some people from outside of Kitware (apart from Alex ;-) ) help with triaging bugs and commit patches and not-too-complex features. I'll try to do that myself but I'm far away from Alex efficiency :-] May be helping the bug triage would be nice, may be some people may search the bug tracker for unassigned and oldish bugs and send some list of such bugs from time to time on the cmake-developer ML? I know that some Kitware people do that (searching the Bug Tracker) from time to time but I do not know if it is systematic nor periodic :-) May be opening a Wiki page with the list of CMake developers (Kitware and outsiders) with their domain of CMake expertise may help triage volunteer to contact them about the unassigned and oldish bug? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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-developers] CMake bug tracker discussion
On Thu, Dec 9, 2010 at 7:19 PM, Eric Noulard eric.noul...@gmail.com wrote: 2010/12/9 David Cole david.c...@kitware.com: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I would personally vote for keeping both. I'd like to keep ML bug related activities for: 1) Having preliminary discussion like Is this a bug or not? If it is a feature request is it worth a formal request ...? 2) Public poll directed to people who seldom browse the bug tracker. Then use the tracker: 1) When we are sure (with or without discussion) that the issue is a bug or a feature request. 2) Because one NEEDS to keep track of changes, bug fixes etc... So my opinion is that BOTH are mandatory, including the usage of the ML for bug handling but may be some common usage rules may be advertised. Now I agree that may be the systematic handling of bugs filed into the tracker has to be improved but I think it already started. As external free-time contributor to CMake I was granted commit right when CMake was using CVS, it's even more easy now with git since I can autonomously commit patches to next branch (see CMake workflow http://www.cmake.org/Wiki/CMake/Git) which is regularly (once a week) merged to master by Kitware. I do get (I don't remember since when) a copy of each new bug entered in the tracker so that I can (autonomously) assign those bugs to myself if do think I can handle it. We added that a couple months ago to raise awareness of new bugs being entered to the mailing list community. If I cannot (not enough time or not my expertise zone) but I'm interested in the bug I do add myself to the monitor list and may add some personal comments to the bug report. So to comment to Pau remark: Maybe you could start by having some people from outside of Kitware (apart from Alex ;-) ) help with triaging bugs and commit patches and not-too-complex features. I'll try to do that myself but I'm far away from Alex efficiency :-] May be helping the bug triage would be nice, may be some people may search the bug tracker for unassigned and oldish bugs and send some list of such bugs from time to time on the cmake-developer ML? This is a great idea. Is there anybody out there on these mailing lists that would like to contribute simply by organizing bugs and communicating about them with the reporters and the developers involved? It would be good to have extra eyes and hands poking around in the oldish and unassigned... I know that some Kitware people do that (searching the Bug Tracker) from time to time but I do not know if it is systematic nor periodic :-) As of our new release procedures since switching to git, we're doing this at least once every patch release of CMake, which we hope to keep going on a quarterly basis (4x a year) moving forward. May be opening a Wiki page with the list of CMake developers (Kitware and outsiders) with their domain of CMake expertise may help triage volunteer to contact them about the unassigned and oldish bug? I don't think this is necessary. We can use the mailing list for this function. And/or simply add notes in the bugs. Reporters, assignees and interested monitors all get notified by email already as notes are added to bugs. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Again, thanks for your input. This is one of the things that's really nice about working with the CMake community. You are for the most part, a bunch of thoughtful, deliberately spoken folk, whose opinion I value very highly. Thanks, David Cole ___ 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 bug tracker discussion
...Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? ... - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? Tradeoffs between push (mailing list) vs pull (bug tracker) seem like a very person-specific preference. Why enforce one or the other? Also, I know it's slightly off-topic, but it seems like the alternatives you're offering are what people use frequently today as opposed to the way things should be (and what new tools are under development in those directions). For example I've been using ditz (a distributed bug tracker that uses git or hg to manage bugs) on a small project lately and enjoying it. It's not polished or maintained enough to warrant using it on a large project, but I mention it because I think it's an indication of how bug tracking might change over the next few years... It would be nice to have local bugs that I don't push to the community but which help me track my own progress. I also happen to think that, besides becoming distributed, bug tracking systems will change in another way: they will more clearly differentiate between technical vs. narrative bug reports and handle both types. Currently, the strategies for handling bug reports from users is either (a) users can file bugs and many useless reports are filed or (b) users cannot file bugs and many problems are never brought to the attention of developers. I suspect (if it hasn't already happened) that a system for collecting **and mining** narrative reports (as told in the voice of the user, many stack traces with similar failures, etc.) will be developed that can tie to a technical issue tracker that is curated by developers (details of the problem and progress on it). My 1 to 3 cents, David ___ 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 bug tracker discussion
On 2010-12-09 19:23-0500 David Cole wrote: On Thu, Dec 9, 2010 at 7:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-12-09 17:06-0500 David Cole wrote: Hello CMake users and devs, (And now for something completely different...) Controversial questions: - Should we eliminate the bug tracker entirely and just do all discussion and patches on the mailing list? (Why have two sources of information...?) - Or, alternatively, should we eliminate the bulk of mailing list traffic, and insist on issues in the bug tracker being the main conversational forum for the whole community? I'd like to have this discussion here publicly, to try to get a good sense of varous community members attitudes and feelings. I'll start the ball rolling by saying that, personally, I like the bug tracker. I find it much easier to keep a list of issues organized and accessible than I can with email filters and folders. But I still see a need for both tools. I am glad you brought this subject up because there is a real problem engulfing CMake's bug tracker as we speak. It appears from the resolved category of CMake bugs on the bug tracker, that ~10 bugs were resolved (not necessarily fixed) in November, but that same month saw ~50 new bugs reported (to the cmake-devel mailing list). That ratio of 5 new bugs for every one resolved means the CMake bug tracker is rapidly being filled with unresolved issues with no hope of ever resolving them unless some substantial changes are made. A couple of points to alleviate (or at least reduce your concerns) about this trend. (1) It's not as bad as you think based on November alone. In the last 365 days, 589 bugs have been opened and 341 have been resolved. Net increase in open bugs of 248 over the last year. So ratio of new-bugs:resolved-bugs is actually about 1.7:1. I am glad to hear the ratio averaged over this entire year is lower than 5 although I would still argue (see below) that 1.7 is not sustainable. (2) Having spent much of my own time perusing bugs in the CMake bug tracker, I can tell you that the 0.7 over the 1 that makes up that 1.7:1 ratio are noise or duplication or just not worth anyone's time. I am not surprised by that large noise factor at all. However, I do believe those noise bug reports are worth someone's time in the sense that they should be dealt with (closed) as quickly as possible. Otherwise, those trying to stay on top of the bug tracker by scanning through the various unresolved bug reports will start getting turned off by this noise, become less efficient, etc. That's why I argue above that the ratio of new bugs to resolutions must be unity (or ideally lower to start whittling away at the backlog) or else the bugtracker is unsustainable in the long run. 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
[Cmake-commits] CMake branch, next, updated. v2.8.3-780-g2805ecc
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2805ecc9a2da403f44d3a747cf2aff0db51e57a8 (commit)
via 608d6bba89a5588c370dda6d6d46365c24168b55 (commit)
from 3696020f6f6b4d7d4fd7cd4ac2f727174102a9cb (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2805ecc9a2da403f44d3a747cf2aff0db51e57a8
commit 2805ecc9a2da403f44d3a747cf2aff0db51e57a8
Merge: 3696020 608d6bb
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 10:19:33 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Dec 9 10:19:33 2010 -0500
Merge topic 'parallel-make-install-of-CMake' into next
608d6bb Fix parallel make install of CMake itself
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=608d6bba89a5588c370dda6d6d46365c24168b55
commit 608d6bba89a5588c370dda6d6d46365c24168b55
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 10:12:12 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Dec 9 10:12:12 2010 -0500
Fix parallel make install of CMake itself
Avoid tracing dependencies of GLOBAL_TARGET targets. The build system
generators are not designed to handle any dependencies that may be
discovered. Global targets are only generated by CMake and never have
commands that reference targets built in the project anyway.
The exception is when building CMake itself there is a special case to
use the just-built cmake binary in the install target so that CMake
can replace itself on Windows. Even in this special case we do not want
to let the install target depend on the cmake target. Doing so
breaks cases like make -j4 install.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index ca61b1f..689550a 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1450,6 +1450,15 @@ cmTargetTraceDependencies
//
void cmTarget::TraceDependencies(const char* vsProjectFile)
{
+ // CMake-generated targets have no dependencies to trace. Normally tracing
+ // would find nothing anyway, but when building CMake itself the install
+ // target command ends up referencing the cmake target but we do not
+ // really want the dependency because install depend on all anyway.
+ if(this-GetType() == cmTarget::GLOBAL_TARGET)
+{
+return;
+}
+
// Use a helper object to trace the dependencies.
cmTargetTraceDependencies tracer(this, this-Internal.Get(), vsProjectFile);
tracer.Trace();
---
Summary of changes:
Source/cmTarget.cxx |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-782-g54fe3cf
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 54fe3cfdb79209b69fe45e7eb038e531212353a2 (commit)
via 7145ca67fcc252e63b10f5a301683701f1b6a69c (commit)
from 2805ecc9a2da403f44d3a747cf2aff0db51e57a8 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54fe3cfdb79209b69fe45e7eb038e531212353a2
commit 54fe3cfdb79209b69fe45e7eb038e531212353a2
Merge: 2805ecc 7145ca6
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 10:38:12 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Dec 9 10:38:12 2010 -0500
Merge topic 'doc-ctest_sleep' into next
7145ca6 CTest: Fix ctest_sleep documentation (#11554)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7145ca67fcc252e63b10f5a301683701f1b6a69c
commit 7145ca67fcc252e63b10f5a301683701f1b6a69c
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 10:36:55 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Dec 9 10:37:28 2010 -0500
CTest: Fix ctest_sleep documentation (#11554)
Document behavior consistently with the implementation.
diff --git a/Source/CTest/cmCTestSleepCommand.h
b/Source/CTest/cmCTestSleepCommand.h
index 411eb01..468cd85 100644
--- a/Source/CTest/cmCTestSleepCommand.h
+++ b/Source/CTest/cmCTestSleepCommand.h
@@ -63,11 +63,10 @@ public:
virtual const char* GetFullDocumentation()
{
return
-ctest_sleep( seconds )\n
-ctest_sleep( time1 duration time2 )\n
- With one argument it will sleep for a given number of seconds.
- With three arguments it will wait for time2 - time1 - duration
- seconds.;
+ctest_sleep(seconds)\n
+ Sleep for given number of seconds.\n
+ctest_sleep(time1 duration time2)\n
+ Sleep for t=(time1 + duration - time2) seconds if t 0.;
}
cmTypeMacro(cmCTestSleepCommand, cmCTestCommand);
---
Summary of changes:
Source/CTest/cmCTestSleepCommand.h |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-784-gdce9799
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via dce97990d97e72766e516b7572d6fabe659d176b (commit)
via d95913e232af7ada3ee6f60487ebbdee91741e01 (commit)
from 54fe3cfdb79209b69fe45e7eb038e531212353a2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dce97990d97e72766e516b7572d6fabe659d176b
commit dce97990d97e72766e516b7572d6fabe659d176b
Merge: 54fe3cf d95913e
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 11:32:21 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Dec 9 11:32:21 2010 -0500
Merge topic 'FindTCL-version-ref' into next
d95913e FindTCL: Fix TCL and TK version variable references (#11528)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d95913e232af7ada3ee6f60487ebbdee91741e01
commit d95913e232af7ada3ee6f60487ebbdee91741e01
Author: Kai Wasserbäch deb...@carbon-project.org
AuthorDate: Thu Dec 9 11:31:00 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Dec 9 11:31:00 2010 -0500
FindTCL: Fix TCL and TK version variable references (#11528)
FindTCL.cmake switched variables in the FIND_LIBRARY invocation. The
FIND_LIBRARY() statement for TCL used the TK variables and vice versa.
This patch reverses that into the right usage.
Closes debian issue 600245.
diff --git a/Modules/FindTCL.cmake b/Modules/FindTCL.cmake
index 8d780c1..8cfd9ca 100644
--- a/Modules/FindTCL.cmake
+++ b/Modules/FindTCL.cmake
@@ -104,7 +104,7 @@ ENDIF(WIN32)
FIND_LIBRARY(TCL_LIBRARY
NAMES
tcl
- tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION}
+ tcl${TCL_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION}
tcl86 tcl8.6
tcl85 tcl8.5
tcl84 tcl8.4
@@ -117,7 +117,7 @@ FIND_LIBRARY(TCL_LIBRARY
FIND_LIBRARY(TK_LIBRARY
NAMES
tk
- tk${TCL_LIBRARY_VERSION} tk${TCL_TCLSH_VERSION} tk${TK_WISH_VERSION}
+ tk${TK_LIBRARY_VERSION} tk${TCL_TCLSH_VERSION} tk${TK_WISH_VERSION}
tk86 tk8.6
tk85 tk8.5
tk84 tk8.4
---
Summary of changes:
Modules/FindTCL.cmake |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-788-g23d26f2
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 23d26f27542b696654c336adfed2b0981ae991af (commit)
via cddcad51020d42bbc321f45507a4649b1842aba4 (commit)
from e0201a7acfc4d074b3d41a21f987eaf210984b0d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d26f27542b696654c336adfed2b0981ae991af
commit 23d26f27542b696654c336adfed2b0981ae991af
Merge: e0201a7 cddcad5
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Thu Dec 9 13:40:43 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Dec 9 13:40:43 2010 -0500
Merge topic 'fix_incremental_vs2010' into next
cddcad5 Fix incremental linking for VS2010 with nmake or make.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cddcad51020d42bbc321f45507a4649b1842aba4
commit cddcad51020d42bbc321f45507a4649b1842aba4
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Thu Dec 9 13:32:48 2010 -0500
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Thu Dec 9 13:32:48 2010 -0500
Fix incremental linking for VS2010 with nmake or make.
VS2010 deprecated /INCREMENTAL:YES. This change makes
/INCREMENTAL the flag to use for incremental linking with
VS2010.
diff --git a/Modules/Platform/Windows-cl.cmake
b/Modules/Platform/Windows-cl.cmake
index 7463c62..56582ff 100644
--- a/Modules/Platform/Windows-cl.cmake
+++ b/Modules/Platform/Windows-cl.cmake
@@ -212,6 +212,8 @@ SET (CMAKE_EXE_LINKER_FLAGS_INIT
SET( MSVC_INCREMENTAL_YES_FLAG )
IF(NOT MSVC_INCREMENTAL_DEFAULT)
SET( MSVC_INCREMENTAL_YES_FLAG /INCREMENTAL:YES)
+ELSE()
+ SET( MSVC_INCREMENTAL_YES_FLAG /INCREMENTAL )
ENDIF()
IF (CMAKE_COMPILER_SUPPORTS_PDBTYPE)
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index ddfdc24..1b49837 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -3815,6 +3815,10 @@ int cmake::VisualStudioLink(std::vectorstd::string
args, int type)
{
hasIncremental = true;
}
+if(cmSystemTools::Strucmp(i-c_str(), /INCREMENTAL) == 0)
+ {
+ hasIncremental = true;
+ }
if(cmSystemTools::Strucmp(i-c_str(), /MANIFEST:NO) == 0)
{
hasManifest = false;
---
Summary of changes:
Modules/Platform/Windows-cl.cmake |2 ++
Source/cmake.cxx |4
2 files changed, 6 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
