Do not store the output of a build in your version control system along with your code. Period. If you work on an interesting product, it is bound to be comprised of multiple components that all fit together in interesting and complex ways. For reasons you may have had no say in, some of those components are built and checked into the source code for use in building a larger product. Do not do this. It will bite you in the end.
First, you have the problem of interfaces. These components interact with the large product through an interface of some sort. Since you’re building the component and the larger product you control that interface. But if a developer has to build the component and check it in for it to be included in the larger product you can get into situations where the interface changes, but the component hasn’t been updated. Oh sure, you can setup rules that remind developers to rebuild and checkin a component if it’s interface changes, but now your developers just have one more thing to remember - and they will forget. Do not do this. It will bite you in the end.
Second, you have the problem of repository size. True, this isn’t as much of an issue for a CVCS such as Subversion. But for a DVCS, which you should be using to store your code anyway, this can cause problems over time. And if you’re patting yourself on the back for using a CVCS, just wait, you’ll come around eventually. And when you do, you’ll care about the size of your whole repository, not just a single revision. Cloning large repositories, made large by many large binary checkins, can take large amounts of time. Do not do this. It will bite you in the end.
Finally, you have the problem of build processes. Because of the need for built binaries to create your entire product, it only makes sense to checkin the binaries for a component once they’ve been built. But now your build scripts are doing more than just building. And you need to make sure the scripts aren’t checking in the binaries each time a developer runs the build on his or her box. And if you have a single script that actually builds the entire product, it is either lying (i.e. you still need to build and checkin the component first), or it’s doing more work than it need to (i.e. you are building the component, checking it into source, then checking it out again). Do not do this. It will bite you in the end.
So what do you need to do to solve this problem? First, make sure your build scripts are doing more work than they need to - build all components, checkin, checkout. Then, remove the checkin/checkout steps.
Of course, this does raise some issues. Now developers who could blithely ignore the component in question will need to make sure they have the code for it, so the build scripts will be able to operate correctly. If you’re doing daily builds, and storing the built files, you can optimize your build scripts in development environments to grab the built components from storage if they don’t have the code. This will work fine for developers who don’t change the interface between the two components. Developers who do change the interface will need the code for the component anyway. And of course, if it builds quickly, all developers can just clone the code and build it.