00:36:12  * piscisaureus_part
00:43:18  * FearTheCowboyjoined
00:43:32  * FearTheCowboyquit (Changing host)
00:43:32  * FearTheCowboyjoined
01:04:37  <virmitio>FearTheCowboy: you actually here right now?
01:05:35  * virmitioquit (Quit: Leaving.)
01:40:18  * gixquit (Ping timeout: 252 seconds)
01:42:09  * gixjoined
02:50:41  * dmex_joined
02:51:14  * dmexquit (Ping timeout: 265 seconds)
02:51:59  * dmex_changed nick to dmex
02:52:06  * dmexquit (Changing host)
02:52:06  * dmexjoined
03:05:40  * gixquit (Ping timeout: 245 seconds)
03:06:18  * _Andrewjoined
03:10:17  * gixjoined
04:37:44  * TReKiEquit
04:39:00  * madewokherdquit (Remote host closed the connection)
05:01:53  * Jonny5joined
05:01:54  * Jonny5quit (Changing host)
05:01:54  * Jonny5joined
05:28:58  * TReKiEjoined
05:55:23  * _Andrewquit (Quit: Ex-Chat)
06:11:30  * _Andrewjoined
06:11:30  * _Andrewquit (Changing host)
06:11:30  * _Andrewjoined
06:13:36  * ender`joined
06:39:03  * remy_ojoined
09:37:19  * HamishCjoined
09:39:03  * ssam2joined
10:22:08  * dmexquit (Quit: uninstalling the internet)
10:25:40  * dmexjoined
10:35:24  * _Andrewquit (Quit: eating)
10:45:23  * HamishCquit (Ping timeout: 265 seconds)
11:15:45  * HamishCjoined
11:59:25  * _Andrewjoined
11:59:25  * _Andrewquit (Changing host)
11:59:25  * _Andrewjoined
12:52:21  * madewokherdjoined
13:01:29  * remy_oquit (Quit: WeeChat 0.3.7)
13:19:13  * piscisaureus_joined
13:24:02  * Jonny5quit (Quit: Leaving.)
13:32:04  * piscisaureus_quit (Read error: Connection reset by peer)
13:52:05  <madewokherd>did we come up with a good way to manage self-built dependencies for coapp packages we want in coapp-packages yet?
13:53:26  <auroraeosrose>dunno know
13:53:39  <auroraeosrose>have to ask virmitio/FearTheCowboy when they return
13:56:33  <madewokherd>I've been doing it a particular way, but if there's another standard I'll want to change it
14:11:14  <madewokherd>I wonder if we could build the -dev packages for libintl/libiconv before we build the regular packages..
14:11:44  <auroraeosrose>... how would you do that? hehe
14:12:01  <auroraeosrose>the dev packages need .lib files generated when the .dlls are built no ?
14:12:25  <madewokherd>yes, you'd have to build the dll's without the deps, but you wouldn't package those
14:12:50  <auroraeosrose>hmmm, that might be possible
14:12:54  <auroraeosrose>build but not package
14:13:02  <madewokherd>I'm not sure yet if it simplifies anything..
14:13:25  <madewokherd>also I suspect the dll's will have to be in the same package
14:13:50  <madewokherd>because I don't think we can make a circular dependency
14:13:53  <madewokherd>which is probably a good thing
14:14:22  <auroraeosrose>yeah, I thought we were just going to do two flavors to avoid that circular dep nonsense
14:14:32  <auroraeosrose>one with gettext one without?
14:15:13  <madewokherd>right but then the gettext that libiconv uses has to use libiconv, and it has to be the same one
14:15:44  <auroraeosrose>yeah - so build build build yes?
14:16:18  <madewokherd>yes, but the end result is two dll's that link to each other
14:16:36  <madewokherd>however you do it
14:17:03  <auroraeosrose>or we just package those two together
14:17:11  <madewokherd>I think we'll have to
14:17:15  <auroraeosrose>ugh, sigh
14:17:38  <madewokherd>we could make an empty libintl package that just depends on libiconv :p
14:17:43  <auroraeosrose>LOL
14:18:00  <bob>er
14:18:43  <madewokherd>and it'd probably be simplest to just have one buildinfo for all of this..
14:21:58  <madewokherd>versioning would be weird
14:22:30  <auroraeosrose>yes....
14:23:00  <madewokherd>one buildinfo might have to mean one repo
14:23:09  <auroraeosrose>the other option is of course to never build libiconv with gettext stupport
14:23:14  * auroraeosrosemumbles
14:23:18  <auroraeosrose>circular deps of doom
14:23:33  <auroraeosrose>or we do three packages
14:23:59  <auroraeosrose>1. libiconv no gettext 2. gettext with libiconv no gettext 3. merged package with both that dep each other
14:24:09  <auroraeosrose>(sigh doom doom )
14:24:17  <madewokherd>3 will have to pull the libintl.dll out of 2
14:24:23  <madewokherd>and repackage it
14:24:28  <auroraeosrose>sure
14:24:38  <auroraeosrose>(or just build again - LOL)
14:25:02  <madewokherd>heh
14:26:08  <madewokherd>I get the feeling the main factor in this decision will be how much virmitio likes it, since he'll have to automate whatever it is
14:33:50  * FearTheCowboyquit (Disconnected by services)
14:33:50  * GarrettS-MSFTjoined
14:34:02  * GarrettS-MSFTchanged nick to FearTheCowboy
14:42:36  * piscisaureus_joined
14:52:44  * virmitiojoined
14:53:05  * alkalinejoined
14:59:01  * _Andrewquit (Read error: Connection reset by peer)
15:16:09  * _Andrewjoined
15:26:37  * ssam2quit (Quit: Leaving)
15:29:01  * remy_ojoined
15:30:09  <madewokherd>what do I have to do in MSVC to distinguish between x86, x86_64, and arm?
15:30:23  <madewokherd>ifdef _M_X86 doesn't seem to be working
15:30:27  <virmitio>like in a define?
15:30:30  <virmitio>ah
15:30:33  <virmitio>one sec
15:30:52  * ssam2joined
15:31:10  <madewokherd>libffi wants to have separate headers for each arch and I don't want to let it
15:32:01  <virmitio>here's what I ended up doing for a similar issue in openssl: https://github.com/coapp-packages/openssl/blob/master/COPKG/opensslconf.h
15:32:38  <virmitio>I'm pretty sure I covered all of the currently known conditions with it
15:32:50  <virmitio>not really sure what to do about arm at the moment
15:32:52  <madewokherd>I guess I can use _WIN64 but it'll make me sad
15:33:03  <auroraeosrose>catches mingw and cygwin ?
15:33:09  <madewokherd>because arches I haven't covered won't #error
15:33:37  <virmitio>auroraeosrose: that was a "just in case" condition that came to mind
15:33:45  <FearTheCowboy>9-
15:34:14  <madewokherd>I'd really like to have a define that says "this is definitely x86" that I can rely on
15:34:21  <auroraeosrose>were you here for our circular deps of doom discussion?
15:34:32  <madewokherd>since I can't use _WIN32
15:36:53  <madewokherd>also, intellisense seems to disagree with my build re: whether _M_X86 is defined
15:40:08  * wwahammyjoined
15:40:47  <madewokherd>http://tinypaste.com/177dd60b
15:41:07  <madewokherd>for the circular dependency discussion
15:41:43  * alkalinequit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:41:49  <FearTheCowboy>CoApp Conf Call 10:30PDT (little less than two hours from now) http://j.mp/wmZr0D install the free lync attendee: http://j.mp/IlsGZV
15:43:22  * ssam2quit (Quit: Leaving)
16:49:44  * sungamiquit (Ping timeout: 245 seconds)
16:59:15  * sungamijoined
16:59:15  * sungamiquit (Changing host)
16:59:15  * sungamijoined
17:16:07  <virmitio>CoApp Conf Call 10:30PDT (15 minutes from now) http://j.mp/wmZr0D install the free lync attendee: http://j.mp/IlsGZV
17:20:43  * rriverajoined
17:20:51  <rrivera>auroraeosrose auroraeosrose auroraeosrose auroraeosrose auroraeosrose
17:23:44  <auroraeosrose>coming!
17:24:02  <auroraeosrose>http://www.youtube.com/watch?feature=player_embedded&v=316AzLYfAzw
17:24:07  <auroraeosrose>also just because it's awesome
17:24:43  <auroraeosrose>why does lync hate me?
17:25:01  <virmitio>because you were mean to it
17:25:37  <ender`>it knows you fear it, and it smells fear
18:02:18  * wwahammyquit (Quit: Give a man a fish and he will eat for a day. Teach him how to fish, and he will sit in a boat and drink beer all day)
18:18:02  * wwahammyjoined
18:44:34  <madewokherd>is there some way I can verify that my libffi package has an assembly with a dll in it?
18:45:32  <virmitio>try installing it and see if you've got an appropriate directory under C:\windows\winsxs\?
18:45:51  <madewokherd>oh, that's where they go?
18:46:03  <virmitio>yep
18:46:25  <madewokherd>cool, I have one
18:46:42  <virmitio>somewhere inside should be your dll
18:48:19  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:48:27  <madewokherd>libffi package pushed
18:48:49  <madewokherd>and I barely had to do any horrible things to it
18:49:00  <virmitio>I'll go push that through the build server when I get back from lunch
18:51:03  <HamishC>virmitio: libjpeg should be good to go, with tests even. libtiff too (with no tests atm)
18:59:16  <madewokherd>what should the version number for libiconv-and-gettext be?
18:59:23  <madewokherd>just the libiconv version?
19:03:09  <madewokherd>eh.. I get the gettext api revs more often, better go with that
19:03:13  <madewokherd>*bet
19:31:02  <madewokherd>crap
19:31:09  <madewokherd>I can't put in two original source locations
19:32:34  * madewokherdjust puts in two product-info sections and will comment one if ptk complains
20:05:05  * _Andrewquit (Quit: sleep)
20:06:58  <madewokherd>so, uh, I can't find the part of libiconv that actually uses libintl :/
20:07:51  <virmitio>lol
20:07:55  <ender`>the iconv application?
20:08:01  <madewokherd>no, just the library
20:08:29  <ender`>isn't iconv(.exe) built as part of libiconv?
20:08:46  <madewokherd>no
20:09:00  <madewokherd>maybe later
20:09:04  <madewokherd>but that doesn't matter
20:09:32  <madewokherd>auroraeosrose!
20:10:10  <auroraeosrose>what???
20:10:14  <auroraeosrose>LOL
20:10:19  <madewokherd>where does libiconv use libintl?
20:10:35  <auroraeosrose>don't remember
20:10:37  <auroraeosrose>it's been awhile
20:10:45  <auroraeosrose>maybe it's just iconv.exe anymore
20:11:31  <madewokherd>
20:11:34  <FearTheCowboy>...
20:11:44  <auroraeosrose>what?
20:11:45  <virmitio>well that would sortof eliminate this whole problem, then, wouldn't it?
20:11:48  <madewokherd>yes
20:11:51  <madewokherd>yes, it would
20:11:59  <virmitio>yay, problem solved
20:12:02  * FearTheCowboyis taking his gun off the mantle.
20:12:09  <auroraeosrose>yeah, although.... we'd still have some weirdness
20:12:20  <virmitio>that frees a slot in the queue for another impossible task
20:12:20  <auroraeosrose>in build -> package steps
20:12:23  <FearTheCowboy>still need to be one repo tho'
20:12:37  <madewokherd>sure
20:12:40  <madewokherd>well
20:12:40  <auroraeosrose>libiconv -> libintl -> iconv -> gettext
20:12:41  <FearTheCowboy>if the iconv.exe source tree still needs intl
20:12:44  <auroraeosrose>yes
20:12:47  <madewokherd>actually I was almost done
20:12:51  <madewokherd>it doesn't seem to be that difficult
20:12:52  <auroraeosrose>LOL - got it working?
20:13:11  <madewokherd>well, I'm at the part where I need to configure the libiconv that uses libintl
20:13:23  <madewokherd>I added ENABLE_NLS and didn't get any linking errors
20:13:54  <madewokherd>(what I ended up doing was adding a "Bootstrap" configuration to the project)
20:14:53  <madewokherd>it's used in relocatable.c
20:14:56  <madewokherd>which we don't use
20:14:58  <madewokherd>that's it
20:16:01  <madewokherd>well that was fun
20:16:58  <auroraeosrose>errr, why are we not using relocatable?
20:17:01  <auroraeosrose>doesn't it need to be?
20:17:30  <madewokherd>yes, through sxs
20:18:52  <madewokherd>whatever they're doing now isn't going to work
20:20:44  <madewokherd>looks like they only use it to find charset.alias, which we're not using either
20:21:25  <madewokherd>they just bake it into the dll on windows
20:24:20  <auroraeosrose>heh, since when is libcharset in the libiconv source.... weird
20:27:47  <madewokherd>so we can use the libintl stuff in gettext/
20:28:19  <madewokherd>which is still a little stupid in that the build process builds libiconv, but otherwise should work
20:32:27  <madewokherd>speaking of which, virmitio, could you add gettext to the build automation and/or refuse because of how stupid the build process is?
20:33:03  <madewokherd>I guess if you could do both that would be impressive
20:38:17  <virmitio>I have now done both
20:38:30  <virmitio>luckily for you, the build process in question is my automation
20:39:06  <virmitio>running it right now to make sure there's no wildly obvious problems
20:46:39  <madewokherd>well, it's stupid in that it builds libiconv and libintl with mingw in order to get one header :p
20:46:54  <madewokherd>which is my fault
20:47:15  <virmitio>it also fails to build when I run ptk release
20:50:16  <virmitio>got all the way through the mingw target, started into the x86, and throws errors starting in libiconvtest.vcxproj, with almost nothing but errors from libintl.vcxproj
20:50:24  <virmitio>it's an impressive wall of red text
20:50:40  <virmitio>kinda reminds me of building perl
20:54:20  <madewokherd>if you clean the mingw target, does the x86 target build?
20:54:45  <madewokherd>I think maybe it's generating files that msvc shouldn't be using
20:55:20  <madewokherd>in which case I'll probably have to make an out of tree build for mingw
21:23:28  <virmitio>yes, running a clean on the mingw target allows the vc10 target to build
21:31:25  * remy_oquit (Quit: WeeChat 0.3.7)
21:36:33  <FearTheCowboy>fyi, I'm having coapp shutdown after 10 or so minutes of inactivity.
21:36:50  <FearTheCowboy>it starts up reasonably quick now, so I dont' see any harm in freeing up that memory.
21:37:44  <FearTheCowboy>oh, and for those who didn't notice, CoApp has it's own debug app now.
21:37:59  <FearTheCowboy>in devtools, there's a DebugWatch app that shows just CoApp's apps
21:38:20  <FearTheCowboy>and it's a lot faster at processing debugging messages than dbgview
21:38:30  <FearTheCowboy>and it's now got a 'clear' menu item.
21:38:44  <FearTheCowboy>it's fairly primitive, really, but better than nothing
21:38:56  <FearTheCowboy>and if anyone wants to make it awesome, the source is in devtools.
21:40:17  <FearTheCowboy>hmm. the clear button crashes it. don't do that.
21:44:43  * wwahammyquit (Quit: For Sale: Intergalactic Proton Powered Electrical Tentacled Advertising Droids)
22:01:46  * Scotisis no longer away : Gone for 22 hrs 32 mins 33 secs
22:01:52  * Scotisis set as away : Reason(lunch)
22:40:00  * ender`quit (Quit: C++ is a modern language where your parent can't touch your privates but your friends can!)
22:47:39  * TReKiEquit
22:48:51  <madewokherd>it's amazing how much of the crap that's involved in a "supported" win32 build configuration you can just ignore when you make a VC project :p
22:50:03  <madewokherd>(e.g. libffi needing only a custom build step involving cl/ml, not some crazy mingw/msvc hybrid)
22:53:25  <HamishC>is it possible to conditionally set a variable in a set block in .buildinfo? ie if ${CONFIG} is "debug" set ${LIBSUFFIX} to "d" so that I can specify libfood.lib as the target instead of libfoo.lib?
22:53:50  * Scotisis no longer away : Gone for 51 mins 55 secs
22:54:45  <HamishC>or is there some other way of achieving this goal (without creating a separate build block)?
22:55:20  <FearTheCowboy>one sec... (
22:56:01  <madewokherd>I'm having trouble with the part where you might want to build libfoo sometimes when there's a libfood
22:58:31  <FearTheCowboy>if you have a debug { } rule and a release { } rule, you can set a property in the rule with set : { libsuffix = "d" }; in the debug one, and set : { libsuffix = "" }; in the release one
22:58:40  <madewokherd>(also, wouldn't you just make debug part of the flavor?)
22:58:43  <HamishC>ahh of course
22:59:09  <HamishC>thanks
22:59:33  <FearTheCowboy>or just set it in debug, and when you use it, use ${libsuffix??} /// which means if libsuffix is null, then just emit nothing
23:01:08  <virmitio>I'm in favor of that option
23:04:03  <virmitio>thus in the debug target: set: { BuildCfg="Debug"; libsuf="d" }; and in the base/build target: set: { libsuf="${libsuf??}"; } targets: { "libfoo${libsuf}.dll", "libfoo${libsuf}.lib" };
23:12:18  * ender`joined
23:17:23  * rriveraquit (*.net *.split)
23:17:23  * ender|quit (*.net *.split)
23:39:25  * cH40z-Lordquit (Ping timeout: 276 seconds)
23:39:35  * cH40z-Lordjoined
23:47:49  * FearTheCowboyis getting tired of tiny changes causing bizarre errors
23:48:40  * TReKiEjoined