In the latest release, I've reorganized the way we ship source code for our clients, so I that while the "what" is contained in the documentation, the "why" would make for a perfect inaugural blog post. Shipping Granny presents some interesting challenges. As of this moment, Granny ships for 9 different platforms, and we have legacy support for several more. (Xbox, GameCube, etc.) In addition, every version of Granny ships with out of the box support for 28 different versions of Max, Maya, and XSI.
None of that would be too onerous, but one of the selling points of Granny is that we give you full access to the source code, allowing you to customize our code at any level. So we have to ship all of this in way that at gives our clients a way to build each platform.
For most products, we could simply give you a copy of our own source tree, along with a Visual Studio project, and call it done. That won't work for Granny. Since we have to build for Linux, MacOSX, and some console platforms that don't have native VS integration, we use a custom build system in order to support all of our platforms from a single build environment. The list of files included for each platform/processor combination we support is determined automatically (so we can't screw it up!), and routed to the appropriate build tool from the command-line. So we can't just hand your our VCPROJ files; we don't have any!
Up until very recently, the solution to this problem was simply to take that dynamically determined list of files, and dump it into the "source" directory of each platform. This has a couple of very nice points. First, you don't have any files you don't need for that version of Granny. Second, you can simply drag all of those files into your own projects, and you're ready to go! You don't have anything you don't need, and you aren't missing anything that you require.
That's worked well, but in the last few years, there's been a shift in the way most of our client ship. It's become far more common for Granny customers to be supporting 2 or 3 platforms, and we've been hearing comments that the "one source directory per platform" layout leaves customers with a bad choice. Either they can combine platform source directories, in which case they no longer have a clean list of files required for each platform, or they can leave them separate, which makes it difficult to manage modifications across platforms.
So: new layout! I've modified the build system to create source trees rather than flat source directories now. There will still be a "source" directory in each distribution, but any platform or application specific files will now be contained in subdirectories. Now when you copy source distributions on top of each other, file collisions are only possible between identical files, and specific platform files will be kept separate in their own subdirectory. This lets you share modifications across platforms, while still making it possible to determine exactly which files you need to build a specific version of the runtime, or the exporter.