01:25:15  * Andnequit (Ping timeout: 248 seconds)
01:33:43  * Andnejoined
01:34:01  * Andnequit (Read error: Connection reset by peer)
06:08:30  * drdanzjoined
08:27:56  * ender`joined
08:42:21  * Arnavionquit (Quit: Arnavion)
08:43:27  * Arnavionjoined
09:55:12  * ender|quit (Quit: You must know by now we Brits are going metric inch by inch! -- Greg Chapman)
09:57:18  * ender|joined
11:32:00  * vit122part
14:34:59  * vit122joined
14:35:06  * vpovirkjoined
15:00:55  <FearTheCowboy>Yeah, I'm alive.
15:01:20  <FearTheCowboy>I've been sucked into the vortext known as "Windows vNext planning"
15:47:03  <ender`>let me guess: that's all you're allowed to tell us about it? :)
15:49:11  <FearTheCowboy>At this point, I can't say *too* much; what I can say: I'm working really hard to push a lot of the fundementals in CoApp into the OS itself--I'm working at desgining a 'pluggable-package-manager' interface into Windows so that everything can eventually work together in a unified way.
15:55:48  <vpovirk>so, you can tell us things we already knew
15:56:40  <FearTheCowboy>Yeah, pretty much
15:57:46  <FearTheCowboy>Oh, I can also tell you that I'm working with the chair of the ISO C++ committee on some of this stuff too -- they are looking to formalize some things around library discovery and acquisition
15:58:25  <FearTheCowboy>which fits neatly into the rest of the work I was planning anyway.
16:57:48  * vit122part
17:48:20  * stalledquit (Ping timeout: 260 seconds)
18:41:31  * cH40z-Lordquit (Ping timeout: 248 seconds)
18:41:58  * cH40z-Lordjoined
19:52:14  * vit122joined
19:59:55  * qwebirc89610joined
20:00:12  <qwebirc89610>hey guys
20:01:03  <qwebirc89610>i wanted to ask if there is any way to reuse files between specific pivot configurations
20:01:55  <qwebirc89610>the reason is that i'm trying to create a package that reuses a shared library (.dll) among both debug and release only for Redist
20:01:59  <qwebirc89610>in the bin: folder
20:02:56  <qwebirc89610>that shared library has a significant size (~9MB) so it's a bit of pain to have redundant copies
20:04:41  <qwebirc89610>also, what are the intended semantics of the redist package?
20:05:00  <qwebirc89610>can a redist package depend on another redist package?
20:07:58  <qwebirc89610>it's not really clear how coapp deals with dependencies between packages
20:09:18  <vpovirk>I thought you could just leave debug/release out of the pivots
20:11:02  <vpovirk>the idea of the redist package was that a package could depend on it if applications making use of it would only need the files in bin/, but it didn't work out as planned because of the way static libraries work, I think..
20:11:52  <vpovirk>the way all of that works is going to change shortly, essentially pivot configurations will each be split into individual packages that will install on demand
20:47:30  <qwebirc89610>ok...
20:47:52  <qwebirc89610>another question is interop with C# apps
20:48:02  <qwebirc89610>while many people have suggested splitting native and managed packages
20:48:25  <qwebirc89610>it turns out the redist package was a really nice target for C# wrappers
20:49:09  <qwebirc89610>you can easily pull this off by having a redist package that has both "native" and .net configurations (e.g. "net45")
20:49:21  <qwebirc89610>with specific .targets and .props file for each
20:49:36  <qwebirc89610>i've tested it by hand and works really well
20:49:57  <qwebirc89610>and you can then have a redist of a native library that works for both C++ and C# applications
20:51:39  <vpovirk>well, it's sort of up to the wrapper to determine which .dll it works with, isn't it?
20:51:51  <qwebirc89610>yeah, definitely
20:52:20  <qwebirc89610>this was only for cases where the wrapper project is developed independently of the native project
20:52:28  <qwebirc89610>like in some 3rd party effort
20:52:38  <qwebirc89610>instead of duplicating the binary DLLs themselves
20:52:49  <vpovirk>maybe it'd be possible for it to depend on the package for the correct configuration and pull the .dll out of that
20:53:02  <vpovirk>but that gets into details I don't know
20:53:10  <qwebirc89610>yeah, that's exactly how I got it to work
20:53:48  <qwebirc89610>the C# wrapper depends on the native package, which then in turn knows how to deploy the DLLs for a managed project
20:54:08  <qwebirc89610>it seems kludgy, but is not really
20:54:10  <vpovirk>I don't think it makes sense to have the native packages install a .dll for .net projects, as it couldn't know which dll to use
20:54:27  <qwebirc89610>well, more or less
20:54:43  <qwebirc89610>if you're doing p/invokes you have to compromise your application architecture anyway
20:54:57  <qwebirc89610>meaning you have to force an x86 or x64 platform configuration
20:55:08  <vpovirk>you might require a specific configuration of the library though
20:55:15  <qwebirc89610>yeah
20:55:23  <vpovirk>beyond the typical pivots
20:55:41  <qwebirc89610>well, before finding out about CoApp I was doing this by hand
20:55:49  <qwebirc89610>and it works pretty well
20:56:05  <vpovirk>in most cases you could probably assume an arbitrary C lib version, release, x86
20:56:13  <qwebirc89610>yeah
20:56:21  <qwebirc89610>that's what i've been assuming
20:56:34  <qwebirc89610>for x86/x64 you can look up the project platform in the vcproj
20:57:01  <vpovirk>I think ideally you'd want the tools for generating managed packages to support generating this sort of thing
20:57:11  <vpovirk>I don't know if there's something coapp tools can do to make that easier
20:57:24  <qwebirc89610>i agree this seems outside the scope of coapp
20:57:28  <vpovirk>or less kludgy
20:57:56  <qwebirc89610>is there a way to specify custom parts of the nupkg inside a coapp autopkg file?
20:58:11  <qwebirc89610>so the custom parts get added while preserving the automatically generated ones?
20:58:46  <vpovirk>I think you can put arbitrary files just in the package and not really use them anywhere
20:59:11  <qwebirc89610>ok, that may be enough actually
20:59:25  <qwebirc89610>since for managed libraries there are not really many pivots besides framework version
21:00:23  <qwebirc89610>which for a p/invoke is really handled the same way for all versions, .net35 would be the same as .net40, etc
21:00:38  <vpovirk>this is going to come up when we want to package gtk# isn't it..
21:01:13  <qwebirc89610>i think it will come up everywhere where managed code calls native code
21:01:19  <qwebirc89610>because you essentially have two choices
21:01:28  <qwebirc89610>either package the native dependency with your own package
21:01:49  <qwebirc89610>thereby duplicating the package
21:01:57  <vpovirk>it doesn't make sense to make packagers of managed projects responsible for this
21:02:05  <qwebirc89610>yeah, agreed
21:02:52  <vpovirk>but I think we have the wrong people on the discussion right now
21:03:14  <vpovirk>we need someone who understands the nuget packaging tools and someone who understands the coapp tools better than I do, probably
21:03:28  <qwebirc89610>i can write this up somewhere more permanent
21:03:56  <qwebirc89610>i think it is possible to figure out a good compromise for native/managed interop packages
21:04:21  <qwebirc89610>it is certainly possible using the new msbuild script injection from NuGet
21:04:27  <qwebirc89610>just a matter of figuring out standards
21:04:56  <qwebirc89610>i would much prefer to avoid package duplication on wrappers
21:04:58  <vpovirk>ideally those packages should be able to pull whatever dll's they need out of the native ones and still get dependency handling + updates, which I wouldn't consider a compromise
21:05:07  <qwebirc89610>yeah, agreed
21:05:26  <vpovirk>and I don't see a reason that's not possible
21:05:43  <vpovirk>(or can't be made possible)
21:05:44  <qwebirc89610>i've done it by hand, so it definitely is
21:06:04  <qwebirc89610>the problem is the current way does require forethought from the developers of native packages
21:06:26  <qwebirc89610>because it's the native package that carries build targets for managed projects
21:06:44  <vpovirk>if you had some way to override the pivot values for a native package, would that help?
21:07:11  <qwebirc89610>you mean, from the managed package side?
21:07:16  <vpovirk>yeah
21:07:34  <qwebirc89610>that could be possible actually
21:07:49  <vpovirk>well, some of them are already just configurable
21:08:12  <qwebirc89610>actually, i think it could be possible to get by if there is a way to just know where pivots are
21:08:12  <vpovirk>but you'd want to be able to specify a C library version instead of relying on a check that won't work
21:09:04  <qwebirc89610>for example, if I am a managed package that depends on a native package, if I could ask where a specific pivot is, like: give me the bin folder of "x86,dynamic,desktop,release"
21:09:22  <qwebirc89610>that would be everything the managed package would need to know
21:09:27  <qwebirc89610>to generate build targets for the project
21:10:00  <vpovirk>I think the way it's set up now there's no way to calculate that without actually setting variables in msbuild corresponding to those pivots
21:10:34  <qwebirc89610>yeah, i guess so
21:10:44  <vpovirk>and it's sort of an implementation detail that there is a bin directory
21:12:10  <qwebirc89610>agreed, although I think we can assume that wrappers know about their native dependency packages well enough
21:12:30  <qwebirc89610>i guess the only thing that would be needed then would be to get the root location of a dependency package
21:12:46  <qwebirc89610>if i had the location where the native package was installed
21:13:17  <qwebirc89610>then assuming I know the folder structure of that package
21:13:24  <qwebirc89610>that would be enough to figure out the rest, ultimately
21:14:23  <vpovirk>well, we can't assume that if the native dependencies are subject to updates
21:14:30  <vpovirk>maybe they'll gain their own dependencies later
21:15:18  <qwebirc89610>true
21:15:55  <vpovirk>(and you shouldn't have to know what the dependencies are of the library you're actually using)
21:16:42  <qwebirc89610>agreed
21:18:49  <qwebirc89610>then it seems like there's only two ways
21:19:15  <qwebirc89610>either the native package knows how to deploy itself onto a managed project (as I'm doing now)
21:19:38  <qwebirc89610>or there's a package resolution mechanism that can be called from the managed project side
21:20:14  <qwebirc89610>like saying "install all redist from this package with this pivot configuration onto this folder"
21:21:00  <qwebirc89610>something like a general msbuild task
21:21:07  <qwebirc89610>or powershell script
21:21:11  <vpovirk>well, or you just depend on the native package and configure things such that it will install everything it needs in bin/
21:21:38  <qwebirc89610>but that has the same problem with dependencies, no?
21:21:50  <qwebirc89610>because you'd have to reconfigure the dependencies also
21:22:08  <vpovirk>no, because dependencies of the native package will install
21:22:22  <vpovirk>I have to check something
21:22:49  <vpovirk>the redist packages don't have dependencies, but the main packages do
21:23:18  <qwebirc89610>hmmm, that makes the redist packages less useful for installs, i think
21:23:38  <vpovirk>I guess the native package would have to be in charge of configuring its own dependencies somehow
21:23:53  <qwebirc89610>yeah
21:23:54  <vpovirk>redist packages are useless
21:23:59  <vpovirk>and they're going to be going away
21:24:05  <qwebirc89610>that's what I'm realizing
21:34:32  <qwebirc89610>i'll have to go now
21:34:33  <qwebirc89610>thanks for the clarifications
21:34:42  <qwebirc89610>i'll think about it some more
21:35:05  * drdanzquit (Remote host closed the connection)
21:35:43  * qwebirc89610quit (Quit: Page closed)
21:38:58  * vpovirkquit (Quit: urk IRC v0.-1.cvs - http://urk.sf.net/)
22:14:27  * madewokherdjoined
22:36:28  * vit122part
22:36:38  * vit122joined
22:55:30  * stalledjoined
22:56:21  * enderjoined
22:58:18  * ender`quit (Ping timeout: 264 seconds)
23:07:03  * [[zzz]]joined
23:10:27  * [[zz]]quit (Ping timeout: 252 seconds)
23:11:59  * enderquit (Quit: Sin is an imaginary disease invented to sell you an imaginary cure.)
23:37:23  * stalledquit (Ping timeout: 260 seconds)
23:41:00  * stalledjoined