Am Montag, 24. September 2012, 16:20:14 schrieb David Cole: > These online chat meetings, moving forward, are going to be at 2:00 PM > Eastern time US on Mondays. (Same as they have been this week and last > week...) > > I am not going to send reminder emails about them -- we're all adults here, > and I'll expect you all to have this on your calendars with your own > reminders set if you want something to remind you.
Ok, here is the log. Next time show up if you want to see what's going on ;) [20:00:15] <davidcole> Hello CMake devs! [20:01:15] <davidcole> My goal for this week's chat is to find out if anybody is working on something that must crucially be in our first release candidate for the upcoming CMake 2.8.10. [20:01:58] <davidcole> If it is in 'next' in the next 6 hours or so, we can use tomorrow's dashboard results to help decide what's appropriate for merging to 'master' -- [20:02:48] <davidcole> and then we can hopefully depend on Wednesday morning's 'master' dashboard being clean so that we can do rc1 on Wednesday [20:07:10] <davidcole> Quieter than last week, eh? ;-) [20:07:35] -*- Chani watches a tumbleweed roll by [20:07:40] <wacky> Are you certain that this is not the floor of the US senate? [20:09:33] <davidcole> ha ha ha -- if this is the Senate, I must be Vice President of something [20:13:36] <wacky> I don't know about Vice President, but you certainly are in charge …. of vice. [20:14:05] <davidcole> (chuckle) [20:14:40] <davidcole> Are any of the European/KDE contingent here today? (Eike, Alex, Steve, Eric?) [20:17:31] <SaroEngels> davidcole: whats up? [20:17:32] *** Modus #cmake +v davidcole durch Dakon [20:18:56] <davidcole> Do people who have logged on since I started speaking at 2:00 Eastern time here see my previous posts, or should I repeat what I said…? [20:19:29] <SaroEngels> yes, they have seen it [20:19:33] <SaroEngels> at least I did [20:19:47] -*- Dakon too [20:19:53] <Dakon> just came home 10 minutes ago [20:20:09] <Dakon> all of the stuff I had in next is already in [20:20:11] <davidcole> OK -- so does anybody have anything that they feel is a must-get-in to rc1 item? [20:20:30] <Dakon> not the "return code 77" stuff, but that could easily wait until 2.8.11 [20:20:51] <davidcole> The main concern with having everything in rc1 is that it's representative of what the final release will be like [20:21:29] <davidcole> Brad and I only like to take trivial bug fixes, fixes for serious crashes or regressions in behavior after we've done the first release candidate. [20:22:02] <Dakon> I would like to have a "docu and typo fixes are allowed at any time" in there ;) [20:22:24] <davidcole> I'll discuss that with Brad, and we'll consider that [20:23:20] <SaroEngels> I still had an issue that get_filename_component( PATH) doesn't work correctly on D:/ [20:23:29] <SaroEngels> or better on D:/bla [20:23:47] <SaroEngels> it will return D: instead of D:/ iirc [20:23:55] <davidcole> is there a bug number on that one? [20:24:03] <SaroEngels> but I can't find the bug number anymore [20:24:05] <SaroEngels> :-( [20:24:46] <rindolf> Hi all. [20:24:51] <SaroEngels> http://public.kitware.com/Bug/view.php?id994 [20:25:24] <SaroEngels> it is ugly to fix, my fixes there are not the best way to go [20:27:16] <davidcole> Is the intent of using "subst" on Windows to get the shortest possible path name to your source and build trees? [20:27:29] <SaroEngels> one of it [20:27:54] <davidcole> The simple workaround, of course, is to enforce using 1 character directory names for your source and build trees underneath the substituted drive letter [20:28:10] <davidcole> That way, you simply avoid the issue, but keep your directory names short [20:28:15] <SaroEngels> davidcole: it doesn't only happen with subst, so it is not an issue with subst itself [20:28:39] <davidcole> I understand, but it's certainly uncommon for people to have source and/or build trees at the root of a drive [20:29:02] <SaroEngels> davidcole: that only fixes one issue [20:29:13] <SaroEngels> one specific issue [20:29:33] <Dakon> I still think this should be fixed ASAP [20:29:53] <Dakon> but because we do not have a patch ready tomorrow, let alone today, I think this is not .10 material [20:29:56] <SaroEngels> the problem itself is that you can't get the correct path from get_filename_component [20:30:17] <Dakon> SaroEngels: agree? [20:30:27] <SaroEngels> Dakon: should be ok [20:31:23] <davidcole> I'd be happy to take a patch for fixing this issue (and its related issues) [20:32:39] <davidcole> If it's not terribly intrusive, we could even take it for rc2, unless it seems likely to cause a regression [20:34:10] <Dakon> that would probably mean we need a dashboard system that builds at the root of a drive [20:34:15] <Dakon> or directly under it [20:34:18] <davidcole> That [20:34:19] <Dakon> or possible even both [20:34:31] <SaroEngels> nope [20:34:33] <davidcole> That's actually a good idea, and not too hard to accomplish either [20:34:53] <davidcole> nope? [20:34:57] <SaroEngels> you just need to check that you can access something in the root of the drive [20:35:05] <SaroEngels> hm [20:35:07] <SaroEngels> although [20:35:26] <SaroEngels> I ran into one regression right away with my first fix [20:41:23] <Dakon> ok, so it seems 2.8.10 is not really a topic anymore? [20:45:19] <Dakon> commit fb578c8635b3c09f4a838c2ec9c671d9f1be34cd fixed a regression in the kdelibs build [20:45:57] <Dakon> hm, maybe even the fix is wrong [20:46:12] <Dakon> or doesn't the . needs to be escaped in []? [20:47:20] <Dakon> the point is that we should have a textcase for a target with a name containing -, ., and possible also _ if we don't have such one yet [20:47:23] <-> steveire heißt jetzt 3JTAADGN9 [20:47:32] <Dakon> so that regression could have been detected [20:48:13] <davidcole> A new test containing funky characters in target names would be useful [20:48:20] <davidcole> I'm just looking at that commit right now [20:48:32] <3JTAADGN9> Hi, [20:48:38] <-> 3JTAADGN9 heißt jetzt steveire [20:48:39] <Dakon> it's already merged to master [20:48:45] <Dakon> ah, the right one ;) [20:48:51] <steveire> No idea what that other nick was. [20:49:05] <Dakon> unregistered from nickserv? [20:49:12] <steveire> I'm not really able to attend the meeting. [20:49:17] <steveire> I can add a test for that later. [20:49:41] <davidcole> Yeah, there [20:49:57] <davidcole> Yeah, there's a bit of a problem with target names, though [20:50:10] <davidcole> We have not been real strict in the past about what's allowable in target names [20:50:39] <davidcole> And it's basically, anything that works as a "make" target name *and* a file name on the file system should work as a CMake target name [20:50:53] <davidcole> Which unfortunately makes it difficult to impose strictness now [20:51:33] <davidcole> I would think the first step might be simply making target names with "non-strict" C identifier characters in their names emit a warning at CMake configure time [20:52:11] <Dakon> that would warn on the '.' [20:52:27] <Dakon> do we need to escape that '.' in the []? [20:52:56] <davidcole> I think '.' in a character class literally means '.' [20:53:04] <davidcole> It certainly doesn't mean 'any character' [20:55:52] <davidcole> Well if we don't want to warn on things that don't cause problems now, then I guess we should figure out what the allowed set of characters is for target names, (what works now) and start being strict about it, and having it be a known/documented thing rather than this mysterious 'oh, try anything, and most things work' state we're in now... [20:56:21] <davidcole> Especially with the introduction of these generator expressions [20:56:38] <steveire> Yes, I thought the same when I was looking at the TARGET_PROPERTY stuff. [20:57:07] <davidcole> now things have to be parse-able in these new contexts, where before there wasn't as much of a need for strictness [21:02:03] <davidcole> steveire: is everything you want in 2.8.10-rc1 already in 'next' or do you have anything pending that you'd really like to see in rc1? [21:02:57] <garr> i'd personally would love to see fully working and documented macos bundle packaging [21:03:53] <davidcole> garr: what doesn't work? what's not documented enough? [21:04:36] <garr> i was recently working a lot on macos bundle packaging in my cmake scripts [21:04:53] <steveire> davidcole: I'm done, yep. [21:05:00] <davidcole> thanks, steve [21:05:01] <steveire> I'll add the test after rc1 [21:05:02] <garr> for example, two different ways [21:05:05] <davidcole> no problem [21:05:14] <garr> cpack and MACOSX_BUNDLE [21:05:25] <garr> and it's a little bit confusing [21:05:38] <davidcole> It is a little bit confusing [21:05:47] <garr> also i'd love to have macdeployqt wrapper [21:05:54] <garr> so i do like [21:06:02] <davidcole> Have you asked any questions on the CMake mailing list? [21:06:12] <garr> qt4_macdeploy (TARGET) on mac [21:06:26] <garr> and have all needed frameworks & qt.conf in .app [21:06:32] <garr> I asked here [21:06:37] <garr> yesterday [21:06:53] <garr> i finally made script that works [21:07:17] <garr> but depending on other scripts [21:07:21] <garr> not on documentation [21:07:28] <davidcole> Have you seen the recent work done on the "DeployQt4.cmake" module? [21:07:37] <garr> yeah i did [21:07:46] <garr> but i couldnt get it to work [21:08:50] <davidcole> There are two fixes to that file since the 2.8.9 release [21:09:02] <davidcole> Were you using 2.8.9, or a CMake built from source since then? [21:09:39] <garr> im using gentoo with the newest cmake available [21:09:48] <davidcole> What version is that? [21:09:55] <davidcole> 'cmake --version' will tell you [21:10:13] <garr> [garrappachc][Dokumenty] $ cmake --version [21:10:13] <garr> cmake version 2.8.9 [21:10:13] <garr> [garrappachc][Dokumenty] $ [21:10:47] <garr> i dont have mac personally, i tried deployqt4 with mingw builds [21:11:15] <davidcole> I don't know that the DeployQt4 stuff will work properly in a cross-compiling/cross-packaging case [21:11:41] <davidcole> In fact, I'd be surprised if it did work in that context without any problems at all [21:12:01] <garr> i set all qt paths and variables properly [21:12:34] <garr> but i really dont know what to do to install for example QtCore and QtGui libs [21:12:37] <davidcole> The fixup_bundle code that it depends on was not really built with cross-packaging in mind at all [21:15:30] <Guillaume> is there any chance that this patch get included (or something else that fixes the problem)? : http://public.kitware.com/Bug/view.php?id596 (after being ignored on both the bug tracker and the mailing list...) [21:15:31] <Dakon> davidcole: I was thinking about a "start contributing to CMake" session [21:15:50] <Dakon> starting with "write some testcases that improve code coverage" [21:16:16] <davidcole> garr: as far as we know, DeployQt4 works as intended on all platforms, but you have to build the package on the same platform [21:16:20] <Dakon> possible shake Phillip on that but again [21:16:56] <davidcole> However, there is always room for improvement to our documentation. If you have specific suggestions, please mention them on the CMake mailing list. People there are very helpful. [21:17:07] <Guillaume> or not... [21:17:35] <garr> davidcole: allright, maybe im limited or something, but tell me, please, what do i have to do to copy needed libraries for specified executable? [21:18:06] <garr> i really dont get the documentation of deployqt4 [21:18:07] <davidcole> guillaume: looks like 12596 might be better fixed by including "/usr/pkg" in all BSD find_* calls [21:18:50] <Dakon> that's what I would have suggested [21:19:13] <Dakon> also the "include" and "lib" things in that patch would be redundant anyway as they are included in _suffixes [21:19:29] <Guillaume> yeah, there's the include/glib stuff too [21:19:54] <Dakon> yes, that's a different story [21:20:01] <davidcole> guillaume: I have found the vast majority of people on the CMake mailing list to be very helpful [21:20:12] <davidcole> There are specific threads that do not get as much attention as they deserve [21:20:32] <davidcole> but that does not diminish the helpfulness of the people that are participating in the threads that they do contribute to [21:21:06] <davidcole> garr: please see http://mikemcquaid.com/2012/01/04/deploying-qt-applications-with-deployqt4/ [21:21:30] <garr> yeah, i've already read that [21:21:33] <davidcole> that would be the first google hit when searching for DeployQt4, and it's dead on, written up by the original author of it [21:21:53] <garr> several times [21:22:18] <Guillaume> well, maybe... what's for sure is I submitted two really easy patches to cmake, one that added 4 chars and this other one that adds three lines [21:22:25] <garr> but it works for make install, doesn't it? [21:22:46] <Guillaume> iirc, I had to wait 4 months for my 4 chars patch... [21:23:53] <davidcole> garr: https://github.com/mikemcquaid/Fabula/blob/master/CMakeLists.txt [21:24:05] <davidcole> look at the bottom 4 lines of code there [21:24:25] <davidcole> The only thing you have to do is call install_qt4_executable [21:24:33] <garr> yeah, i know that [21:24:36] <garr> i saw that [21:24:41] <garr> but there's the point [21:24:41] <davidcole> The bundle utilities functions will copy and fixup the Qt libraries as needed [21:25:02] <garr> now im confused totally [21:25:08] <garr> i mean [21:25:10] <garr> it this script [21:25:16] <garr> he includes CPack [21:25:46] <davidcole> CPack and DeployQt4 are orthogonal to each other [21:25:49] <garr> what does the dragndrop cpack generator do? [21:25:50] <davidcole> independent [21:25:58] <garr> it creates the dmg? [21:26:00] <garr> to app? [21:26:08] <Guillaume> anyways, I'll update my patch to use /usr/pkg [21:26:33] <davidcole> The dragndrop CPack generator takes your make install tree, and puts it in a folder next to a shortcut to "/Applications" so you can drag and drop it in there when the dog opens up [21:26:41] <davidcole> dmg, not dog [21:27:36] <garr> allright, but in other script i saw no install for macos bundle [21:27:50] <garr> MACOSX_BUNDLE for add_executable creates the .app [21:28:02] <garr> with executable in .app/Contents/MacOS [21:28:25] <garr> and what im doing is i move the icon, resources and everything to .app/Contents/Resources [21:28:59] <garr> and then i want to install frameworks to .app/Contents/Frameworks and create .dmg from that [21:29:04] <garr> and i doing it wrong? [21:29:07] <garr> *am [21:29:31] <davidcole> It doesn't sound like you're doing it wrong [21:29:44] <davidcole> What is incorrect about the result that you're getting? [21:30:44] <garr> i dont to make install nor make package [21:30:51] <garr> after make i have app bundle [21:30:57] <garr> *do [21:31:13] <garr> and that's it [21:31:26] <davidcole> So, if you want to have a valid bundle after 'make' [21:31:34] <davidcole> and never do a 'make install' or 'make package' [21:31:53] <davidcole> then you need to use the equivalent of install_qt4_executable... [21:32:04] <davidcole> but change install-time things to build-time things that happen when you type 'make' [21:32:12] <davidcole> That is not easy [21:32:24] <davidcole> What is easy is using install_qt4_executable at 'make install' time [21:32:33] <garr> okay [21:32:36] <davidcole> CPack automatically calls 'make install' for you to build the package [21:32:42] <davidcole> But if you want to do it at build time [21:32:47] <garr> no [21:32:48] <garr> its not that [21:32:53] <garr> i can do make package [21:32:59] <garr> its not the point [21:33:05] <garr> but now i dont know what should i do [21:33:22] <garr> do i have to add the MACOSX_BUNDLE to add_executable? [21:33:37] <garr> where do i have to install all needed resources? [21:33:57] <garr> calling manually cp or via install? [21:35:30] <steveire> Is the meeting over? Is everything on the agenda covered? [21:35:41] <davidcole> steveire: yes [21:35:44] <Dakon> Guillaume: could you try just adding /usr/pkg to that find_package call and see if it works [21:35:47] <davidcole> Thanks for your participation this week [21:36:15] <Dakon> developer attending has been as overwhelming as last time ;) [21:36:27] <davidcole> garr: I don't have a lot of bandwidth for this type of live discussion. Perhaps you could join the CMake mailing list and ask for advice there from a wider audience? [21:36:46] <steveire> We can improve attendance. [21:36:50] <Dakon> ;) [21:37:06] <davidcole> I figure if we all show up each week, it'll only get better as more people catch on that it's really happening [21:37:11] <Dakon> yeah, I suggest davidcole sends the reminder email 3 hours earlier next time ;) [21:37:21] <garr> i really dont want to waste your time here ;) i just would like to see everything well-documented [21:37:25] <steveire> We should put out the reminder several hours before, and to other places - llvm/clang, kde buildsystem mailing list and cmake users mailing list. [21:37:35] <davidcole> Yeah, 15 minutes and 0 minutes have proven not to be that helpful as far as reminder emails go [21:37:37] <garr> as is nsis od deb packaging [21:37:44] <steveire> davidcole: Yes, it just needs to be regular. It'll catch on. [21:38:13] <davidcole> We would all like to see everything very well documented. [21:38:14] <steveire> The timing is not great for me though. I can't do every week. [21:38:18] <Dakon> garr: I suggest you join the mailing list, find out what's going on and then submit a patch to describe what you would have liked to read *g* [21:38:22] <Dakon> and I'll happily merge it [21:38:31] <davidcole> Unfortunately, it falls off the list frequently, as things working take priority over well-documenting... [21:38:47] <garr> i see ;) [21:39:21] <Dakon> davidcole: saw my message about the contribution session? [21:39:41] <davidcole> Dakon: yes, sorry, fell out the other side of my brain [21:40:11] <davidcole> did you mean on the wiki? [21:40:15] <Guillaume> ho... but... FindGTK2 doesn't have include and lib in its SUFFIXES :| [21:40:35] <Guillaume> btw, there would be less paths if they were in it... [21:40:56] <Dakon> davidcole: the session? no, I would do it here with live guiding people and merging the patches when they are ready [21:41:05] <Guillaume> (for instance /opt/gnome/include /opt/gnome/lib /sw/include /sw/lib etc.) [21:41:13] <Dakon> likely this saturday as I'm alone@home anyway ;) [21:41:23] <davidcole> sounds good
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