00:03:46  * bcraigquit (Ping timeout: 246 seconds)
02:19:35  * coyoquit (Disconnected by services)
03:06:58  * piscisaureus_joined
05:06:41  * piscisaureus_quit (Ping timeout: 245 seconds)
06:33:31  * ender`joined
09:01:01  <ender|>WTF Microsoft: http://eternallybored.org/Image1.png
09:05:43  <ender|>(look at the weird scaling)
12:30:53  * bcraigjoined
12:39:35  * bcraigquit (Ping timeout: 265 seconds)
13:05:39  * bcraigjoined
14:19:57  * piscisaureus_joined
14:47:47  * piscisaureus_quit (Ping timeout: 272 seconds)
14:49:41  * piscisaureus_joined
14:57:55  * piscisaureus_quit (Ping timeout: 272 seconds)
15:05:52  * auroraeosrosejoined
15:46:32  * piscisaureus_joined
15:50:27  * auroraeosrosequit (Read error: Connection reset by peer)
15:51:45  * piscisaureus_quit (Ping timeout: 272 seconds)
16:32:54  * vpovirkjoined
16:35:39  * piscisaureus_joined
16:38:05  <ender|>meeting today?
16:56:49  * HamishCjoined
17:16:15  * FearTheCowboyjoined
17:17:00  <FearTheCowboy>Quick CoApp meeting this 10:30 morning: https://join.microsoft.com/meet/garretts/HZ96LF57 #JoinAnytime
17:57:57  <vpovirk>I missed it, sorry :(
17:58:22  <vpovirk>forgot these were a thing
18:03:01  <FearTheCowboy>s'ok. nothing important this week;
18:05:37  <bcraig>something I've been meaning to ask... I know there is work being done to make it so that clients only need to download the pivots that they are actually using. Is there an example of how to do that?
18:05:57  <bcraig>I know it isn't necessarily production ready at this point, but I'd like to start wrapping my head around how to use it
18:06:49  <FearTheCowboy>gimme a couple seconds.
18:13:01  <FearTheCowboy>So in the next version of the tools, each pivot combination generates a seperate container for the files that are in that pivot combination.
18:13:17  <FearTheCowboy>The .targets/.props files determine which pivots are needed at compile time
18:14:37  <bcraig>is this "container" a different technology, or is it just a bunch of nuget packages with dependencies linking them together?
18:15:12  <FearTheCowboy>just another nuget file (that just contains the files, no .targets and .props)
18:15:23  <FearTheCowboy>it doesn't have dependency data in it either
18:15:47  <FearTheCowboy>the main package has the smarts to determine what it needs at compile time
18:16:02  <bcraig>does this file-only package show up in regular searches on nuget.org?
18:16:11  <FearTheCowboy>and includes an msbuild extension task and a nuget extension that makes it all work together
18:16:45  <FearTheCowboy>no, it won't, if you use the publish-nugetpackage cmdlet
18:17:04  <FearTheCowboy>since it uploads the overlay versions and then marks them as unlisted
18:17:31  <FearTheCowboy>it also just means you can specify the base package, and it picks up all the overlays without you having to upload them all individually
18:18:13  <bcraig>gotcha. Is there a prototype zlib (or some other package) in a github repo that I can look at that does this?
18:18:47  <FearTheCowboy>the .autopkg script actually doesn't change at all to make this happen
18:19:31  <FearTheCowboy>you can update to the "development version" (my off-the-cuff builds) of the tools by using update-coapptools -devlopment -killpowershells
18:19:52  <FearTheCowboy>and if you generate a package, you should get the new one with the overlay pgks.
18:20:24  <bcraig>hmm, ok.
18:20:59  <ender|>...and i'm back
18:21:09  <ender|>(and missed the meeting)
18:23:43  <FearTheCowboy>I've also been tweaking the impelemtation of the stuff that copies bin files to the output folder (so that you can generate arbitrary collections of files and do arbitrary things with them)
18:24:37  <FearTheCowboy>you can see some of the progress that was made if you look at the conversations: https://github.com/coapp/coapp.powershell/issues?state=open
18:24:43  <bcraig>so... sort of a cross between the nuget use case and the chocolatey use case?
18:25:17  <bcraig>like if I wanted to package a static lib and a code generator in my package, and have the .targets / .props invoke the code generator some way
18:26:04  <FearTheCowboy>that's *possible*, but I'd have to make an example of how to make that work right.
18:26:17  <FearTheCowboy>wouldn't require any tool changes tho;
18:26:57  <bcraig>the dream there is to have the input file just be listed as a source file, and have the tool automatically invoked on that source file. I have no idea how hard that is though
18:27:22  <bcraig>It almost feels like have a way of adding a new language to the project system (though not necessarily the editor)
18:29:16  <vpovirk>I feel like the nasm package did that..
18:29:25  <vpovirk>but maybe I misunderstood
18:29:40  <FearTheCowboy>Yeah, kindof.
18:30:20  <FearTheCowboy>it's not terribly hard, just not well documented
18:30:25  <FearTheCowboy>nor good examples
18:30:45  <FearTheCowboy>and I think the nasm one doesn't quite work right either nowth athI think about it
18:31:33  <bcraig>well, if I have a bad example and a week or so to tinker with it, I -might- be able to make a good example with a real product
18:32:14  <FearTheCowboy>After I get the next version of the tools out (which is only days away) perhaps we can spend a couple days and make a good go of this with something like nasm
18:32:41  <bcraig>well, the selfish project I had in mind was Apache Thrift, but sure :)
18:33:30  <bcraig>nasm is almost certainly farther along right now, as I haven't even started making the nuget packages for thrift yet
18:33:45  <bcraig>I'm just happy that there is a boost that is good enough to limp along with
18:33:49  <FearTheCowboy>hmm. thrift would be a good idea too.
18:38:59  <FearTheCowboy>So, just so that I'm clear on how you think about thrift working, you'd like to put thrift source files into your project so that when you hit build, it generates the C/C++, and passes that along to the Compiler task.
18:39:17  <bcraig>right
18:39:39  <bcraig>so the project file view (whatever it's called) might have two files in it, main.cpp, and foo.thrift
18:40:11  <bcraig>and the project would figure out that main.cpp, and three other cpp files need to get passed to cl
18:40:29  <FearTheCowboy>and you'd include the thift-exe that in the package itself.
18:40:34  <FearTheCowboy>Yeah, we can totally do that.
18:40:35  <bcraig>yep
18:41:16  <bcraig>what if you need to inspect the .thrift file to figure out the names of the .cpp files?
18:41:35  <bcraig>and by "inspect", I mean run the thrift-exe with some extra flags to find out the names of those files
18:41:53  <bcraig>somewhat reminiscent of figuring out header dependencies given a cpp file
18:42:20  <FearTheCowboy>does the thrift-exe generate files that are predictably named from the source file, or the declared elements inside the .thrift file
18:42:21  <FearTheCowboy>??
18:42:27  <bcraig>some of both
18:42:31  <FearTheCowboy>hmm.
18:42:42  <FearTheCowboy>lemme think about that a moment.
18:43:00  <bcraig>it doesn't currently have a way to return that information, but that would be easy (on the thrift side) to add
18:43:44  <FearTheCowboy>Really? it doesn't return that information? even via stdout?
18:44:27  <bcraig>hasn't been a lot of demand for that. Generally the files that the .thrift generates aren't changing all that often
18:44:59  <FearTheCowboy>hmm. But you'd need to know what they were in the first place. Which I think is one step too many.
18:45:13  <bcraig>For the nuget case, yes
18:45:53  <bcraig>The current workflow requires people to know ahead of time, and add those files to their project
18:45:57  <FearTheCowboy>If we could make the thrift generator spit out the filenames in a predictable way via stdout, we could easily dynamically transform that into additional <ClCompile> file objects at build time.
18:46:13  <FearTheCowboy>then you'd be able to just "build" .thrift files
18:46:52  <bcraig>well, the thrift side can be changed to make that work.
18:47:29  <bcraig>should I look at existing nasm packages as a starting point? Is there any other (possibly bad) example of dynamically adding <ClCompile> objects at build time?
18:47:41  <FearTheCowboy>no, that doesn't do that.
18:48:15  <FearTheCowboy>it works in a different way (and not easy to understand anyway, I think that it tried too hard)
18:48:58  * FearTheCowboyis considering the fastest way to do this.
18:51:04  <FearTheCowboy>done right, we don't have to make seperate files for this, we can do it entirely in the .autopkg script (since it generates the .props and .targets files, and all the logic can be done in there)
18:52:59  <FearTheCowboy>gimme a couple of minutes, lemme see if I can push of the work that I was doing today, so I can work on this...
18:53:27  <bcraig>I think you are prioritizing this higher than I am :)
18:53:54  <FearTheCowboy>(I needed something that wasn't brain-sucking to work on today)
18:54:06  <bcraig>but I'm glad that I've sparked your interest
18:54:12  <FearTheCowboy>This is a worthy distraction
18:57:09  * piscisaureus_quit (Ping timeout: 248 seconds)
19:41:29  * piscisaureus_joined
20:00:45  <FearTheCowboy>bcraig -> hmm. I seem to have introduced a bug that breaks other things. I may not get back to this today, but let's try to connect next week and see what we can get working.
20:01:20  <bcraig>sure thing. I will be on IRC most of next week as well
21:09:35  * piscisaureus_quit (Ping timeout: 245 seconds)
21:40:48  * vpovirkquit (Remote host closed the connection)
22:21:20  * HamishCquit (Quit: Page closed)
22:45:00  * madewokherdjoined
23:15:48  * bcraigquit (Ping timeout: 240 seconds)
23:27:53  * ender`quit (Quit: I was in the grocery store. I saw a sign that said "pet supplies." So I did. Then I went outside and saw a sign that said "compact cars"...)