00:01:11  * bcraigquit (Ping timeout: 260 seconds)
04:02:14  * auroraeosrosequit (Ping timeout: 240 seconds)
05:14:36  * madewokherdquit (Remote host closed the connection)
05:15:44  * TReKiEquit
05:58:00  * TReKiEjoined
06:34:40  * ender`joined
08:17:40  * azenojoined
09:27:40  * sungamiquit (Ping timeout: 252 seconds)
09:28:57  * sungamijoined
09:34:30  * auroraeosrosejoined
11:04:38  * auroraeosrosequit (Ping timeout: 240 seconds)
11:10:49  * auroraeosrosejoined
12:30:25  * bcraigjoined
13:39:00  * bcraigquit (Ping timeout: 256 seconds)
16:20:11  * vpovirkjoined
16:47:51  * sungamiquit (Quit: No Ping reply in 180 seconds.)
16:48:07  * sungamijoined
16:48:07  * sungamiquit (Changing host)
16:48:07  * sungamijoined
20:09:40  <nemequ>I have a package that I recently managed to get working with mingw, and I would like to get working on coapp. It contains a shared library, a bunch of plugins (loaded with LoadLibrary on windows), and a couple of executables... are there any existing packages which would be a good guide for something like that?
20:10:46  <vpovirk>coapp... doesn't really exist as a general package manager at the moment...
20:12:09  <nemequ>hm, okay... in that case, any ideas on what i should do to best support windows?
20:13:01  <nemequ>I know basically nothing about windows development, and haven't really used it for anything more than playing Civilization for the better part of a decade, so I'm a bit out of the loop...
20:13:22  <vpovirk>uh, nope, if I thought there were a good existing packaging system for windows I wouldn't be interested in coapp ;)
20:13:55  <FearTheCowboy>nemequ -> when you say package, I'm assuming you mean for redistribution to end-users, right?
20:14:08  <nemequ>FearTheCowboy, well, more for developers
20:14:34  <nemequ>the executable may be convenient for *some* end users, but it's command line, so probably not many people one windows will be interested
20:14:47  <FearTheCowboy>well, we *can* build packages for native libraries for NuGet that are consumable by c++ developers
20:14:53  <nemequ>FearTheCowboy, if it helps, the project is http://quixdb.github.io/squash/
20:15:19  <nemequ>FearTheCowboy, yeah, consumable by developers is really what i'm after.
20:17:00  <FearTheCowboy>Interesting.
20:17:32  <FearTheCowboy>it looks like you need libraries for all the compression types; where do those currently come from?
20:18:03  <nemequ>FearTheCowboy, yum or apt ;)
20:18:21  <FearTheCowboy>and if one wanted to do it for windows?
20:18:37  <FearTheCowboy>I assume that at this point you'd have to compile those too...
20:18:41  <nemequ>for windows, there are dlls on fedora which are used for cross compilation for some of them (zlib, lzma, and a couple others)
20:18:55  <FearTheCowboy>ah. workable, but not very replicable.
20:19:02  <nemequ>but most of the less popular codecs are git submodules
20:19:12  <nemequ>so the code is basically statically linked into the plugin
20:19:24  <FearTheCowboy>hmm.
20:19:32  <nemequ>i seem to remember seeing at least a zlib coapp package
20:19:48  <FearTheCowboy>Yeah, we've done zlib and bzip afaicr
20:20:09  <FearTheCowboy>from a best-practice perspective, you'd be best served having each of the compression libraries packaged as a pkg
20:20:22  <FearTheCowboy>and then consume them all in the squash build
20:20:51  <FearTheCowboy>currently, we don't have any support for cmake (although, it's really high on my list of things to look at after my next release)
20:21:00  <nemequ>FearTheCowboy, in theory yes, for some of them, but others really are meant to be included in your project instead of using a shared library, even in linux
20:21:05  <FearTheCowboy>that's not to say you couldn't use the packages with cmake
20:21:15  <FearTheCowboy>it would need some manual love and care is all.
20:21:41  <nemequ>oh, i kind of assumed this would have to circumvent the build system entirely. i'd definitely like to reuse anything i can, though...
20:22:11  <FearTheCowboy>well, CoApp's NuGet packages support static libs and dynamic (shared) libs so you can consume them statically if you want your binaries to have the code (ie, instead of referencing the shared zlib.dll)
20:23:15  <FearTheCowboy>hmmm.
20:23:20  <nemequ>FearTheCowboy, well, i've kind of taken the position of shared libraries whenever possible, but for plugins/platforms where a shared library isn't available, fall back on the internal copy
20:23:46  <nemequ>for example lzf will use the package on fedora, but i don't think debian has one so we use the internal copy
20:26:04  <FearTheCowboy>Well, this is probably doable-although, I'd recommend holding off till I can release the next version of the tools (maybe in the next week or two)
20:26:32  <nemequ>okay, i'm good with that.
20:27:03  <FearTheCowboy>I would have had it out a few weeks ago, but my tester got reassigned, and ... I don't know when I'm ever getting him back.
20:27:34  <FearTheCowboy>so I've had to kinda backfill that, as well as handling two other projects concurrently. Needless to say, not everything is getting done in a timely manner :S
20:28:04  <nemequ>np, i'll just lurk here for a while.
20:29:32  <nemequ>one more question: are all the forks on the github page the recommended way of doing things, or should the coapp/autopackage stuff ideally live in the upstream packages?
20:29:47  <FearTheCowboy>ideally, it should be upstream
20:30:02  <FearTheCowboy>eventually we'd like to not have to have a fork for anything
20:30:10  <nemequ>okay, then it will be for squash :)
20:34:16  <nemequ>FearTheCowboy, vpovirk, thank you for the help
20:34:20  <FearTheCowboy>np
21:25:22  * vpovirkquit (Quit: urk IRC v0.-1.cvs - http://urk.sf.net/)
23:03:50  * madewokherdjoined
23:04:28  * auroraeosrosequit (Ping timeout: 240 seconds)
23:10:50  * auroraeosrosejoined
23:49:25  * ender`quit (Quit: Trying to establish voice contact ... please yell into keyboard.)