An interesting thing with our build environment is that since we're compiling as kernel modules, your robot program is actually its own dynamic library (as opposed to a static *.a library).
My development pattern is that I tend to make a lot of little projects to test various things, and setting up linkage to a set of libraries each time would get annoying. So instead of setting up a static library, I compile it as a regular project, and then FTP the object file (*.out) to the robot and edit ni-rt.ini to load the library before it loads FRC_UserProgram.out. Then my installation program for the library copies the header files to the wind river include directory, and I just include the header files and it all magically works.
The other reasoning for this is that my library uses boost, and setting up that is a pain, so I'd rather just have a quick installer that installs the relevant header files and object files on our other development computers instead of trying to do it on each machine.
Of course, if your library changes a lot, then this is a bad approach. Its more suited to something that you are going to redistribute to other teams. See my project website for more information:
http://code.google.com/p/webdma/