[cmake-developers] Proposal: An IRC dev meeting to chat about CMake stuff

[Rolf Eike Beer]

David Cole wrote:
> Please join us in about 15 minutes for a CMake Developers chat via the IRC
> #cmake room...

Here is the log of the meeting.

[19:47:56] <Dakon> ah, the VIPs are finally arriving ;)
[19:48:36] *** Modus #cmake +o Dakon durch ChanServ
[19:48:47] *** Modus #cmake +v davidcole durch Dakon
[19:58:01] <davidcole> VIP? Where? (looks around… sees nobody else)
[19:58:13] <Dakon> ;)
[19:58:26] <Dakon> aLeSD|: there?
[19:59:38] <davidcole> Can we tell how many are here? I'm not an IRC expert 
yet by any stretch
[20:00:30] <wacky> I'm here for the developer discussion.
[20:00:42] <steveire> davidcole: 84 people
[20:00:49] <steveire> But it's always about that many
[20:00:52] <davidcole> Excellent, you are in the right place
[20:01:28] <davidcole> This is going to be sort of free form…
[20:01:37] <davidcole> I don't have any specific agenda
[20:02:35] <davidcole> But I would like to talk about CMake 2.8.10, when we 
should anticipate having release candidate 1, talk a little about bugs, and 
then see if anybody else has any questions or discussion items
[20:04:38] <Dakon> then let's talk ;)
[20:05:50] <davidcole> OK - first of all, one of the ideas with scheduling this 
on Monday was to talk about anything you all would like to bring to my 
attention (and Brad's) before our Tuesday merge sessions.
[20:06:20] <davidcole> Before we talk about 2.8.10-rc1, does anybody have any 
specific items that they want to chat about w.r.t. tomorrow's merging?
[20:06:26] <steveire> I have an item: Is the qt5-qtdialog-port branch blocked 
on something? Waiting for Qt 5 relase or something like thaT?
[20:06:35] <davidcole> The dashboard looks good today.
[20:06:51] <davidcole> qt5 question: hang on, let me take a glance at it...
[20:07:40] <steveire> Oops, I just realized I didn't merge it to next...
[20:07:44] <Dakon> I think I finally fixed the last issue in the document-MSVC-
variables-12567 branch, should be green tomorrow
[20:07:48] <davidcole> The "qt5-qtdialog-port" is not merged to 'next' 
according to 'stage print'
[20:08:11] <davidcole> One of these times I'll look up to see what others have 
typed before I hit "return" :-P
[20:08:21] <Dakon> hrhr
[20:08:40] <Dakon> I have a fix in bug 13262 but got no response from the 
original reporter so far
[20:08:41] <davidcole> great on the "fixing last issue" - thanks, Eike
[20:09:16] <Dakon> I think I'll just push and merge that to next now and let 
everyone complain afterwards about the things I broke again ;)
[20:09:16] <davidcole> well….
[20:09:29] <steveire> Merged the qt5 branch to next now.
[20:09:40] <davidcole> w.r.t. 13262, if you don't hear back, but you think 
it's probably the right fix, it's ok with me if you want to merge it to 'next'
[20:10:08] <davidcole> the patch for it looks simple enough
[20:10:42] <Dakon> I think I once again will run into problems there is the 
list is empty, no?
[20:10:58] <Dakon> will check and then merge
[20:11:39] <Dakon> ah, no, the list can't be empty there
[20:12:11] <Dakon> but I'll change that "set" to "list(APPEND" for sanity
[20:12:31] <davidcole> sounds reasonable
[20:12:42] <davidcole> there are other "not yet in next
[20:12:48] <davidcole> " branches on the stage
[20:13:17] <davidcole> any claimers? for "export-sets-2" 
"generate_export_header-fixes" and "AutomocUseTargetProperties"
[20:13:36] <davidcole> will they be in 'next' soon? Or is the stage being used 
as a communications channel for these topics?
[20:14:01] <Dakon> the second one sounds like steveire ;)
[20:14:03] <steveire> generate_export_header-fixes is mine. I'll try to come 
back to it soon
[20:14:24] <steveire> The last time I merged it, the dashboard blushed.
[20:14:37] <davidcole> It was embarrassed for you?
[20:14:38] <davidcole> '-)
[20:14:40] <davidcole> ;-)
[20:14:59] <davidcole> Looks like export-sets-2 is Alex's
[20:15:00] <steveire> :)
[20:15:18] <steveire> Yes, that's under discussion on the ml atm.
[20:15:22] <Dakon> someone could have noticed that I messed up the argument 
order to list(FIND) in that patch
[20:15:30] <steveire> http://public.kitware.com/Bug/view.php?id=13493#c30781 
relates to the third one.
[20:15:31] <davidcole> And so is the other one (also Alex's)
[20:15:58] <davidcole> Dang, do I have to look up the --help-command for list 
everytime....?
[20:16:45] <Dakon> hehe ;)
[20:17:01] <Dakon> why should it be simpler for you than for me, hm? ;)
[20:17:08] <davidcole> All right, so it sounds like things are fairly well in 
hand for topics already in 'next' and topics coming soon on the stage
[20:17:53] <Dakon> I would like if Brad could go and cherry-pick that kwsys 
stuff from VTK he talked about
[20:17:58] <davidcole> Assuming the dashboards look good tomorrow, Brad and I 
will review them all and hopefully push most or all of them to master
[20:18:26] <davidcole> I will mention the kwsys/VTK item to him
[20:20:33] <Dakon> can someone try to load one of the Windows machines with a 
bunch of open source projects?
[20:21:04] <Dakon> I fear that most Find modules are not tested on windows at 
all and will explode once someone will test them
[20:22:00] <davidcole> What do you mean by "load with a bunch"?
[20:22:30] <davidcole> It's really a delicate balancing act trying not to mess 
up a dashboard machine that's already successfully submitting for multiple 
projects.
[20:22:53] <davidcole> I tend to avoid installing stuff unless it's absolutely 
necessary on the stable dashboard machines.
[20:23:04] <davidcole> I can see your point, though
[20:23:20] <davidcole> Just not sure how to achieve the goal without becoming 
responsible for "other people'
[20:23:24] <davidcole> s dashboard scripts"
[20:23:29] <Dakon> how are these machines organized at Kitware? physical 
hardware? vms?
[20:23:41] <davidcole> mostly physical hardware
[20:23:49] <davidcole> some of the newer ones are vm-based
[20:24:15] <Dakon> maybe you could clone one of them?
[20:25:42] <Dakon> and then just look on the output of AllFindModules test and 
install everything that is not found ;)
[20:26:04] <davidcole> Good idea, but I don't have the bandwidth to get to 
that anytime soon.
[20:27:04] <steveire> So, next item is RC1?
[20:27:07] <Dakon> well, if it takes another week or 3 it doesn't matter that 
much I think
[20:27:09] <davidcole> In fact, my personal bandwidth on CMake is fairly 
limited lately to reviewing and organizing the patches and submissions of you 
all: you guys are the real CMake VIPs
[20:27:17] <davidcole> yes -- rc1
[20:27:36] <Dakon> I wont mind if you delegate it to someone else ;)
[20:28:10] <davidcole> OK…. so whenever we plan a date for a CMake release, we 
tend to just pick a Wednesday out there in the future that's about 3 months 
from the previous release and pin it on the calendar
[20:28:13] <Dakon> reminds me of something: is there a description of what 
stuff is accepted in what stage of development?
[20:28:30] <davidcole> This time around, I picked 10/31, Halloween, after 
releasing 2.8.9 on Aug. 9th
[20:28:50] <Dakon> yeah, let's create a nightmare release ;)
[20:28:51] <davidcole> So -- to hit that, we should really have rc1 a week 
from Wednesday, on Sept. 26th
[20:29:14] <davidcole> I'm willing to go further out than that, but that means 
we would be in November probably for the real release of 2.8.10
[20:29:23] <steveire> Hmm.
[20:29:39] <steveire> A bit close. What does rc1 mean? No new features?
[20:29:46] <davidcole> The other possibilities are Wed. Oct. 3 and Wed. Oct 
17th
[20:30:16] <davidcole> The week of the 10th is out for me, as I will be out of 
town with limited computing access
[20:30:38] <davidcole> rc1 means no significant new changes, except for 
regression bug fixes
[20:30:45] <davidcole> Think of it this way:
[20:31:07] <davidcole> if rc1 works for somebody who's not encountering a 
regression in behavior, then the final release should also work for them
[20:31:27] <Dakon> so things like the processor id stuff will likely not make 
it into 2.8.10
[20:31:30] <steveire> Right.
[20:31:30] <Dakon> which is ok for me
[20:31:31] <davidcole> So, Brad and I are very careful, in general, about what 
we take into 'master' during a release candidate phase
[20:31:54] <steveire> I'll try to get the config specific include dirs in before 
next wed then.
[20:32:39] <steveire> I'll have another refactoring branch to merge to next 
tomorrow or the next day, then I might be able to get it in.
[20:32:49] <davidcole> Sounds good
[20:33:02] <davidcole> The reason to favor doing it early from our 
perspective...
[20:33:10] <steveire> It's not critical for 2.8.10 anyway, so ok from me.
[20:33:37] <Dakon> davidcole: I have a change that moves the implementation of 
cmMessageCommand::GetFullDocumentation() from header to source
[20:33:38] <davidcole> …is that there was fix on the Mac that really really 
helps out people using multiple installations of Xcode, or pre-release dev 
snapshots from Apple
[20:33:56] <Dakon> it was created while trying to implement something else 
which didn't work out
[20:34:07] <Dakon> I wonder if I should merge this or just drop it
[20:34:35] <davidcole> Are other commands in the cxx files now? I thought most 
are still in header files...
[20:34:57] <Dakon> heavily depends on the file afaict
[20:36:22] <davidcole> git grep GetFullDocumentation | grep -E "\.h:" | wc
[20:36:30] <davidcole> says that 107 of 119 are in header files
[20:36:38] <davidcole> so just leave that one in the header file too
[20:36:49] <Dakon> ok
[20:37:01] <steveire> So, on to bugs.
[20:37:22] <steveire> (Then I have one discussion item)
[20:37:27] <davidcole> Steve is our moderator, keeping us on schedule
[20:37:30] <davidcole> :-)
[20:37:46] <steveire> :)
[20:37:50] <davidcole> Since it seems to be just mostly 3 of us, there's not 
much to talk about bugs I guess
[20:37:59] <davidcole> We have about 30-something on the roadmap
[20:38:05] <davidcole> and I doubt we'll get to them all
[20:38:18] <davidcole> we have fixed 24 according to the change log page since 
Aug. 9th
[20:38:59] <davidcole> I was hoping more would be listening in here, and 
available to volunteer some man-power in terms of telling us which bugs have 
good patches, adding patches, testing.....
[20:39:56] <Dakon> another one ;)
[20:39:56] <steveire> The first meeting being under-attended isn't surprising 
anyway. :) A reminder on the mailing lists next time might help with that.
[20:40:00] <davidcole> Any ideas for getting some more folks involved in CMake 
development? (And thereby helping us fix bugs at a faster rate…. or at least 
being more effective at our communications in the bugs)
[20:40:03] <Dakon> ok, I'll be away for half an hour
[20:40:08] <Dakon> need to pick up my wife
[20:40:09] <AmineKhaldi> hey, I'm here too ! :)
[20:40:17] <Dakon> stay around so we can continue later ;)
[20:40:31] <AmineKhaldi> (I just didn't know what to contribute to the 
discussion)
[20:40:43] <davidcole> Hi Amine!
[20:40:49] <AmineKhaldi> hey ;)
[20:41:09] <davidcole> So…. unfortunately, although I put some of your bugs of 
interest on the roadmap,
[20:41:20] <davidcole> we have not seen any adopters coming forward to help 
out
[20:41:25] <steveire> davidcole: Perhaps add a link to the contribute page 
when putting bugs in the backlog.
[20:41:45] <AmineKhaldi> yeah, it's too bad
[20:41:51] <davidcole> That is a very good idea
[20:42:11] <steveire> There are plenty of people using the bug tracker who are 
competent enough to contribute more if they knew it would get their patches in 
I'm sure.
[20:43:06] <davidcole> Is the contribute page complete, and have good 
instructions on it? (Which page do you mean, anyhow? a wiki page, something on 
cmake.org, or something else?)
[20:43:18] <davidcole> Yes, there are
[20:43:33] <davidcole> One of the major problems we have with patches attached 
to the bug tracker is...
[20:44:09] <steveire> davidcole: http://www.paraview.org/Wiki/CMake/Git or 
something similar to it.
[20:44:12] <davidcole> …they're sufficient to fix the problem at hand for 
*somebody* , but that person may or may not take into account the fact that 
CMake has to work on tens of platforms and even more compilers
[20:44:46] <steveire> http://www.cmake.org/cmake/project/getinvolved.html 
could maybe be linked to that wiki page.
[20:45:55] <steveire> Yes, that's something that the person merging has to 
take care of.
[20:46:09] <steveire> Which, incidentally, brings me to the point I wanted to 
discuss :)
[20:46:28] <davidcole> Good idea on both fronts, Steve. I will take your 
advice and add links like that next time I 'backlog' anything
[20:46:40] <davidcole> And I can get a link to the wiki added to that 
getinvolved page
[20:46:54] <steveire> I get hit by compiler warnings after I merge things to 
next for errors that I should have caught locally.
[20:47:16] <davidcole> Yes, quite common and unfortunate
[20:47:28] <steveire> I expected cmake to have the warnings enabled for 
building cmake so that I wouldn't get initialization order wrong, name unused 
parameters etc.
[20:47:57] <davidcole> Why did you expect that? ;-)
[20:48:00] <steveire> It should be quite simple to add the warnings for some 
base version of gcc/clang so that most people would get them.
[20:48:08] <davidcole> That's a good idea, too
[20:49:12] <steveire> I can see if it works with
[20:49:12] <steveire>   set (CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -Wno-long-long 
-std=iso9899:1990 -Wundef -Wcast-align -Werror-implicit-function-declaration -
Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -
Wmissing-format-attribute -fno-common")
[20:49:12] <steveire>   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wnon-
virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall 
-W -Wpointer-arith -Wformat-security -fno-check-new -fno-common ")
[20:49:12] <steveire> then at some point, which is the magic warnings I use 
everywhere.
[20:49:22] <syntheticpp> hi, (syntheticpp == Peter Kuemmel)
[20:49:37] <davidcole> Hello Peter
[20:49:39] <steveire> Hi Peter.
[20:49:44] <AmineKhaldi> Peter ;)
[20:50:20] <syntheticpp> Haven't compiled reactos for a while, sorry ;)
[20:51:11] <syntheticpp> I've a question to ExternalProject: there is this bug 
entry http://www.cmake.org/Bug/view.php?id=13538
[20:51:11] <steveire> I'm going to have to go soon.
[20:51:24] <steveire> Should we post the chat log to the mailing list?
[20:51:27] <davidcole> Steve, now that the compiler variables are well known, 
work everywhere, and fully documented, it should be easy enough to add the 
flags for warnings in conditional blocks based on the compiler
[20:52:17] <steveire> "now that the compiler variables are well known, work 
everywhere, and fully documented, " << What do you mean? Did something change 
to make that true?
[20:52:18] <davidcole> So, wrap those set calls in conditional logic based on 
the compiler, and push a branch to the stage for that. If it's a branch on the 
stage, I will definitely talk to Brad about it.
[20:52:31] <syntheticpp> but I'm not sure if it's not a missing feature in 
ExternalProject, David aren't you the EP expert?
[20:52:35] <davidcole> yes, Brad's recent commits (last few weeks)
[20:52:46] <steveire> davidcole: Ah, you mean version checks.
[20:52:50] <steveire> for the compiler version
[20:52:53] <davidcole> yes
[20:53:12] <davidcole> Peter, I am as close as one can get to an EP expert
[20:53:27] <steveire> davidcole: But I'm talking about building cmake itself, 
and that requires cmake 2.8.2, right?
[20:53:32] <davidcole> The bug sounds related to files with the SYMBOLIC 
property
[20:53:51] <steveire> So I can't make use of the compiler version variables.
[20:53:53] <davidcole> steve, you're right
[20:53:56] <davidcole> sorry
[20:54:09] <davidcole> bad suggestion (but it will be good in about 2 
years...)
[20:54:17] <steveire> But I can check for some reasonably recent gcc that 
people are likely to be using for primary development anyway.
[20:54:30] <steveire> :) Yes, we can do it that way in 2 years.
[20:54:48] <davidcole> the SYMBOLIC files should end up being .phony targets in 
the makefiles (from what I understand)
[20:55:16] <davidcole> I would think that if ninja has 'phony' as a keyword, 
it should work the same
[20:56:08] <davidcole> I just read your note in the bug, though, and I think 
your analysis is correct
[20:56:20] <davidcole> So never mind what I'm saying about SYMBOLIC and phone
[20:56:22] <davidcole> phony
[20:56:51] <syntheticpp> Yes, it has, but how could it know the target name 
and lib name are related?
[20:56:59] <steveire> I'm going to have to roll. Thanks for the meeting. Maybe 
Dakon can post the chat log if you think that's useful. He'll have all of it 
:).
[20:57:05] <davidcole> it can't -- your analysis is correct
[20:57:13] <davidcole> thanks, Steve
[20:57:18] <davidcole> chat with ya again next week
[20:57:23] <syntheticpp> bye Steve
[20:57:28] <AmineKhaldi> bye steveire
[20:57:29] <steveire> bye
[20:57:58] <davidcole> OK, so before we call it a 'wrap
[20:58:03] <davidcole> ' -- a recap:
[20:58:39] <davidcole> We are hoping to schedule rc1 for next Wed. Sept. 26, 
and we will execute on that unless something pops up to prevent it between now 
and then
[20:59:33] <davidcole> We still need more contributors, and folks to help us 
manage the large amount of stuff we are tracking in our bug database
[21:00:22] <davidcole> And this seems like it was useful, so we'll continue to 
schedule chat sessions on Mondays at 2:00 pm Eastern time US
[21:00:46] <davidcole> Any other questions for me before I sign off today?
[21:01:20] <syntheticpp> Could I assign mentioned bug to you?
[21:02:00] <davidcole> Sure
[21:02:07] <AmineKhaldi> davidcole: one question if I may
[21:02:24] <davidcole> He claims it does work with the Makefile generator, but 
I don't know how it could. Maybe he's just getting lucky with build ordering.
[21:02:31] <davidcole> Go ahead Amine
[21:03:06] <AmineKhaldi> does any of you guys use VS with a solution that has 
more than 20 projects for example ? and if so, when you alter a cmake file 
doesn't VS go crazy about "do you want to reload the project" prompt for every 
single project in the solution ?
[21:03:13] <davidcole> In fact, that's probably why it appears to work with 
make. It probably wouldn't work with a clean+heavily-parallel make…
[21:03:27] <AmineKhaldi> I'm just curious to know, since this happens for us 
and we have like 800 modules, so you can see how impractical that is
[21:03:28] <syntheticpp> Yes, I've tested it with nmake and a target, and it 
fails like ninja
[21:03:31] <davidcole> yes, VS is constantly going crazy
[21:04:09] <davidcole> I personally cannot stand the way more than about 10 
projects seem to overload poor little Visual Studio
[21:04:26] <AmineKhaldi> in light of the recent cleanup around msvc, could 
something be considered for this very frequent situation ?
[21:04:31] <davidcole> I always close the solution I'm working on, then run 
cmake to re-configure, then re-open the solution when I have to use VS
[21:04:48] <syntheticpp> Amine: I've seen a solution for that in clang, 
looking for the link ...
[21:05:10] <AmineKhaldi> ah, this reminds me of another question, since you 
mentioned clang
[21:05:16] <AmineKhaldi> clang in windows behaves in two ways
[21:05:20] <AmineKhaldi> gcc mode and msvc mode
[21:05:36] <AmineKhaldi> they have the same driver, but one is compatible with 
ld, and the other is compatible with link
[21:05:44] <AmineKhaldi> (and codegen differs of course)
[21:05:51] <syntheticpp> CMakeLists in clang at the end: # Workaround for 
MSVS10 to avoid the Dialog Hell
[21:06:00] <syntheticpp> http://llvm.org/svn/llvm-
project/cfe/trunk/CMakeLists.txt
[21:06:16] <davidcole> We have this very old, very well known bug that we have 
not been able to fix:
[21:06:17] <davidcole> http://public.kitware.com/Bug/view.php?id=11258
[21:06:25] <AmineKhaldi> the question is: did you consider something to 
support this ? since we can't just if(MSVC) in the case of the msvc compatible 
clang
[21:06:27] <davidcole> There is a VS add-on that you can try
[21:07:09] <davidcole> Try the add-on from vscommands.com as a way of 
reloading them all in a single swoop
[21:07:13] <AmineKhaldi> syntheticpp: hmm, interesting
[21:07:17] <davidcole> I haven't tried it myself
[21:08:19] <AmineKhaldi> davidcole: another thing, re. the asm defines support, 
someone added a patch
[21:08:35] <AmineKhaldi> it was for supporting custom commands for asm files
[21:08:56] <AmineKhaldi> it was missing the defines, so I asked the guy to 
consider expanding <DEFINES> but I got no reply
[21:09:08] <AmineKhaldi> is there a chance to pick up his patch and add just 
that to it ?
[21:09:12] <davidcole> We do not expand anything for Visual Studio projects
[21:09:51] <AmineKhaldi> hmm, so his patch is incorrect ?
[21:09:55] <Dakon> back
[21:09:58] <AmineKhaldi> as in using an incorrect angle ?
[21:10:14] <davidcole> It may look like we do from a "net result" perspective, 
but we don't expand those rule vars for VS, we let VS do it's own thing based 
on the generated projects
[21:10:42] <davidcole> which patch are we talking about here? (or bug number)?
[21:12:43] <rindolf> Hi all.
[21:12:48] <rindolf> Is the meeting still on?
[21:13:51] <syntheticpp> Hi, meeting is near the end
[21:13:56] <rindolf> syntheticpp: ah, OK.
[21:14:33] <syntheticpp> but maybe a log is posted
[21:15:36] <davidcole> I am still here…. did you have a question, or did you 
just want to observe?
[21:18:29] <Dakon> I wanted to ask one or 2 things, but I'll need a moment to 
remember what it was
[21:20:34] <Dakon> davidcole: any news about the QNX builds?
[21:21:55] <Dakon> and what's the problem with amber1[02]?
[21:22:54] <AmineKhaldi> sorry, that was the phone
[21:22:59] -*- AmineKhaldi reads up
[21:24:06] <AmineKhaldi> davidcole: this one: 
http://www.cmake.org/Bug/view.php?id=8170
[21:30:40] <davidcole> He's calling ExpandRuleVariables from a context in 
which it was never designed to be called (a Visual Studio generator)
[21:30:58] <AmineKhaldi> ouch
[21:31:01] <davidcole> It may work, it may not, I've not delved into the rule 
variables enough to know
[21:31:23] <AmineKhaldi> well, could having it working for one more var 
(DEFINES) be considered a short term solution ?
[21:31:53] <Dakon> davidcole: I also have some good news
[21:32:03] <AmineKhaldi> if this one somehow gets expanded correctly for each 
source file, that would be great
[21:32:38] <davidcole> No news that I know of regarding QNX builds. I'll have 
to re-ping
[21:32:42] <davidcole> What's your good news?
[21:32:43] <Dakon> aLeSD| is working on perforce integration for CMake
[21:35:29] <davidcole> the problem with amber10 is that Visual Studio 10 has 
always been flaky on that machine, but we leave it running our Continuous 
anyway
[21:35:41] <davidcole> because it's better than not having one and we don't 
have another machine we can put it on right now
[21:36:02] <davidcole> so, the errors it reports are frequently "MSBuild 
crashed" while building something
[21:36:07] <davidcole> sorry about that.
[21:38:55] <davidcole> And… amber12, the mingw/msys builds are run in their 
own separate command prompt, but in parallel with other dashboards running in 
other command prompts
[21:39:15] <davidcole> Seems one of them is ALWAYS timing out, but always on a 
different test each night.
[21:39:55] <davidcole> If we could figure the rhyme or reason behind that one, 
we'd change it, but at this point, it's better to live with it until we get a 
new dashboard for mingw/msys set up on a different machine than it is to give 
up on it entirely
[21:40:20] <davidcole> Brad and I discount these types of dashboard errors 
when we are considering the state of the system and deciding what gets merged 
to 'master'
[21:40:36] <davidcole> I have got to get going for today, but this has been 
fun
[21:40:57] <wacky> CU
[21:41:04] <davidcole> Dakon: could you please save a transcript of this, and 
post it to the CMake dev mailing list?
[21:41:07] <davidcole> thanks all!
[21:41:11] <Dakon> sure
[21:41:11] <davidcole> bye
[21:41:16] <Dakon> cu next week
[21:42:27] <Dakon> time for some new VMs I would say ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20120917/5494cedb/attachment.sig>