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?id493#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?id538 [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?id258 [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�70 [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 ;)
signature.asc
Description: This is a digitally signed message part.
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
