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

[Rolf Eike Beer]

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?id=10994
[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) an
d 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?id=12596 (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 at home anyway ;)
[21:41:23] <davidcole> sounds good
-------------- 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/20120924/fc9f4f48/attachment.sig>