Years ago, in our 100+ coder company I kept finding copies of Microsoft's Developer CDs in CVS. Everything to set up a build machine was in there.
Furthermore, because developers sometimes didn't all have the same build environments, all of the intermediate builds were also checked in since you couldn't assume your machine would build exactly the same executable code as anyone else's machine.
CVS was definitely not built for this, but it worked. And if it works, and a programmer thinks it solves his problem, it will be used.
I discovered this because we kept getting problems with orphaned CVS locks, and people complaining of the slow checkins (CVS did the diff on the server, so upload the slow way over your ADSL line all those giant files that didn't change.) Which led to the day I typo'd a lock removal command and deleted all files with "rfl" in their name. Not a common sequence, unless your software deals with "overfly"s. Hurray for backups!
On the other hand, it's not entirely clear that you should include all that stuff inside a source control repository. This is something I've grappled with myself, in a number of contexts, and I don't have any great answers. In fact, I've usually just done what you do.
Still, given the time and incentives to really do it right, I think a better solution would involve keeping metadata versioned, and storing large binary files extra-repo. Within your repo, you'd have a file or a set of files that indicate that the tools you're using to build/test/deploy/etc are all contained within one or more uniquely identifiable tarballs. Your build process would have a way to extract the contents of those tarballs, if necessary.
No. For long-life projects I snapshot entire build systems (toolsets, documentation, you name it) so that a precise image can be re-created later.