LeechCraft - Четверг, 28 июля 2011

LeechCraft

leechcraft@conference.gentoo.ru

Четверг, 28 июля 2011< ^ >

0xd34df00d установил(а) тему: http://leechcraft.org | Баг/предложение? http://dev.leechcraft.org/projects/leechcraft/issues | Исходники: git://github.com/0xd34df00d/leechcraft.git | LeechCraft Stable: 0.3.0; unstable: 0.3.95 | Логи: http://tinyurl.com/leechcraft-logs

Конфигурация комнаты

Участники комнаты

GMT+4
[00:07:59] NightNord вышел(а) из комнаты
[01:00:22] Celt вышел(а) из комнаты: Replaced by new connection
[01:00:32] Celt вошёл(а) в комнату
[01:36:08] maksbotan вышел(а) из комнаты
[02:32:55] 0xd34df00d вышел(а) из комнаты
[02:35:04] 0xd34df00d вошёл(а) в комнату
[03:21:03] 0xd34df00d вышел(а) из комнаты
[03:22:17] 0xd34df00d вошёл(а) в комнату
[06:50:00] 0xd34df00d вышел(а) из комнаты
[06:51:15] 0xd34df00d вошёл(а) в комнату
[08:36:35] maksbotan вошёл(а) в комнату
[09:34:08] Celt вышел(а) из комнаты
[10:50:02] Celt вошёл(а) в комнату
[11:40:14] maksbotan вышел(а) из комнаты
[15:10:11] Celt вышел(а) из комнаты
[16:41:32] Celt вошёл(а) в комнату
[17:48:41] maksbotan вошёл(а) в комнату
[17:48:51] maksbotan вышел(а) из комнаты
[17:48:59] maksbotan вошёл(а) в комнату
[18:47:12] NightNord вошёл(а) в комнату
[19:40:45] Celt вышел(а) из комнаты
[20:01:53] mgorny вошёл(а) в комнату
[20:02:04] <mgorny> maksbotan: pong, I think :P
[20:02:25] <0xd34df00d> Oh, this conference then.
[20:02:27] <0xd34df00d> mgorny: hi!
[20:02:32] <maksbotan> nice
[20:03:53] <maksbotan> 0xd34df00d: you can ask your qeustions, i think :)
[20:04:08] <mgorny> I'm basically still working but the HDD is so busy I mostly wait anyway :P
[20:05:26] <0xd34df00d> maksbotan: well, I hardly have any, and, well, I thought I'd here to clarify some issues regarding ebuilds/eclasses.
[20:05:46] <maksbotan> да блин, начните уже говорить
[20:05:49] <maksbotan> смешно прям
[20:06:09] <0xd34df00d> Seems like the only thing that's going to be left in the eclass is setting egit project (so that everything is cloned into the same directory) and forcing a couple of CFLAGS.
[20:06:51] <mgorny> are you sure about keeping everything in same git repo? projects right now tend to split everything
[20:07:05] <mgorny> that's just simpler. you update one plugin, you don't need to rebuild remaining -9999 packages
[20:07:09] <0xd34df00d> Anyway, even having these two in the eclass, I think it's worth having it anyway — almost all the plugins have the same build process, so that in case something changes only eclass would be subject to updates.
[20:07:53] <NightNord> Hehe. I've been pressing him about splitting git repo into smaller ones from about year ago =)
[20:07:53] <0xd34df00d> mgorny: plugins may depend on features provided by others, and, anyway, keeping everything in one repo allows to track history, switch branches and such easily.
[20:08:06] <NightNord> Hi, mgorny
[20:08:11] <0xd34df00d> I've considered splitting repos, but seems like that'd be pure hell.
[20:08:56] <0xd34df00d> Also, I don't see any reasons for rebuilding all the -9999 packages when codebase in one of them changes — unless you are speaking of tools like smart-live-rebuild.
[20:09:07] <0xd34df00d> I dunno about them since I've never used them.
[20:09:54] <mgorny> without such tools, you rebuild everything anyway
[20:09:58] <NightNord> 0xd34df00d: don't worry, actually. We are working at work with 150 git repos
[20:10:14] <mgorny> and tracking history is harder with a single repo
[20:10:19] <0xd34df00d> Why?
[20:10:21] <mgorny> if you modify one plugin, you need to do git log plugindir/
[20:10:38] <mgorny> and git needs to track which commits actually touched that plugin and which did not
[20:11:00] <NightNord> It's okay, you'll need a bit of scriptioning for some batch tasks, but, actually, they are rather rare
[20:11:54] <0xd34df00d> And what about bisecting? You'd need to hop between commits on several branches simultaneously, and there'd be different amount of them, and such.
[20:12:10] <NightNord> Why?
[20:12:22] <NightNord> Don't you know, what feature is broken?
[20:12:49] <mgorny> if you want to package plugins separate, you need to ensure a clean relationship between the core and them
[20:13:09] <0xd34df00d> Ok, imagine you have a bug that is related to incorrect work of plugins with each other, and you wonder when it occured and what plugin caused it.
[20:13:10] <mgorny> if you change core API, your plugins need to be able to say 'hey, dude, I don't support ya'
[20:13:33] <mgorny> the cross-plugin dependencies need to handled carefully anyway
[20:13:33] <0xd34df00d> Of course, you could read the code all over again, but tools like git bisect exist to ease things like this.
[20:13:56] <0xd34df00d> mgorny: well, there are dependencies like these: plugins rely on features provided by other plugins.
[20:14:18] <0xd34df00d> That's why we have some packages in virtual/ category, and even that doesn't describe all the dependencies.
[20:14:31] <mgorny> bisecting is a fair point, I didn
[20:14:35] <mgorny> didn't consider that*
[20:15:37] <0xd34df00d> Though all of the interdependencies are fulfilled at runtime, and some are actually optional, for complete testing and such, you need to keep them in pretty same state.
[20:16:38] <0xd34df00d> In other words, though most of the things can work without each other, it makes sense to develop/test/etc plugins keeping the same API/design state of all of them.
[20:17:19] <0xd34df00d> That's the primary reason for keeping all of them in one repo, and, well, once again, I had an experience of maintaining a separate repo for another plugin, and that was much more tedious, troublesome and such.
[20:18:26] <mgorny> well, I have no better idea on bisecting code
[20:18:39] <mgorny> with separate repos, that seems like 10x more painful
[20:19:04] <0xd34df00d> And we also tend to break backward compatibility quite often, so installing a plugin from milestone, say, 0.4.80, on LC 0.4.85 is likely to cause troubles.
[20:19:22] <0xd34df00d> And the same applies to release versions, of course.
[20:19:46] <mgorny> and that's already a design problem
[20:19:53] <mgorny> if you'd like to support third-party plugins, you can't do that
[20:20:04] <NightNord> 0xd34df00d: don't your plugins check api version on load?
[20:20:30] <0xd34df00d> NightNord: not yet, I'd introduce that with the next major API change, after 0.5.
[20:20:40] <0xd34df00d> That's one of drawbacks haunting us since the beginning, surely.
[20:21:12] <0xd34df00d> And even with API version check that'd result in plugins failing to load. Better than crashing everything, but still not usable.
[20:22:16] <NightNord> 0xd34df00d: Do qt-* packages have any problems with that? I guess no
[20:23:29] <0xd34df00d> mgorny: well, I'm speaking now rather about those sets of plugins that are in active development. For example, we work now on IM heavily, and on some extensions to notifications system, but the API now, for last several milestones, has been changed and updated many times, of course. But 3d-pary plugins still managed to be up-to-date with current API most of the time.
[20:24:12] <0xd34df00d> NightNord: no, but they put really big effort in providing backward compatibility, and that makes sense if you take into the account that closed-source apps also can use Qt.
[20:25:07] <NightNord> I mean, that you are updating qt-core, but not other libs, qt apps will not work anymore
[20:25:13] <mgorny> could any of you paste how the eclass looks now?
[20:25:44] <0xd34df00d> NightNord: that depends, I'm afraid, I had experience of breaking the system while updating 4.7.9999.
[20:25:53] <0xd34df00d> maksbotan: I guess you have a more up-to-date version of the eclass then me?
[20:26:44] <NightNord> 0xd34df00d: well, actually, it could be possible to write scripts to decompose working developer's single repo in smaller ones
[20:27:19] <NightNord> I thing that was some special clone option, that allow to export only path/ related commits
[20:27:54] <NightNord> So it's possible to make one repo for developers and many separate repos for users
[20:28:26] <0xd34df00d> Users, those that build manually or do the packaging stuff for other repos, actually also like single-repo approach.
[20:29:37] <NightNord> Well, we are speaking now about simple users. Who are users, not packagers or developers, or manually-builers. And nobody forbids publishing a single repo too
[20:30:27] <NightNord> Problem with current approach is, that smart-live-rebuild will rebuild all leechcraft-related stuff if any of it is updated. And that's bad.
[20:31:41] <0xd34df00d> NightNord: and why do users, not manually-builders, do care about repo structure?
[20:31:55] Celt вошёл(а) в комнату
[20:34:39] <NightNord> 0xd34df00d: because they are using 9999 ebuilds?
[20:34:40] <maksbotan> http://paste.pocoo.org/show/448246/ latest but still incorrect version
[20:34:47] <0xd34df00d> Ah, ok.
[20:34:56] <0xd34df00d> NightNord: makes sense, possibly.
[20:36:19] <NightNord> 0xd34df00d: http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository
[20:36:48] <maksbotan> i'll be away for about an hour
[20:42:52] <0xd34df00d> mgorny: ^^^^ there maksbotan posted the eclass.
[20:43:35] <0xd34df00d> Seems like CMAKE_BUILD_TYPE could be actually removed, but, instead, -fvisibility=hidden and -fno-strict-aliasing should be forced.
[20:44:08] <mgorny> they should be forced by the buildsystem
[20:44:26] <mgorny> i.e. appended to CFLAGS set by buildtype
[20:44:51] <mgorny> but you should check for them too, if you're willing to support something more than gcc
[20:45:33] <0xd34df00d> Hm, then I don't get cmake building process on Gentoo.
[20:45:51] <0xd34df00d> mgorny: why cmake sets "Gentoo" build type, and how CFLAGS are passed from the system?
[20:49:23] <mgorny> cmake-utils sets that
[20:50:11] <mgorny> it mangles CMakeLists.txt
[20:50:34] <0xd34df00d> Hm, so inside my cmakelists.txt I can expect *_FLAGS set as external buildsystem requires?
[20:50:56] <0xd34df00d> That's great, since, personally, I just add those two flags to the list of flags in CMakeLists.txt
[20:51:29] <mgorny> Hm, or not. It just sets the C compiler.
[20:52:03] <mgorny> cmake-utils.eclass, line 319 and following.
[20:55:03] <0xd34df00d> Hm,
[20:58:15] <0xd34df00d> Ah, ok then.
[20:58:25] <0xd34df00d> Seems like plainly appending the string in sources should work.
[20:58:59] <mgorny> I'd suggest you try instead of thinking ;P.
[21:03:25] <0xd34df00d> Yeah, we'd fix that, anyway, CMAKE_BUILD_TYPE could be fixed for now.
[21:08:55] <mgorny> I'm not the one who should be editing that eclass :P
[21:09:10] <mgorny> btw if you need some -D for debug, I'd suggest you used -DNDEBUG
[21:09:14] <mgorny> (for no-debug)
[21:09:21] <mgorny> as that's what cmake-utils sets by default
[21:10:14] <0xd34df00d> Hmmm, we use quite the reverse, QT_DEBUG and such, which is defined by Qt itself.
[21:10:24] <0xd34df00d> It works now well, at least.
[21:24:54] Celt вышел(а) из комнаты
[21:46:05] mgorny вышел(а) из комнаты
[21:51:45] <maksbotan> ну и к чему пришли?
[22:03:01] <0xd34df00d> Флаги в ебилде добавлять не надо.