#gemrb@irc.freenode.net logs for 16 Sep 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:25:12] <-- Maighstir___ has left IRC (Quit: .)
[00:53:01] <-- yyz has left IRC (Read error: Connection reset by peer)
[00:53:54] --> yyz has joined #gemrb
[01:06:45] <-- yyz has left IRC (Quit: leaving)
[01:09:48] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[01:27:48] <-- brad_a has left IRC (Quit: brad_a)
[01:31:49] --> brad_a has joined #gemrb
[01:41:52] <-- brad_a has left IRC (Remote host closed the connection)
[01:42:01] --> brad_a has joined #gemrb
[01:52:30] <-- brad_a has left IRC (Remote host closed the connection)
[01:52:49] --> brad_a has joined #gemrb
[01:57:43] <-- brad_a has left IRC (Remote host closed the connection)
[01:57:53] --> brad_a has joined #gemrb
[02:03:03] <-- brad_a has left IRC (Remote host closed the connection)
[02:03:16] --> brad_a has joined #gemrb
[02:07:03] <-- brad_a has left IRC (Remote host closed the connection)
[02:07:11] --> brad_a has joined #gemrb
[02:17:02] <-- brad_a has left IRC (Remote host closed the connection)
[02:17:18] --> brad_a has joined #gemrb
[02:31:34] --> joneirik has joined #gemrb
[04:34:55] <-- joneirik has left IRC (Remote host closed the connection)
[04:57:34] <-- PixelScum has left IRC (Read error: Connection reset by peer)
[04:58:29] --> Drakkar has joined #gemrb
[05:26:35] <-- brad_a has left IRC (Quit: brad_a)
[07:14:38] --> edheldil_ has joined #gemrb
[07:21:49] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[07:22:15] --> edheldil_ has joined #gemrb
[07:43:49] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[08:18:35] --> edheldil_ has joined #gemrb
[08:24:50] --> lynxlynxlynx has joined #gemrb
[08:24:50] <-- lynxlynxlynx has left IRC (Changing host)
[08:24:50] --> lynxlynxlynx has joined #gemrb
[08:24:50] --- ChanServ gives channel operator status to lynxlynxlynx
[08:25:08] --> test32894789234u has joined #gemrb
[10:24:26] <-- arikel has left IRC (Quit: Leaving)
[11:22:10] --> yyz has joined #gemrb
[11:48:32] <-- Demitar has left IRC (Ping timeout: 260 seconds)
[11:48:48] --> Demitar has joined #gemrb
[12:44:38] <-- Drakkar has left IRC (Ping timeout: 252 seconds)
[12:48:13] --> Drakkar has joined #gemrb
[12:51:10] <-- yyz has left IRC (Read error: Connection reset by peer)
[12:56:54] --> yyz has joined #gemrb
[14:15:03] <-- Drakkar has left IRC (Ping timeout: 240 seconds)
[14:22:50] --> barra_home has joined #gemrb
[14:37:43] --> Drakkar has joined #gemrb
[14:51:42] <-- Drakkar has left IRC (Ping timeout: 260 seconds)
[15:21:21] --> brad_a has joined #gemrb
[15:22:49] <brad_a> http://dl.dropbox.com/u/13866402/cocoawrapper.patch lynx i made this via command line and im still getting the /dev/null stuff in thereā€¦
[15:23:20] --> Drakkar has joined #gemrb
[15:24:08] <lynxlynxlynx> if you committed it, it will show up
[15:29:45] <brad_a> so its not a problem? im confused. what was that /dev stuff you said was a problem yesterday?
[15:32:12] <edheldil> *that* /dev/null only shows that it's a new file
[15:32:31] <edheldil> s/that/this/
[15:33:28] <brad_a> ok well then i guess i dont know what you were talking about yesterday lynx. yesterday you said "just don't commit dev/ too" and i dont know what you are talking about
[15:34:39] <lynxlynxlynx> there was a folder dev/ in there
[15:34:47] <lynxlynxlynx> but it also could be a bug in the viewer
[15:35:05] <brad_a> is it in that new one? because i searched the patch for dev both times and that dev/null was all it found
[15:35:09] <brad_a> oh
[15:35:21] <lynxlynxlynx> if git whatchanged # looks ok, then nevermind
[15:35:30] <brad_a> well speaking of new one. could somebody test that it doesnt break building on non apple platforms?
[15:35:39] <lynxlynxlynx> later
[15:35:43] <brad_a> thanks
[15:36:31] <brad_a> just fyi i had to change it quite a bit from yesterday
[15:36:49] <brad_a> tomprince: thanks for the plugin macro stuff
[15:50:45] <-- yyz has left IRC (Read error: Connection reset by peer)
[15:51:19] --> yyz has joined #gemrb
[16:20:17] --> Maighstir has joined #gemrb
[16:31:27] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[17:24:55] <Maighstir> The cocoawrapper patch seems to build nicely on Linux and Windows/MinGW
[18:19:31] <brad_a> awesome. thank you for testing.
[18:25:51] <Maighstir> the icon wasn't added to the artwork directory though
[18:35:06] <brad_a> hmmm
[18:35:11] <brad_a> any idea why?
[18:50:16] <-- yyz has left IRC (Read error: Connection reset by peer)
[18:50:24] --> yyz has joined #gemrb
[18:52:24] --> edheldil_ has joined #gemrb
[18:58:33] <Maighstir> nope, maybe patch doesn't like binary files?
[19:17:22] <brad_a> guess ill find out if its a problem when i push
[19:23:36] <-- test32894789234u has left #gemrb
[19:57:31] --> Yoshimo has joined #gemrb
[20:46:05] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:06:00] <tomprince> Maighstir brad_a: you would need to use git-apply for the binary portion.
[21:09:30] <brad_a> the icon is in my repo. shouldnt it be added to artwork when i git push?
[21:24:22] --> barra_away has joined #gemrb
[21:24:23] <tomprince> yes, I was talking about the patch, and applying it. Since it shows up in the patch, it will show up when you push.
[21:27:54] <-- barra_home has left IRC (Ping timeout: 260 seconds)
[21:35:07] <Maighstir> so it's really a non-issue
[21:49:53] <-- yyz has left IRC (Read error: Connection reset by peer)
[21:50:45] --> yyz has joined #gemrb
[21:51:34] <brad_a> well unless there are any objections im going to go ahead and push it.
[22:01:41] <-- brad_a has left IRC (Remote host closed the connection)
[22:01:51] --> brad_a has joined #gemrb
[22:05:48] <tomprince> You should remove the commented out SET line in the CmakeFile.txt
[22:06:20] <-- brad_a has left IRC (Ping timeout: 252 seconds)
[22:07:00] --> brad_a has joined #gemrb
[22:10:22] <tomprince> And I think there is probably a bettern name for LAYOUT=library, perhaps mac or osx or framework? And related to that, you have a mix of absolute paths and paths relative to $ENV{HOME}, and totally ignore CMAKE_INSTALL_PREFIX.
[22:14:32] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[22:15:54] <brad_a> well I am/was going to add other layouts for mac such that you could package the plugins and dylib into the app bundle
[22:21:40] <Maighstir> I understand the dylibs, as they could be shared between other applications, but is there a reason to not have the plugins bundled?
[22:22:32] <fuzzie> well you might not necessarily want an app bundle, i guess
[22:23:12] <fuzzie> but something a bit more explanatory for LAYOUT might be nice for future people poking at it
[22:23:30] <Maighstir> yes
[22:25:00] <-- brad_a has left IRC (Remote host closed the connection)
[22:25:01] <Maighstir> though I was thinking, if you're building a bundle anyway, and putting the main binary there, what's the reason of not bundling the plugins?
[22:25:31] <tomprince> And I sort of think that CMAKE_INSTALL_PREFIX would be better than $ENV{HOME} as a base.
[22:25:46] --> brad_a has joined #gemrb
[22:30:16] <-- brad_a has left IRC (Ping timeout: 260 seconds)
[22:53:13] --> brad_a has joined #gemrb
[22:56:55] <brad_a> the only proper places for these things to go on a mac in are the app bundle, ~/library/application support, or /library/application support.
[23:06:42] <brad_a> i will use cmake_install_prefix for the application and the bonus goodies tho
[23:10:03] <tomprince> Well, I would suggest that cmake_install_prefix should only be either ~ or /
[23:10:16] <tomprince> But then, I have never realy used a mac.
[23:10:35] <brad_a> that actually sounds like a good idea
[23:13:26] <tomprince> If OSX is sanely designed, then you probably even add other directories that it search, other than ~ or /
[23:14:10] <tomprince> At the very least, I recall tools for installing each program in a seprate folder, and the populating /usr/local with symlinks for each package (on unix).
[23:15:53] <brad_a> well like i said apple intends for applications like this to not have files is arbitrary locations. these is nothing stopping me form allowing cmake to put stuff anywhere it wants provided it has permissions. its just a guideline and isnt actually enforced in any way
[23:16:17] <brad_a> plus /usr and other unix directories are hidden by default on a mac
[23:21:11] <brad_a> maybe i should jsut put in the extra effort to figure out how to get cmake to package plugins and the dylib in the bundle then i can allow whatever install prefix the user wants
[23:21:59] <brad_a> well that wouldnt really work either. isnt the plugin path hardcoded in gemrb?
[23:22:12] <brad_a> i guess i can use a relative path
[23:22:49] <tomprince> Well, clearly, anybody can override everything anyway. But it seems to me like .../Library/Application Support and .../Aplications are the mac equivalent of .../bin and .../share so installing to them relative to an arbitrary prefix seems like thing to do. I think beos/haiku have a similiar layout, but have a larger search path than the mac, as well.
[23:23:39] <tomprince> There is a todo to teach gemrb to search relative to its install path.
[23:23:52] <brad_a> maybe i should tackle that todo
[23:24:20] <tomprince> And it would be reasonable to teach the plugin loader to load from a bundle on OSX.
[23:24:22] <brad_a> yes it would
[23:24:33] <brad_a> byld already looks in the bundle for libraries
[23:24:36] <brad_a> dyld
[23:24:58] <tomprince> It might even be reasonable to allow guiscript and gmerb overrides to located in the bundle.
[23:25:08] <brad_a> yes certainly it would
[23:25:14] <brad_a> i already do this on ios
[23:25:21] <brad_a> but im not using cmake for that
[23:25:49] <brad_a> i just have a build script+hack in the gemrb interface code
[23:27:35] <brad_a> so gemrb currently cant load plugins for a relative path?
[23:27:41] <tomprince> If you unhack it, you should push it upstream.
[23:28:29] <tomprince> Well, if you give it relative paths, it will look relative to the current directory.
[23:30:25] <tomprince> It would be ideal if it could figure out where the binary was originally installed relative to the plugins, etc, and then look in the filesystem at the same path relative to the current binary location. (as well as the original ones)
[23:30:31] <tomprince> gcc does this.
[23:32:31] <tomprince> If you do 'gcc -print-search-dirs' you see thing like /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/lib/ for that reason.
[23:33:26] <brad_a> well if i understand i should just be able to set plugindir to ../Plugins since the plugin directory of an app bundle is required to be there
[23:34:25] <tomprince> Well, but that is relative to the binary, not relative to the current directory.
[23:34:32] <brad_a> thats what i need
[23:34:50] <brad_a> in an app bundle they will always be located relative to the binary
[23:35:08] <tomprince> Yes, so you will need to implement that.
[23:35:15] <brad_a> i can do that
[23:36:02] <brad_a> change cmake to use CMAKE_INSTALL_PREFIX for everything except plugins and the dylib which i will have cmake build into the app bundle
[23:36:14] <brad_a> then everybody is happy
[23:37:21] <brad_a> ill have to mull this over when i get home
[23:44:56] <brad_a> anyhow since it will be awhile before i get around to figuring out how to get cmake to package plugins etc. id like to go ahead and push this as it is.