While many of the shared Chef cookbooks do build from source, that is not because it is necessarily the best route to get software on the systems. It is often indicative of the "simplest thing that could possibly work (but isn't optimized)," or "the (cookbook) author doesn't have time / resources to maintain a public repository of packages."
The "common practice"(*) is to build and install native packages for your platform, and host them on an internal repository. If you work at a company that is amicable to sharing, contributing those to upstream or using a publicly hosted repository (like Ubuntu PPAs) may be an option too.
The problem with the approach is every major distribution has different opinions on package management, so it all works slightly differently. That's where Jordan Sissel's "fpm" is really handy. While it only works on RPM, DEB and Solaris now, support for other packaging systems is planned. You can further hook fpm into a continuous integration server like Jenkins by calling the fpm command you want from a build step in Jenkins.
Once you have built the package(s) you want to deploy, you'll need to put them in a repository. If you can't share this publicly through a PPA, then I suggest building the package repo host with Chef. If you're using Debian/Ubuntu, reprepro is common for making an apt repository. For RPM/Yum, mrepo is common, though I don't know of a cookbook that sets it up. Then you could use apt or yum cookbooks to set up the repository on your other nodes.
Another route that might be a simpler option is to build the software, tar it up and stick it on an HTTP server your nodes can get to, and then use Bryan Berry's ark cookbook's resource for retrieving and unpacking it.
(*) I say common because I dispise "best" here :)
