Hey all,
I am currently experimenting with different ideas on how to structure my project. It will most probably become a big project with a lot of LoC. So I thought it would be nice if I could structure it logically and cut down compile time at the same time. My project basically consists of a reusable part I want to put into a shared library and a specific program. What I want to do is split the shared library into several static libraries which I can compile individually. Since I use CLion I put every lib into its own project (separate (c)make-files etc.)
This is my first Linux project of this kind, so I am unsure if this is the best option as debugging might become difficult (I do not yet know the full capabilities of GDB + CLion). Maybe someone could enlighten me, send me into the right direction, give me good links,...?
liba.a ┐
libb.a ┼─> libshared.so ─> myapp
libc.a ┘
UPDATE
So I just built a structure as described above and I can debug everything. Very nice!
PrasannaKumar Muralidharan
Kernel developer @ Witworks
I think always put things separated is better, i don't know if this in c is different but if you are planning to reuse more of the work and the usability i think the best is separate and win :)
Keep things separated as it helps in increasing the modularity and force to write good code. Compile time should not be a problem as make only compiles files that have changed.
Tips: Use clang to get faster compile time than gcc and better error/warning messages.
Use clang static analyser for catching bugs that are noticeable easily.
Use thread sanitizer and memory sanitizer to find difficult to diagnose runtime memory errors and race conditions.
If you don't have a compelling reason to use static library then stick to using shared library. If you library is going to be used by several application using shared libraries will help reducing overall system memory usage, faster app load time. Static library does not let your app get all improvements Linux kernel could provide.