#gemrb@irc.freenode.net logs for 31 Mar 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:14:41] <tomprince> cmake or autotools? Right now, the cmake build install seems broken.
[01:53:54] <-- Maighstir_laptop has left #GemRb
[02:56:56] <tomprince> ... and me a broken record.
[05:07:30] --> raevol has joined #GemRb
[05:39:43] --> Nomad010 has joined #GemRb
[05:59:56] <-- raevol has left IRC (Quit: Leaving.)
[06:56:47] --> lynxlynxlynx has joined #GemRb
[06:56:47] --- ChanServ gives channel operator status to lynxlynxlynx
[07:04:05] <-- |Cable| has left IRC (Remote host closed the connection)
[07:09:08] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:09:18] --> Gekz has joined #GemRb
[07:09:37] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:11:12] --> Gekz_ has joined #GemRb
[08:01:30] <-- lynxlynxlynx has left IRC (Read error: Operation timed out)
[08:02:08] --> lynxlynxlynx has joined #GemRb
[08:02:08] --- ChanServ gives channel operator status to lynxlynxlynx
[08:41:34] <fuzzie> tomprince: i think whoever fixes+verifies cmake or autotools everywhere gets to decide
[08:50:23] <fuzzie> cmake appears to be installing bits into crazy locations, but i don't know where they're meant to be.
[08:59:34] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[08:59:44] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:59:59] --> Gekz has joined #GemRb
[09:00:59] --> Gekz_ has joined #GemRb
[09:13:27] <fuzzie> lynxlynxlynx: are there ever transparent window borders?
[09:17:02] <-- Gekz has left IRC (Read error: Connection reset by peer)
[09:17:04] --> Brendan__ has joined #GemRb
[09:17:29] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[09:17:59] --> Gekz_ has joined #GemRb
[09:20:52] <fuzzie> hmm, never mind
[09:24:58] <fuzzie> perhaps someone could explain renewal theory to me instead. in the absence of that, bbiab.
[09:41:17] <edheldil> fuzzie: I vaguely seem to remember that there are windows. which are bigger than their background or st. like that in PST. But it's long and I am not sure
[10:33:12] --- Brendan__ is now known as Gekz
[10:33:20] <-- Gekz has left IRC (Changing host)
[10:33:20] --> Gekz has joined #GemRb
[10:35:26] --> raevol has joined #GemRb
[11:12:16] <fuzzie> edheldil: ok, thanks, i'll look some more
[11:19:22] --> Maighstir_laptop has joined #GemRb
[12:09:05] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[12:10:51] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[12:24:19] <lynxlynxlynx> i didn't know there were special window borders
[12:47:32] <fuzzie> there is SetBorder()
[12:56:59] <lynxlynxlynx> for buttons i know, but that's it
[13:00:11] <tomprince_loki> morning.
[13:01:28] --> Nomad010 has joined #GemRb
[13:01:36] <fuzzie> oh, SetFrame().
[13:01:43] <fuzzie> sorry, didn't have the code from where I was.
[13:05:06] <Genraznx> Morning
[13:12:27] <edheldil> hi, tomprince
[13:15:13] <fuzzie> tomprince: what did you mean about the cmake build install?
[13:16:14] <tomprince_loki> Well, PLUGINDIR is not defined, so that it can't find the plugins.
[13:16:31] <fuzzie> oh
[13:17:04] <tomprince_loki> Also, it doesn't seem to obey the FHS.
[13:17:18] <fuzzie> the official supported way is that all paths must be specified in GemRB.cfg, i thin
[13:17:36] <fuzzie> but yes, i do note that it seems to install into /usr/local/override directly and the such
[13:17:37] <tomprince_loki> Which it should at least have an option for, or distros will hate us.
[13:17:51] <fuzzie> does autotools get that right? i couldn't decode what it was doing
[13:18:43] <tomprince_loki> Yes, as far as I can tell.
[13:20:16] <edheldil> I did autotools and they used to work
[13:20:36] <fuzzie> (it seems to just install into $moddir, which doesn't seem to get set to anything reasonable anywhere, but i didn't try it)
[13:21:24] <tomprince_loki> moddir is $datadir or $datadir/gemrb
[13:21:39] <tomprince_loki> $datadir is $prefix/share, from autoconf.
[13:21:57] <fuzzie> ok. it is not, here.
[13:22:33] <fuzzie> i assume because autogen.sh is passing flags.
[13:23:17] <fuzzie> right, yes, it passes --disable-subdirs. i expect the cmake script is just trying to reproduce that behaviour.
[13:24:12] <tomprince_loki> And --datadir=$dest/
[13:24:33] <edheldil> plain configure should setup install to /usr/local/, *mostly* FHS , but I have not read FHS then and it quite possibly changed anyway
[13:24:49] <tomprince_loki> That is probably not unreasonable for someone installing manually, but horrible for distributions.
[13:25:06] <edheldil> then rerun configure afterwards
[13:25:16] <edheldil> or did you mean cmake?
[13:25:25] <tomprince_loki> CMake.
[13:25:39] <fuzzie> well, i just mean: cmake was just trying to reproduce what the default autotools setup does.
[13:25:47] <fuzzie> i don't imagine there was any thought beyond that.
[13:25:55] <tomprince_loki> As far as I can tell, it does follow FHS.
[13:26:16] <fuzzie> And there's no sign that autogen.sh does something different :)
[13:27:08] <tomprince_loki> If we are switching to cmake, I should fix it.
[13:27:28] <fuzzie> I imagine it would be a nice fix anyway. I just don't know how to do it cross-platform.
[13:27:40] <edheldil> it would be possible to change cmake's dir settings with some simple flag, no?
[13:28:08] <edheldil> are we switching to cmake? :-O
[13:28:10] <fuzzie> (the autoconfiguration without GemRB.cfg paths is a seperate issue, though.)
[13:28:28] <fuzzie> well, there are some thoughts that maintaining both autotools *and* cmake is silly.
[13:28:31] <tomprince_loki> It works just fine with autotools right now.
[13:29:05] <fuzzie> yes, but it's an "extra" - the intention is that you set the paths.
[13:29:12] <fuzzie> not a problem adding the variables to cmake, of course.
[13:29:28] <tomprince_loki> It is possible to change cmake's paths with flags. But there should probably be an option to obey the FHS.
[13:29:46] <edheldil> fuzzie: I had an idea, that w/o a config gemrb would use it's own minimal dataset to display some add-game menu, similar to scummvm
[13:30:04] <tomprince_loki> fuzzie: I have *never* set the paths. Except for to the games themselves.
[13:30:12] <tomprince_loki> It just works with autotools.
[13:30:12] <fuzzie> tomprince_loki: I don't think you understand.
[13:30:31] <fuzzie> The fact that it works with autotools is helpful, but it's not the 'normal' method.
[13:30:43] <fuzzie> So I mean, it's not that cmake is broken there, it's just that autotools adds that bit.
[13:30:54] <fuzzie> And adding that to cmake is no problem, but I wouldn't call it broken atm.
[13:31:10] <fuzzie> I'm pretty sure we document that you have to set the paths in GemRB.cfg.
[13:32:22] <fuzzie> Maybe not.
[13:32:48] <edheldil> what paths? to game data?
[13:32:51] <fuzzie> We should, it doesn't work automatically on platforms where you can't predict the path anyway.
[13:34:01] <tomprince_loki> I don't know, it just seems silly to require setting the paths when you don't need to.
[13:34:23] <tomprince_loki> I suspect on windows, we could get away with defaulting to paths relative to the binary.
[13:34:50] <tomprince_loki> And use the install paths on unix-y systems.
[13:35:02] <fuzzie> Well, 'unix-y' means 'Linux' here.
[13:35:27] <edheldil> no
[13:35:28] <fuzzie> But defaulting paths relative to the binary is a good idea..
[13:35:41] <edheldil> it used to work on FreeBSD too
[13:35:56] <fuzzie> Well, I mean, it doesn't work on OS X or other platforms which do bundles.
[13:35:57] <tomprince_loki> Probably still does?
[13:36:05] <fuzzie> Because users can move files around.
[13:36:23] <fuzzie> So we probably want some code defaulting paths relative to the binary for those, too.
[13:36:35] <tomprince_loki> Well, I have no idea how bundles work, but shouldn't we just look in the bundle on those.
[13:37:02] <fuzzie> Yes.
[13:37:17] <edheldil> what about having more than one sample config?
[13:37:43] <fuzzie> Sorry; I don't mean to be so specific. On OS X you'd want to call the API for the bundle location, on Windows the API to find the exe, etc.
[13:38:48] <edheldil> it's in argv[0], no?
[13:39:17] <fuzzie> (GetModuleFileName for Win32, CFBundleGetMainBundle+CFBundleCopyBundleURL for OS X, etc)
[13:39:23] <edheldil> or maybe not
[13:39:53] <edheldil> those could be abstracted to VFS.(cpp.h)
[13:40:10] <fuzzie> I could copy that code from another project of mine which does the same thing, but snippets seem easy enough to find on Google.
[13:40:32] <wjp> scummvm and pentagram should have similar code
[13:40:49] <-- raevol has left IRC (Quit: Leaving.)
[13:40:50] <fuzzie> But my original point, which I apparently made very badly - sorry - is that the FHS thing is a seperate issue.
[13:41:08] <wjp> I haven't read the entire backlog, but I'd say it would be quite nice to default some of the search paths to install locations and/or current dir and/or bundle
[13:41:25] <wjp> (as long as it remains overwritable in the config)
[13:41:30] <fuzzie> That is tomprince's suggestion, which is an obvious good thing.
[13:41:32] <edheldil> *sigh* ... what are you exactly trying to achieve?
[13:41:48] <wjp> making life easier for packagers?
[13:42:14] <tomprince_loki> Yes.
[13:42:24] <edheldil> wjp: see the word "exactly" :-P
[13:42:32] <fuzzie> Well, also that Windows and OS X and etc installs don't have predictable installation paths at compile time.
[13:42:47] <wjp> especially for OS X bundles it's a huge improvement not to have to set a path to inside some bundle
[13:43:00] <fuzzie> So you want three patches: (a) fix FHS (b) add PLUGINDIR to cmake (c) make gemrb check for relative paths to the bundle/binary.
[13:43:52] <fuzzie> I apologise for making a hash of that point.
[13:44:04] <tomprince_loki> I can do a+b, and c for unix.
[13:45:07] <edheldil> what about defining a tag for config files, let's say {install}, which would get expanded by calls to macos/win api functions
[13:45:34] <wjp> I'd prefer an implicit default
[13:45:47] <wjp> (that gets used when the path is unset)
[13:46:13] <fuzzie> How do you make it work on unix?
[13:46:20] <fuzzie> I mean, the relative path thing.
[13:46:48] <edheldil> but you want FHS on unices, and that IMO should not be relative to binary
[13:46:56] <wjp> I wouldn't mind not having a relative path check on linux
[13:47:03] <tomprince_loki> I'm not sure off the top of my head.
[13:47:09] <edheldil> I would, that's ugly
[13:47:43] <edheldil> err, I meant that to have a relative patch check is ugly
[13:48:00] <wjp> how about this: on OS X, default to searching in bundle. On Windows default to searching in current dir. On Unix, default to searching install paths
[13:48:01] <tomprince_loki> Well, if you do an install like the one that cmake does, or the the one the autogen does, then it makes sense to do a relative path check.
[13:48:29] <wjp> and cmake/configure could set those install paths to whatever it decided to install to
[13:48:50] <fuzzie> Well, it would be nice to have an option on unix, for *only* when you're building in non-FHS mode.
[13:48:53] <wjp> (regardless of 'flat' or FHS)
[13:48:58] <fuzzie> I am just wondering if one of you had an idea how to do that.
[13:49:29] <tomprince_loki> On linux, you could probably get away with doing readlink on /proc/self/exe, although there has to be a better way.
[13:49:37] <fuzzie> Looks like readlink() on /proc/self/exe is the popular terribly unportable method.
[13:49:40] <fuzzie> Yes, that.
[13:50:18] <wjp> do we need an absolute path? Why not just use '.' ?
[13:50:44] <fuzzie> the current directory is never going to be where you want it :)
[13:51:29] <wjp> dunno... I usually make sure it is, but that's me :-)
[13:51:35] <fuzzie> As far as I am aware all the bundle-type mechanisms on Linux are sufficiently obscure that people will presumably be happy patching things themselves.
[13:51:58] <edheldil> tomprince: unix != linux
[13:52:05] <fuzzie> I just thought it might be nice to handle it on generic *nix if there were a nice portable way.
[13:52:11] <fuzzie> Apparently there is not. :(
[13:54:04] <wjp> but as long as everything is overridable from the config file, not handling corner cases properly by default isn't such a big deal
[13:54:13] <edheldil> hmm, what about starting a ticket or a wiki page and analyze the situation there? I think on unix, we could default to CWD and let it be changeable in config
[13:54:55] <fuzzie> Well, if tomprince could write a patch for the other issues, they could be just applied.
[13:56:03] <tomprince_loki> gcc does it. It searches the PATH for argv[0], if argv[0] doesn't have slashes, otherwise uses argv[0].
[13:56:50] <edheldil> that sounds reasonable .... unless you symlink it :)
[13:56:54] <fuzzie> I can't imagine using argv[0] is going to actually help anyone, but it doesn't seem like it could do any harm.
[13:57:44] <edheldil> well, unless somebody deleted it, gemrb uses argv[0] when searching for it's config file
[13:58:06] <tomprince_loki> PLUGINDIR fix pushed to or.cz/cmake.
[13:59:12] <fuzzie> 12 hours ago? :)
[14:00:04] <tomprince_loki> Well, I had that one particular fix, I didn't have a fix for FHS, and wanted to know which build system was going to get nuked, before learning enough cmake to fix the other.
[14:00:49] <fuzzie> I could try finding an OS X machine to bash at autotools on, but I haven't even found the time to spend an hour testing with VC++, so it wouldn't be soon..
[14:01:42] <wjp> hehe, and here I was reloading the gitweb page because all heads said 12 hours ago :-)
[14:01:44] <fuzzie> Argh, or.cz's misconfigured gitweb is a bit of a pain sometimes.
[14:02:23] <fuzzie> cmake complains at the escaping there.
[14:02:40] <tomprince_loki> How is it misconfigure? Not saying it isn't, just curious.
[14:02:53] <fuzzie> tomprince_loki: click 'patch' next to a file on a diff page
[14:03:11] <fuzzie> there are a couple other things which do that
[14:03:31] <fuzzie> nothing important, i just get very confused when i look away for a moment..
[14:04:08] <fuzzie> tomprince_loki: which cmake version are you using?
[14:04:38] <tomprince_loki> 2.6.4 and 2.8.0.
[14:07:43] <tomprince_loki> Yes, I get that warning too. But at least here, I get the right result from it.
[14:07:46] <fuzzie> Was thinking it would be simple to stop it complaining about the escaping.
[14:07:58] <fuzzie> The warning is "you're using deprecated behaviour, please fix and update your policy".
[14:08:48] <fuzzie> But if I update the policy, I can't make it to the right thing.
[14:12:03] <fuzzie> Oh, because my cmake is broken.
[14:13:23] <fuzzie> http://fuzzie.org/nfs/gemrb/cmake_plugindir.txt does the Right Thing here.
[14:13:26] <tomprince_loki> New version pushed that works. Well, 'strings interface.o' tells me it works.
[14:14:06] <fuzzie> ok, i'll take that one.
[14:15:49] <fuzzie> thanks.
[14:16:10] <CIA-43> GemRB: 03tom.prince * rc055d30cbf1b 10gemrb/CMakeLists.txt:
[14:16:10] <CIA-43> GemRB: cmake: Define PLUGINDIR when using CMake.
[14:16:10] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[14:18:53] <tomprince_loki> fuzzie: Does your comment about finding a machine with OSX mean that you would prefer autotools to cmake? If we can get it to work?
[14:21:40] <fuzzie> I don't really mind either way.
[14:21:47] <tomprince_loki> Gekz was on the other night, saying he add all three systems. I don't know if he is willing to be my guinea pig.
[14:24:04] <tomprince_loki> I suspect that most people feel about the same way.
[14:56:29] <edheldil> I think it would be better to have only one system to support, but I am really not sure who's worse, whether autotools or cmake
[15:00:00] <fuzzie> if anyone has the ability, i would like to know whether the bg2 map icons are in the right place now
[15:00:15] <fuzzie> they look fin e, i just can't run the original
[15:00:19] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[15:00:30] <fuzzie> and thought someone might remember it better than me.
[15:01:26] <edheldil> not me
[15:35:47] --> tomprince_loki has joined #GemRb
[15:44:24] <fuzzie> re the scummvm-style frontend: it would make more sense as something seperate
[15:45:30] <fuzzie> i think Nick Daly has been seperating his launcher so the GUI is seperate, which might help (wouldn't be stuck with GTK+)
[15:46:52] <edheldil> why separate? it would allow us to display something sensible without prior config instead of bombing out
[15:51:26] <tomprince_loki> Would it make sense to implement it in GUIScript. So we don't need to worry about cross-platform toolkits?
[15:51:53] <tomprince_loki> After, of course, we have sensible defaults for the gemrb paths.
[16:00:27] <fuzzie> well, i am as usual not bothered either way :) but setting up data paths, mounting discs etc is a bit complex
[16:02:18] <edheldil> in the most simple case, one or several text entries and two buttons is enough ;-)
[16:08:43] <fuzzie> maybe it ties in well with tomprince's thoughts for importers
[16:11:56] <tomprince_loki> My thoughts importers? Do you mean what I have done for images and sound, and the KEYImporter/DirectoryImporter?
[16:12:28] <fuzzie> the latter, with thoughts about zip/iso imports
[16:15:50] <-- Gekz has left IRC (Quit: Leaving)
[16:18:29] <edheldil> well, MAYBE in an even more simplistic case, screen with some background, "setup you config!" label and "Bother off" button would be enough for the moment ;-)
[16:22:24] <edheldil> later ...
[16:27:30] --> |Cable| has joined #GemRb
[16:43:03] <fuzzie> meh, iwd2 is pretty broken
[16:44:00] <fuzzie> if you move the SetFrame() in iwd2/GUIMA.py to the right window (Window.SetFrame) then the map doesn't flicker any more, but the rest of the GUI does. i guess zapping the DrawRect is the sensible thing to do. but then i find other broken things, so i leave this in the irc log for now.
[16:47:30] --> Maighstir_laptop has joined #GemRb
[17:04:32] * Genraznx pats Fuzzle
[17:04:33] <Genraznx> Its okay
[17:04:40] <Genraznx> Just shoot it with a gun
[17:57:58] <lynxlynxlynx> fuzzie: bg2 map icons are fine
[17:58:07] <fuzzie> thanks :)
[18:01:09] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[18:02:24] <fuzzie> huh, hadn't realised the Black Wyrm forums had become pay-for..
[18:04:51] <lynxlynxlynx> see the g3 thread, there's some good comedy at the start by temujin :)
[18:22:29] <fuzzie> Just, meh, where is my "don't give me results that want $30 to view" option in Google.
[18:23:17] <fuzzie> am appreciating the thread though.
[18:27:45] <fuzzie> I was wondering how the character-specific items worked.
[18:45:25] <lynxlynxlynx> you mean things like keldorn's armor?
[18:46:46] <fuzzie> well, that is maybe a bad example, but yes :)
[18:52:50] <wjp> one more thought about directories: it might eventually be nice to have real (multi-directory) search paths. I could imagine it would be useful to keep mods organized
[18:53:17] <fuzzie> see tomprince's patches
[18:53:26] <wjp> nice :-)
[18:54:51] <wjp> the DirectoryImporter?
[18:54:54] <fuzzie> yes
[18:56:08] <fuzzie> so you just have an array of ResourceMgr instances; add a DirectoryImporter where needed to add to the path.
[18:57:34] <lynxlynxlynx> yeah, i think it was buggy in the original and anyone could wear it
[18:57:55] <lynxlynxlynx> there's no action the check the actor name?
[18:58:22] <fuzzie> well, it's already equipped by the time an action happened
[18:58:25] <lynxlynxlynx> iirc you could exploit such checks by naming yourself the same, but I think now mods also check some stats, since those don't change
[18:59:07] <fuzzie> i haven't had the patience to test the DirectoryImporter patch, but at a glance it looked ok (although i'd move the code out of the header)
[18:59:30] <fuzzie> and imo it is an obvious good refactoring
[19:04:20] <fuzzie> and i think is rather nicer for keeping mods organised than just hacking search paths in; eg you can easily add a (cached) zip resourcemgr.
[19:58:45] <-- Maighstir_laptop has left #GemRb
[20:04:51] --> Edheldil_ has joined #GemRb
[20:37:59] --> Maighstir_laptop has joined #GemRb
[21:06:45] --> tomprince_loki has joined #GemRb
[21:16:20] --> cfchris6_ has joined #GemRb
[21:20:10] <-- cfchris6 has left IRC (Ping timeout: 264 seconds)
[21:50:15] <-- Maighstir_laptop has left #GemRb
[22:38:26] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:40:40] <tomprince_loki> I'll to write a zip resource manger, if anybody wants it, on top of libarchive.
[22:41:41] <fuzzie> which seems to also be shipping both autotools for sane platforms and cmake in desperation for the rest..
[22:43:03] <tomprince_loki> :)
[22:43:34] <fuzzie> i was more thinking :-( myself
[22:43:57] <tomprince_loki> That too.
[22:47:05] <fuzzie> seems like a reasonable idea, though. no idea if it would be wished-for much.
[22:48:19] <tomprince_loki> That's why I haven't written in yet. It is *way* down on my todo list.
[22:48:39] <tomprince_loki> I have more than enough other stuff to do ....
[22:48:56] <fuzzie> :)
[22:49:00] <Lightkey> totally unheard of
[22:49:07] <tomprince_loki> But if somebody actually has a real use for it *now*, then I can code it up sooner.
[22:51:15] <Edheldil_> good night
[22:51:19] <-- Edheldil_ has left IRC (Quit: Really?)
[22:59:13] <fuzzie> tomprince_loki: your DelAllWindows patch is missing one of the callers?
[23:01:08] <tomprince_loki> Yes, looks like, probably grep for DelWindow(0xfff) or something, and didn't catch the Oxffffu.
[23:01:40] <fuzzie> Can't commit from here, just looking.
[23:04:03] <tomprince_loki> Fixed.
[23:30:00] --> raevol has joined #GemRb
[23:48:30] <tomprince_loki> Any one here familiar with Coq?
[23:50:23] <Lightkey> whoever thought of that name?
[23:52:32] <tomprince_loki> It originated in France.
[23:54:34] <tomprince_loki> It originated from the ideas of Thomas Coquand.