views:

79

answers:

3

I'm building a bunch of windows libraries (mostly simple wrappers to compine features from API and third party libraries) to be consumed later by set of applications which have very similar requirements.

Most of libraries are depending from another library and all of them are depending from one common library. This common library contains rather huge amount of header files, which is causing me a problem.

I would like to be able to checkout the libraryA from the version controlling and it to be ready to compile without pulling out libraryCommon or libraryB which the libraryA is depending. The only way I can figure is to copy all the hundreds of headers from common library to all the libraries, but this is kind of ugly solution.

So what is the best way to store "third party" header files into your c++ project? Does something like header library/packages exists?

I'm currently working with Visual Studio 2008, but I would like some more standard C++ solution.

A: 

Say your common library is boost. Then you would install it, e.g., to c:\boost and add c:\boost to the list of directories searched for headers by Visual Studio. Under Unix, you would install the headers in /usr/include (or /usr/local/include) where they are automatically found.

fschmitt
A: 

The details differ a bit for Windows and Linux/Unix environments, but one thing they have in common is that you don't go about copying headers from a 'third party' library into your own project. That is just asking for problems when there is an update of those headers.

If the libraryCommon and libraryB should be considered as externally maintained libraries for which you only get updates when there is a new official release, then the best practice is to install the latest version of those libraries and you tell your compiler in which location the library has installed its headers (In Linux/Unix typically /usr/include or /usr/local/include, in Windows typically wherever you dumped the sources).
If you are supposed to use the very latest version of those libraries from the VCS, then it will be easier to do a check-out of the libraries and tell your compiler where the check-out process placed the header files.

Another reason why the headers from libraryCommon and libraryB are not sufficient is because you will need to link against those libraries when you test if your modifications in libraryA are working as they should.

Bart van Ingen Schenau
+1  A: 

If the libraries are project specific, you will want to install the libraries in a well-known location (/project/$FOO/ or D:\projects\$FOO) and add a version number to the directory because sooner or later you'll end up supporting a development trunk and a couple of older releases that are in production and just need occasional fixes.

So, create:

  • /project/$FOO-1.00
  • /project/$FOO-1.05
  • /project/$FOO-1.80

Then in the makefile for the actual project that uses those libraries, point to the right version to use. DO not use the directory names with the versions when referring to a header from the source code.

Not like this:

#include <$FOO-1.05/base.h>

but like this:

#include <base.h>

Because you don't want to touch all the source code when updating the library.

florin
This still requires me to pull seperatly all those required libraries from the version control. But I like the thing that this tackles the issue with different versions, which was the initial problem I wanted to solve.