00:39:35  * piscisaureus_joined
02:02:03  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
05:08:48  * hanrahatjoined
05:13:08  * hanrahatquit (Ping timeout: 252 seconds)
05:40:43  * madewokherdquit (Remote host closed the connection)
06:17:18  * ender`joined
06:33:57  * Arnavionquit (Quit: Arnavion)
07:07:52  * drdanzjoined
07:15:56  * Arnavionjoined
07:35:08  * cH40z-Lordquit (*.net *.split)
07:35:09  * ender|quit (*.net *.split)
07:35:09  * Arnavionquit (*.net *.split)
07:35:09  * ender`quit (*.net *.split)
07:35:10  * gix-quit (*.net *.split)
07:35:10  * [[zz]]quit (*.net *.split)
07:35:11  * ChanServquit (*.net *.split)
07:35:12  * drdanzquit (*.net *.split)
07:35:12  * FearTheCowboyquit (*.net *.split)
07:35:12  * TReKiEquit (*.net *.split)
07:35:13  * azeno_quit (*.net *.split)
07:35:14  * stalledquit (*.net *.split)
07:35:16  * AtashiConquit (*.net *.split)
07:35:17  * ln-quit (*.net *.split)
07:35:17  * sungamiquit (*.net *.split)
07:37:44  * Arnavionjoined
07:37:44  * drdanzjoined
07:37:44  * ender`joined
07:37:44  * gix-joined
07:37:44  * [[zz]]joined
07:37:44  * AtashiConjoined
07:37:44  * cH40z-Lordjoined
07:37:44  * ln-joined
07:37:44  * azeno_joined
07:37:44  * ender|joined
07:37:44  * FearTheCowboyjoined
07:37:44  * TReKiEjoined
07:37:44  * stalledjoined
07:37:44  * sungamijoined
07:37:44  * ChanServjoined
08:20:52  * Arnavionquit (Quit: Arnavion)
08:22:16  * Arnavionjoined
09:35:03  * Arnavionquit (Quit: Arnavion)
09:35:49  * Arnavionjoined
13:18:55  * theshadowquit (Quit: theshadow)
14:02:04  * theshadowjoined
14:12:36  * johne53joined
14:25:15  <johne53>Arnavion: John Emmas here... we were talking with Garrett a couple of weeks ago (over on #hexchat). You mentioned that you'd built the Gtk stack (which I've also done). But I wondered if you've ever built the C++ modules (glibmm / gtkmm etc). I'm just starting them but they're not easy to build with MSVC :-(
14:27:43  <auroraeosrose>do they need patches for them? build errors? or just hard to get the right config stuff?
14:29:52  * vit122joined
14:35:58  <johne53>auroraeorose: The Git sources contain (almost) no source or header files. They all need to get generated by a macro processor called 'M4' (some old 'Kernighan & Richie' thing). AFAICT there isn't a standalone version of M4 for Windows. I can only get it by installing some other Windows build system, such as Cygwin :-(
14:38:51  <auroraeosrose>....
14:38:59  <auroraeosrose>LOL - you mean autotools
14:39:03  <auroraeosrose>yeah a lot of open sources uses that
14:39:07  <auroraeosrose>use msys
14:39:10  <auroraeosrose>not cygwin
14:39:23  <auroraeosrose>you can put the windows linker and compiler in your path and run ./configure
14:39:36  <auroraeosrose>it'll work - we do that for a lot of projects
14:41:51  <johne53>auroraeorose: Thanks, I figured it'd be something like that. It's just so annoying to have to install one build system, before your preferred build system will work ;-)
14:41:55  <auroraeosrose>you just need autotools and a bash shell - msys will give you that
14:42:00  <auroraeosrose>yeah, I know - nuts
14:42:10  <auroraeosrose>if you can, just commit the generated files
14:42:24  <johne53>auroraeorose: Thanks.
14:42:25  <auroraeosrose>when you're done - to the coapp magic branch ;)
14:42:27  <auroraeosrose>no problem
14:43:28  <auroraeosrose>note - you just need msys, NOT mingw
14:44:04  * vpovirkjoined
14:44:13  <auroraeosrose>I think you may have to tell it what linker to use too, it's been a bit since I've done the nonsense ;)
14:44:47  <auroraeosrose>vpovirk: when you run configure in msys with msvc compiler/linker - you have to tell it what linker correct? it's been awhile ;)
14:45:07  <johne53>auroraeorose: Excellent... I think I already have TDM-GCC installed somewhere (it's a variation on MinGW) but I've never used it for anything.
14:48:24  <FearTheCowboy>Chuckle-of-the-day --- we built the BerkeleyDB package, for the typical pivots... the package file came out to 1.08 GB
14:48:26  <FearTheCowboy>O_O
14:49:10  <FearTheCowboy>I guess that work to split up packages into finer peices is gonna have to come sooner rather than later.
14:50:04  <vpovirk>auroraeosrose: I'm not sure I've ever done that
14:52:05  <auroraeosrose>johne53: errr - yeah... that won't work
14:52:08  <auroraeosrose>;)
14:52:12  <auroraeosrose>unless you want to compile with that
14:52:18  <auroraeosrose>msys is just the tools - bash, autotools, etc
14:52:23  <auroraeosrose>no compiler or anything
14:59:53  <johne53>auroraeorose: I've got a vague feeling that TDM-GCC is some kind of "souped up" version of MinGW (i.e. with MSYS and various other things already included). I'll have to see if I can find it again.
15:08:31  <FearTheCowboy>oh, and FYI, I got parallel building working in PTK now -- we can build projects against multiple compilers/platforms/arches all at the same time :D
15:08:37  <FearTheCowboy>I really gotta document this stuff.
15:09:41  <auroraeosrose>FearTheCowboy: yeah but ptk doesn't run ./configure ;)
15:10:01  <FearTheCowboy>no, it don't. :(
15:10:53  <FearTheCowboy>but, if Rafael would free up a day somwhere, I think we can get the trace -> mkProject stuff working... then you could build it once in mingw/GCC and generate the VCXproj files fromt hat.
15:11:09  <auroraeosrose>that still doesn't fix build systems that use configure to generate code
15:11:13  <auroraeosrose>there are LOT that do that
15:11:19  <auroraeosrose>(I own two)
15:11:25  * auroraeosrosehides
15:11:30  <FearTheCowboy>Yeah, we hates that.
15:12:10  <FearTheCowboy>in the short-to-mid-term, we pretty much have to capture the commands that generate that code and either (a) run them as custom steps in the vc build, or (b) preseve the generated files.
15:13:19  <FearTheCowboy>The other option is to install the GnuWin binaries, which works for some situations
15:13:32  <FearTheCowboy>chocolatey has an install for that. It's not *terrible* ... :S
15:13:41  <FearTheCowboy>hmm. M4 is in there.
15:14:30  <FearTheCowboy>hmm. so is autoconf ... does that stuff acutally work!?
15:14:33  <auroraeosrose>well some of gnuwin32 is on our build list already yes
15:14:36  <auroraeosrose>yes
15:14:50  <auroraeosrose>in fact you can even do non-complicated stuff with gnuwin32 binaries and powershell
15:14:55  * auroraeosrosehas done great evil
15:15:12  <FearTheCowboy>hmm. That's interesting.
15:15:19  <auroraeosrose>and evil
15:16:07  <FearTheCowboy>Well, in the short-to-mid term, I think we're going to take a dependency on chocolatey (at least under-the-covers) as a way to get tools in a standardized way.
15:16:19  <FearTheCowboy>I should add that support in today.
15:16:36  <FearTheCowboy>if I can ever fully wake up.
15:20:06  * azeno_quit (Quit: No Ping reply in 180 seconds.)
15:20:12  * azenojoined
15:21:24  <FearTheCowboy>DERP: http://www.hanselman.com/blog/10NewFeaturesInWindows81PreviewThatSavedMySurfaceRT.aspx
15:22:12  <FearTheCowboy>#1 "BEING ABLE TO USE YOUR DESKTOP WALLPAPER AS YOUR START MENU BACKGROUND" ... uh, really? who cares about the background of the start screen. I mean *really*!?
15:22:22  <auroraeosrose>yo mama!
15:22:27  <FearTheCowboy>Ok, outlook would be nice.
15:22:47  <FearTheCowboy>as for the rest... big-whoop-de-doo.
15:29:57  <vpovirk>how good is outlook at rss?
15:31:01  <FearTheCowboy>Dunno, never really tried it.
15:51:46  <johne53>@FearThecowboy: I was telling out team leader about NuGet / CoApp etc and ke asked me to find out something....
15:52:37  <FearTheCowboy>shoot
15:54:53  <johne53>Great idea to have a FOSS repo available for Windows. It could include apps and libraries, like we all discussed - but what about paid-for s/ware that gets distributed via some kind of installer? How can we prevent if from over-writing DLLs already downloaded (i.e. DLL hell)? Would it be preferable to have a dedicated installer (wix?) which is intelligent enough to get libraries from the repo
15:54:54  <johne53>- so that installers don't need to ship them?
15:56:05  <vpovirk>this is what sxs is for
15:57:08  <johne53>vpovirk: Yes - and it works well for Microsoft DLLs (C runtime etc) but will it work for 3rd party DLLs?
15:57:27  <FearTheCowboy>Yeah, SxS will work for third party stuff perfectly fine.
15:57:34  <vpovirk>3rd party DLL's are more what it's designed for, as I understand it
15:58:02  <vpovirk>it gives each third party a namespace, based on their public key, so they won't conflict with each other
15:58:35  <johne53>vpovirk: @FearTheCowboy: Great, I wasn't sure of that so thought I should flag it up...
15:58:45  <FearTheCowboy>I'm planning on working with WiX over the next year to make this a very simple thing
15:58:58  <FearTheCowboy>so that installers can just reference a common package like that
15:59:22  <FearTheCowboy>and get them at install time (and can get independently updated when necessary)
15:59:41  <FearTheCowboy>it's what CoApp was originally going to be, but we're going to merge all that functionality into WiX itself
15:59:56  <johne53>@FearTheCowboy: Yes, that's exactly what's needed I think.
15:59:59  <FearTheCowboy>so that any application install can use it
16:01:10  <johne53>@FearTheCowboy: I'm still not 100% clear about the difference between NuGet and CoApp. Is CoApp just the overall project name and NuGet is the Repo name?
16:01:13  <FearTheCowboy>I'll likely actually start that work in the fall, over the summer I'm just putting the last tweaks into the NuGet side of stuff
16:01:39  <FearTheCowboy>so, for the immediate term, I wouldn't invest a lot of time into it quite yet.
16:02:15  <vpovirk>nuget is an entirely separate project
16:02:55  <vpovirk>but nuget was originally a package manager for developers to get .NET libraries only
16:03:03  <FearTheCowboy>CoApp and NuGet had some overlaps, so we adapted to get NuGet updated to support native libraries.
16:03:50  <vpovirk>also coapp produces tools for building those native nuget libraries (which as I understand it will also be able to build other things in the future)
16:03:52  <FearTheCowboy>most of the work for that ended up being in the magic of acutally packaging, and the NuGet folks don't really do anything complex there, so I kept the tools for doing this as the "CoApp powershell tools"
16:04:19  * vpovirkshould really just let FearTheCowboy talk about this stuff, but this is more fun
16:04:24  <FearTheCowboy>LOL
16:05:38  <johne53>FearTheCowboy: Is CoApp a prject that's evolving / merging with NuGet to provide support for FOSS libraries?
16:06:05  <FearTheCowboy>Let's put it this way: CoApp was originally going to be a Package Management system, but over the last year, I've come to the realization that we're better off integrating with the popular stuff directly, so CoApp's just becoming a toolset for using those systems, and an effort to bootstrap the repositories
16:06:43  <FearTheCowboy>We'll likely never actually merge the native package building with the nuget stuff -- it's *really* complex and they're not really equipped to maintain it.
16:07:07  <FearTheCowboy>but the packages can be *used* by developers without anything more than NuGet itself
16:07:33  <FearTheCowboy>And, as we go, I keep making more tools/cmdlets for automating native build processes a lot.
16:07:33  <johne53>@FearTheCowboy: and remind me what Chocolatey is? That's something similar from an outside party?
16:08:16  <FearTheCowboy>Chocolatey is a really thin vaneer on top of NuGet that abuses it to make a general purpose package management system
16:08:25  <FearTheCowboy>it's really not that good, but good enough in the short term
16:08:47  <FearTheCowboy>it's a potential security nightmare (so I wouldn't really recommend it for non-techies)
16:08:54  * theshadowquit (Ping timeout: 240 seconds)
16:08:54  * theshado_joined
16:09:02  <FearTheCowboy>and its codebase is a ratsnest of pain and suffering.
16:09:11  <FearTheCowboy>but it works... mostly.
16:09:23  <FearTheCowboy>http://chocolatey.org/
16:09:51  <FearTheCowboy>at its heart, it's just a way of automating installs of stuff, not a true package management system
16:10:25  <FearTheCowboy>When we get package support added to WiX, chocolatey will be an awful lot less useful.
16:12:00  <johne53>@FearTheCowboy: So, let's suppose I (and Arnavion) have produced some GNU libraries, how do we co-ordinate it all so you can add them to where..? NuGet?
16:13:54  <FearTheCowboy>The best way to handle this is to adapt the build process that you have to the one that the CoApp tools can use (which isn't well documented at this point)... which allows us to trivially build the same library for many different variations (and combinations of variations) ... think VC12, VC11, VC10 * Release, Debug * static, dynamic * X64, X86 ...
16:14:36  <FearTheCowboy>I have a cmdlet that can take a typical VCXPROJ file and generate a new one that can be built against all combinations of variations with a single command
16:14:53  <FearTheCowboy>(the invoke-build cmdlet -- what we often call 'ptk' )
16:15:51  <FearTheCowboy>once I catch up on the stuff I'm trying to get past, I'll work with you guys to get this done.
16:16:56  <FearTheCowboy>from there, it becomes much easier to maintain this stuff, each library can be built, packaged and published independently in a reliable fashion
16:16:57  <johne53>@FearTheCowboy: Yes, it's coming back to me now. I'm currently using VS2005 which was too old to accommodate any of this but with my MSDN subscription, that should get solved now.
16:17:09  <FearTheCowboy>indeed.
16:17:48  <johne53>@FearTheCowboy: I guess your main task is to produce at least _some_ documentation as a starting point for us.
16:19:30  <FearTheCowboy>Yeah. I have a couple more scripts I need to finish up (mainly making it so that some tools can be installed in a standardized way) and then I can start working with you to do this. It's gonna be a bootstrap-levitation process where I generate the docs as I work thru this stuff with you guys as an example
16:21:21  <FearTheCowboy>the goal is to get it simple enough that you can go to a fresh machine with a minimal set of stuff installed (VS, git and the CoApp tools) and do a simple 'git clone ...' and 'invoke-build ...' for a given project, and that should work.
16:26:06  <johne53>@FearTheCowboy: Great. We probably need to decide also on some kind of standardised naming scheme for the DLLs etc - and probably even some standardised build settings. I'ts going to get very confused if I build with certain settings enabled while Arnavion usually has them disabled (or whatever).
16:27:55  <johne53>@FearTheCowboy: For example, because building a fully optimized Release project can be very time consuing, I tend to build 3 x build targets for our projects:- 1) Debug, 2) Release and 3) "Debuggable Release (unoptimized)
16:28:59  <FearTheCowboy>So, we've come up with a set of patterns for that ... we try to keep all the DLL and LIB files the same name, and generate into unique paths that have all the variations in them
16:29:33  <FearTheCowboy>this way, it's WAAAAY simpler to make it so that consuming developers don't have to futz with things to consume a library (or change their mind how they consume it)
16:30:32  <FearTheCowboy>the build settings are generally constrained to a set of common files (so that *everything* we build is built in a similar fashion)
16:30:52  <FearTheCowboy>and developers are doing accidental one-off changes on a given build (which really, is not a good idea)
16:31:43  <FearTheCowboy>this also makes it easy to simplfiy the hell out of the actual VCXPRoj files that each project has
16:31:52  <vpovirk>do optimizations really get in the way of debugging?
16:32:07  <vpovirk>somehow I thought that wasn't the case anymore
16:32:43  <johne53>vpovirk: It always seems to for me (although I'm currently using VC2005)
16:32:46  <FearTheCowboy>aggressive optimizations *can* (PGO-style stuff) ... and even regular optimizations can make it so some things aren't inspectable.
16:33:44  <FearTheCowboy>but generally, a decent DEBUG build should suffice. (which should be very close to what people call "debuggable release")
16:35:17  <johne53>@FearTheCowboy: It's extremely rare for us to need the Debuggable Release version - but there are very rare occasions where a bug exhibits itself in the Release build but not in the Debug build.
16:35:38  <FearTheCowboy>johne53 -> this is an example of one of our VCXProj files: https://github.com/coapp-packages/freeglut/blob/master/COPKG/freeglut.vcxproj
16:35:56  <FearTheCowboy>I'd argue that they DEBUG build should be more like the "debuggable release" build then :D
16:39:11  <johne53>@FearTheCowboy: Rmember too that GUN libraries tend to have a LOT of auto-generated stuff. If you're auto-generating for every build, the projects are permanently out of date (i.e. building a Debug target makes the Release target out of date and vice-versa). So we put all that auto-generation stuff into the Debuggable Release target (which we only rarely need to build). It saves a lot of
16:39:11  <johne53>unneccessary rebuilding!
16:39:34  <johne53>GNU, not GUN ;)
16:40:04  <vpovirk>we'd probably put those in the intermediate directory, or outside the vcxproj entirely
16:40:55  <vpovirk>but even if you're not using coapp tools, it seems like you'd be better off with a separate project for them
16:43:02  <johne53>vpovirk: Possibly - but the nice thing about it is that we almost have a 'one click' build solution for the whole GTK+ stack. Absolutely everything gets built, even the files that need to get auto-generated. It's pretty neat.
16:44:03  <FearTheCowboy>The one-click is kinda nice, except that encourages tighter dependencies than are sometimes necessary
16:44:16  <johne53>@FearTheCowboy: Your vcxproj doesn't look too bad. I've never needed to use one before now.
16:44:43  <FearTheCowboy>when each item is independently 'one-click' (or at close to it), doing a whole stack is kinda trivial
16:44:55  <vpovirk>how is that different from a project that depends on another project?
16:45:11  <johne53>@FearTheCowboy: Yes. The tighter dependencies are helpful to us but probably not so good for what you want.
16:46:23  <FearTheCowboy>Still, having a gtk-stack meta-project is trivial to do, and would get you exactly the same thing (and allow you to build and publish *all* the variations of everything in a one-click fashion)
16:46:40  <FearTheCowboy>of course, it might take a day or two to build it all :D
16:47:30  <johne53>vpovirk: What's nice about it is that we don't need to leave Visual Studio. Everthing gets built automatically. It's appealing for us.
16:48:08  <vpovirk>well, sure, but you wouldn't anyway
16:48:18  <vpovirk>as long as all relevant projects are in the same solution
16:49:32  <johne53>vpovirk: Yes, we just have one solution with a long chain of dependent projects.
16:49:46  <FearTheCowboy>our vcxproj files are buildable from VS still. But I do have a todo to generate a .sln file.
16:50:31  <FearTheCowboy>having a mega-solution can be awful handy for a ton of developers
16:50:54  <johne53>I've never used a vcxproj file so far. I'll have to do some reading about them.
16:52:01  <FearTheCowboy>well, you've used vcproj files in VS2005 - this is the evolution of that stuff (evolved to be common for all MS languages)
16:52:03  <johne53>@FearTheCowboy: Yes. I live in Manchester (UK) but all the other devs are in USA (and are mostly non-Windows users) so I try to simplify everything for them.
16:53:43  <johne53>I know the pain of having to build all this stuff on Linux, which I'm not familiar with - so a simple solution is really good for us!
16:57:54  <FearTheCowboy>Hmm. I think I can do a generator for a mega-sln file. We can may have to add a couple lines into our common vcxproj stuff to pick up sibling-libraries from the build location instead of the nuget-package path, but shouldn't be terribly difficult.
16:58:44  <FearTheCowboy>I think I can even make it so that all the variations show up as different configurations in the configuration manager.
16:59:11  <FearTheCowboy>pity that could be 30+ configurations, but at least you could trivially pick one and build.
16:59:22  <johne53>@FearTheCowboy: Neat!
17:00:33  <FearTheCowboy>the hardest problem is actually that crappy SLN format, wihch isn't well structured, and breaks at the slightest issues. (silly VS people :p)
17:00:57  <FearTheCowboy>and I don't believe there is any programatic code for manipulating them
17:00:58  * theshado_quit (Quit: theshado_)
17:02:40  <johne53>@FearTheCowboy: Yes, I've noticed that! BTW - did you say that current VS offerings (VC12 etc) can build a project as if it had been built with an earlier compiler or did I imagine that? i.e. would it be necessary to have all the different compilers available to build all the different versions?
17:03:37  <FearTheCowboy>You need to have the earlier VC versions installed, but once you do, it's just a configuration change to support older compilers
17:03:51  <FearTheCowboy>you don't have to change IDEs or anything
17:04:30  <FearTheCowboy>(although they hide it in the properties window -- it's called 'PlatformToolset'
17:05:09  <FearTheCowboy>oh, and MS didn't actually include the support for VC 6,7,8 -- you need to install the stuff from http://daffodil.codeplex.com
17:05:14  * theshadowjoined
17:05:17  * theshadowquit (Max SendQ exceeded)
17:05:19  <FearTheCowboy>I think I'm going to include that in the coapp tools tho'
17:05:20  <FearTheCowboy>soon
17:05:54  * theshadowjoined
17:05:58  <Arnavion><johne53> Arnavion: John Emmas here... we were talking with Garrett a couple of weeks ago (over on #hexchat). You mentioned that you'd built the Gtk stack (which I've also done). But I wondered if you've ever built the C++ modules (glibmm / gtkmm etc). I'm just starting them but they're not easy to build with MSVC :-(
17:06:02  <Arnavion>Nope
17:06:12  <Arnavion>HC is entirely C
17:07:09  <Arnavion>Also in the last few days new versions of things came out
17:07:11  <Arnavion>https://github.com/hexchat/gtk-win32/issues/10
17:07:13  <Arnavion>Fun~
17:08:46  <johne53>Arnavion: Is hexchat an IRC client? I use mIRC at the moment but I don't like it much.
17:08:56  <Arnavion>Yes
17:08:59  <FearTheCowboy>Hmm. there's a codeplex project that can generate sln files.
17:09:14  <Arnavion>Why do you need to generate sln files?
17:09:35  <Arnavion>Here at SQL we just write a dirs.proj that includes all the .*proj we want and open that
17:09:51  <Arnavion>because VS has the weird behavior of where it doesn't build references dependency projects if they're not in the solution
17:09:58  <Arnavion>referenced*
17:10:21  <johne53>Arnavion: Will it 'beep' me if someone replies with my name? mIRC does do that - but only when it feels like it :-(
17:10:30  <Arnavion>Yes
17:10:47  <Arnavion>The only feature it doesn't have from mIRC is the existence of a retarded scripting language
17:10:48  <johne53>Arnavion: Hmmm... I might try it.
17:13:48  <FearTheCowboy>Arnavion -> one of the things I want to do is make it trivial for devs to build any variation (platform/linkage/platformatoolset/debugrelease/etc) from the IDE that we can build from the command line
17:14:21  <Arnavion>FearTheCowboy: Yes, and you can do the same thing with an overarching .proj file that references all the projects you want to build
17:16:09  <FearTheCowboy>you have an example of one? Does it just have a ton of <ProjectReference> nodes in it?
17:16:45  <Arnavion>Yes
17:16:46  <FearTheCowboy>when dependent projects build, what are they using for $(SolutionDir) ?
17:17:17  * FearTheCowboywishes that VS would have thrown out SLN files years ago...
17:18:40  <Arnavion>I figure for SolutionDir they probably use the most common part of root of all the projects
17:18:55  <vpovirk>I'm not sure if I understand the use case for a solution builder
17:19:15  <Arnavion>So if you have C:\foo\one\one.vcxproj and C:\foo\two\two.vcxproj, the SolutionDir would be the most common part of the two ProjectDir's - C:\Foo
17:19:34  <Arnavion>That's how it looks like when you open the combined project too
17:20:03  <Arnavion>Instead of having all the projects at the top level (like with opening sln files), they appear under a directory hierarchy
17:20:41  <FearTheCowboy>Are you hand-making those?
17:20:51  <Arnavion>Yes
17:21:12  <Arnavion>They're called dirs.proj by convention and they're regular msbuild projects
17:21:13  <Arnavion><Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
17:21:20  <Arnavion>Then an <ItemGroup>
17:21:23  <vpovirk>I'm concerned that any information in .buildinfo about non-msbuild steps would have to be duplicated
17:21:29  <Arnavion>Inside that, all the <ProjectReference> that are needed
17:21:51  <FearTheCowboy>hmm. that does sound a bit less silly
17:21:55  <Arnavion>Any common <Import> for props files before and after the ItemGroup
17:22:46  <FearTheCowboy>So, properties from the top-level get propogated down to the Referenced projects? Hmmm.
17:22:54  <Arnavion>Yes
17:23:11  <FearTheCowboy>vpovirk -> the .buildinfo would be the source of the generated sln, but perhaps not even needed at all.
17:23:28  * FearTheCowboynow has to go and twiddle with this.
17:23:50  <vpovirk>:|
17:23:59  <Arnavion>You only need the dirs.proj thing if your projects don't have dependencies between them
17:24:16  <vpovirk>this seems completely out of coapp's scope to me
17:24:17  <Arnavion>If one.vcxproj and two.vcxproj have nothing in common, then you need a dirs.proj to be able to open both of them
17:24:34  <Arnavion>But if one.vcxproj already has a ProjectReference to two.vcxproj, then you don't need a dirs.proj
17:24:50  <Arnavion>Just open one.vcxproj directly. It'll open two.vcxproj in the same solution
17:25:10  <Arnavion>So I think the problem you're trying to solve doesn't even exist in the first place
17:25:45  <vpovirk>VS isn't going to do a good job of editing our vcxproj files
17:25:50  <FearTheCowboy>We haven't use Project References between projects at all, since we tend to build projects atomically and then reference the generated package
17:26:10  <Arnavion>I see
17:26:22  <vpovirk>so at best you'll end up with the equivalent of ptk but selecting only one target and via a gui
17:27:02  <FearTheCowboy>vpovirk -> pretty much. which can be good if you're actually working on the project instead of just packaging it (like we do...)
17:27:13  <vpovirk>if people only want a few types of builds, they don't need to be using our tools
17:27:48  <FearTheCowboy>No, but if we encourage people to drop the lousy vcxproj files and just use ours, they're gonna want to do the things they are used to.
17:28:17  <Arnavion>At SQL we all know not to modify the projects from within VS
17:28:19  <Arnavion>We do it by hand
17:28:20  <FearTheCowboy>LOL
17:28:32  <FearTheCowboy>generally speaking, that's good policy :D
17:28:33  <vpovirk>and it's not our job to add features (like ability to switch between static/dynamic easily) that the VS people don't think are necessary
17:28:35  <Arnavion>Yep
17:29:15  <vpovirk>let the VS authors fix VS
17:29:24  <FearTheCowboy>vpovirk -> that's really not the big deal. Just making it easy to build whatever they are working on from the IDE is
17:29:38  <Arnavion>At any rate, even if someone does modify the VS project
17:29:40  <FearTheCowboy>I'm not trying to fix anything. Just make sure that they can open up and start working.
17:29:47  <Arnavion>The VS project doesn't matter, does it? Only the .buildinfo does?
17:29:51  <Arnavion>So what's the problem?
17:30:08  <vpovirk>who is going to use our vcxproj template and want to do this?
17:31:53  <vpovirk>for consuming them, you can use a nuget package, and for editing them you're not going to get good results from VS
17:32:02  <FearTheCowboy>If I'm an active developer on zlib, I'm going to want to work from the IDE.
17:32:32  <FearTheCowboy>I'm not saying they are going to edit the vcxproj file in VS (which still works, btw), but they are going to want to compile, debug and run from there.
17:32:40  <Arnavion>That doesn't work now?
17:33:01  <FearTheCowboy>For an individual project, sure.
17:33:32  <FearTheCowboy>for one that depends on another, right *now*, you have to have project A generate the .nupkg file and project B update their reference to that
17:34:18  <FearTheCowboy>Ideally if I'm working on two related projects, it'd be kinda nice to open up VS and make changes where needed, and hit compile and have it do the right thing.
17:35:03  <FearTheCowboy>Like I said, we don't have any inter *project* references right now, just project -> package dependencies.
17:35:04  <Arnavion>So you want to be able to second-guess whether the user wants to build dependency projects or whether they want to use the DLL off nuget?
17:35:05  <vpovirk>by "projects" do you mean vcxproj files, or repos?
17:35:40  <FearTheCowboy>Arnavion -> yes. ( :D ) .. I'd like them to have the option of doing what they'd like
17:36:05  <Arnavion>So make it an option for the .buildinfo -> vcxproj file generator
17:36:15  <Arnavion>They'll have to be conscious of it the first time
17:36:25  <FearTheCowboy>vpovirk -> technically, both. freeglut has like 10 vcxproj files that are bound by the buildinfo. but nothing right now inside of VS
17:36:28  <Arnavion>and they can't mix and match
17:36:45  <FearTheCowboy>Arnavion -> that's pretty much what I'm thinking.
17:36:45  <Arnavion>Alternatively generate two vcxproj files, one for sources builds and one for nuget DLLs builds
17:36:53  <Arnavion>Let the user decide which
17:37:06  <Arnavion>which they want to use*
17:37:18  <FearTheCowboy>Arnavion -> they can be the same file, the common files can use properties to drive which way they want it.
17:37:42  <Arnavion>How would they set those properties from within VS?
17:37:43  <vpovirk>I just don't think we have the information to do this without manual intervention that's required anyway
17:38:56  <FearTheCowboy>Arnavion -> We already generate .xml files that populate settings in the VC properties window, this could be done for dependency library source selection
17:39:08  <Arnavion>Ah
17:39:12  <Arnavion>That would work
17:39:19  <vpovirk>how do you know when to remove a dependency on a nuget package, in favor of a dep on another project and a properties file that (afaik) would have to be generated based on the autopkg file?
17:39:51  <Arnavion>vpovirk: That is what he said. He'll give a setting in the properties window in VS to toggle that
17:40:36  <FearTheCowboy>oddly enough I have this EXACT same problem right now with the coapp tools. I have the clrplus libraries built seperately in a seperate sln than the coapp.powershell project
17:40:58  <FearTheCowboy>I had to manually tweak the coapp.powershell project to peek next door for outputs first.
17:41:02  <vpovirk>but you couldn't add new projects from within the VS gui
17:41:10  <FearTheCowboy>it's still a bit glitchy.
17:41:20  <vpovirk>you'd need some sort of generator to actually add the dependent projects
17:41:47  <FearTheCowboy>vpovirk -> Yeah. Ideally.
17:42:35  <Arnavion>It's a matter of replacing all the <Reference Nuget-sourced DLL /> with <ProjectReference path to downloaded project />
17:42:46  <vpovirk>ideally, VS would understand all of our stuff and have a wonderful gui built around it, and also any features not specific to us would just be merged into it
17:43:43  <vpovirk>what you're talking about can never be described as "ideal"
17:43:50  <FearTheCowboy>Arnavion -> ideally. except native references are handled implemented as <Import>ed .targets and .props files that are found in the packages directory
17:44:12  <FearTheCowboy>I'm gonna go talk with the VS/VC folks about some of this stuff soon anyway... there are some issues with building store apps that pull in libraries that I don't think anyone has thought thru all the way.
17:45:06  <Arnavion>By the way
17:45:16  <FearTheCowboy>I've actually been considering altering the <Import>'d .targets files to do a <ProjectReference> to a synthetic project
17:45:25  <Arnavion>What's the status of this .buildinfo -> vcxproj generator?
17:45:31  <Arnavion>It's not functional right now?
17:46:12  <vpovirk>the status is that he just made it up, which (I'm hoping) means it doesn't have to ever really be built
17:46:36  <Arnavion>Huh? Why?
17:46:42  <FearTheCowboy>the vcxproj generation (harvesting from old vcxproj files) works, and binding them together with .buildifo works
17:46:52  * drdanzquit (Read error: Connection reset by peer)
17:47:27  <FearTheCowboy>I added support to parallel build variations this week, and we tested it by building BerkeleyDB in all its flavors
17:47:47  <vpovirk>I don't want it taking up time that could be spent on other things
17:48:02  <FearTheCowboy>It built just fine... but produced a (compressed) 1.08gb package (3+ gb uncompressed)
17:48:43  * johne53quit
17:49:02  <FearTheCowboy>I want to add the stuff to buildinfo to specify the required tools and automate the dependent libraries (since that's still a bit manual) and I think we're ready to try and start working on gtk
17:49:46  <vpovirk>I thought we were already ready to try to build anything and package any library
17:50:33  <FearTheCowboy>vpovirk -> we *can* but if you're missing tools we don't have a way to get them consistently. (this is a tiny thing, really...)
17:50:59  <FearTheCowboy>I'm also writing a DCR to change the generator to split up the redistributables of a nuget package to finer grained packages, since NuGet can't practically handle stuff over 200mb-ish
17:51:19  <FearTheCowboy>But I won't get to coding that till after July 15th
17:53:26  <FearTheCowboy>I'm still making the spec for that.
17:53:57  <FearTheCowboy>but that won't affect any of the .buildinfo or .autopkg source files, just what gets generated.
17:55:02  <FearTheCowboy>and If I can squeeze in some fix to support libraries for store apps (where they have items they want in the Toolbox), I think I'll make some more friends. I just can't find any docs on any of that tho'
17:55:38  <FearTheCowboy>I don't think they made that work right except with ExtensionSDKs (which suck, and they *know* they suck...)
17:57:36  * stalledquit (Ping timeout: 260 seconds)
18:11:25  * stalledjoined
18:13:53  * jgmdevjoined
19:22:53  * cH40z-Lordquit (Quit: Wenn 2 im Raum sind, 3 raus gehen, dann muss einer zur├╝ckkommen, dass keiner mehr da ist.)
20:25:17  * drdanzjoined
20:32:44  * drdanzquit (Read error: Connection reset by peer)
20:34:38  * drdanzjoined
20:51:59  * vit122quit (Remote host closed the connection)
21:03:34  * theshadowquit (Ping timeout: 240 seconds)
21:19:01  * vit122joined
21:32:55  * drdanzquit (Remote host closed the connection)
21:38:25  * [[zzz]]joined
21:38:55  * cH40z-Lordjoined
21:40:42  * vpovirkquit (Remote host closed the connection)
21:41:54  * [[zz]]quit (Ping timeout: 240 seconds)
21:52:05  * theshadowjoined
22:00:46  * ender`quit (Quit: #define sizeof(x) ((rand() % 100 == 42) ? sizeof(x)-1 : sizeof(x)))
22:11:08  * madewokherdjoined
22:15:18  * drdanzjoined
22:16:23  * drdanzquit (Remote host closed the connection)
22:18:22  * drdanzjoined
22:19:18  * drdanzquit (Remote host closed the connection)
22:20:01  * drdanzjoined
22:20:10  * drdanzquit (Read error: Connection reset by peer)
22:22:01  * drdanzjoined
22:40:30  * drdanzquit (Remote host closed the connection)
22:42:25  * drdanzjoined
22:47:27  * drdanzquit (Remote host closed the connection)
22:49:30  * drdanzjoined
22:49:39  * drdanzquit (Read error: Connection reset by peer)