What is the best way to organize my C project code and its external libraries? [closed]

Question

I'm starting a new C project, which is largely OSS-based. It'll also be on SourceForge, and I'd like to take this opportunity to learn established best practices for organizing this kind of code. I'm using libraries like libcurl and libz, and I'll compile it using MinGW and MSYS.

I'll be distributing copies the source of all libraries I'm using with my projet, so people downloading the source won't have to go peck and hunt for dependencies. What should I call the directory I store the libraries in? So far, I hesitate between:

• lib, because they are libraries. However, 'lib' has a different connotation in UNIX-world.
• src, because they are source files.
• 3rdparty, because I didn't write it.

And where should I compile these libraries to? Should I simply configure and install them to the system root, or should I set up a directory where all libraries should compile to, and link from there? Obviously, this will have ramifications for my Makefile.

How should I go about this? Are there established conventions that I should follow? Are they written down somewhere?

Answer 1

First, for external libraries I would use vendor, but that's just a preference.

Second, I don't think it is a good idea to install other libraries in a system root, without the users knowledge. Most importantly because this will conflict with later installed versions of those libraries. So I think the best place for these libraries would be in the same directory as your application.

You could also statically compile these libraries into your program.

Answer 2

At a previous job, the standard was to install them in a directory named 3rdparty and build the libraries right there (in 3rdparty/LIBNAME/Debug, etc.).

Answer 3

We use something with the _ext or _EXT suffix (i.e MyProject_EXT) to signify that it is external to our project to store the source code of external packages that we link against.

I agree with Peter. The external libraries should be not be built into the system root as they may cause conflicts. I'd build them in their directory and then install them into a /lib directory (or maybe /extlib) that is unique to your application and link to them there.

Answer 4

Please don't ship third party sources with your code, either in the source or linked statically into the binaries, or any other way. That will just interfere with other copies of the same, and won't get updated when the library requires fixing. Do tell the user what the requirements are (and keep up with API changes in the library!). A self-compiling user will make sure to get the dependencies, a distribution will make sure your package works with the version that they ship.