EDIT: Answer is assuming you are asking from a software engineering point-of-view.
Having a library file separate from your application code represents a best practice approach. Aside from static and dynamic linking of library files and applications, your library file should house logically / semantically related code. This structuring "componentizes" your code into reusable pieces of software, which can be fed into other libraries and applications. This practice promotes loose coupling and is a preferred method of design and implementation of software.
With a single project approach, you will still have the same object files that are compiled when needed (as in the separate library approach). Only those files altered will have their object files re-generated accordingly. However, you will still end up with an entirely new library / application file.
As an example benefit of using the first approach (number 1), you can layer a separate "test" library to unit-test your standalone library, all while not having to re-include or re-build your standalone library. You exercise the standalone library while making the modifications to your test library (e.g., adding, modifying, deleting unit-tests).
Hope this helps!