16

I contribute to a decent-sized C++ project with a number of dependencies. The problem is, the project contains the source of all of its dependencies (e.g. pcre, zlib, etc.). I want to trim the project down to just what's relevant to the program itself. Is there some relatively standard way to compile these libraries and put them somewhere, and have their header files also easily accessible?

For what it's worth, I'm using Windows 7, and I'm developing using VS2005. I'm also a complete noob with working on large C++ projects on Windows; I've never really needed to step outside the standard library and win32.

Twisol
  • 2,762
  • 1
  • 17
  • 17
  • 5
    This comment won't be that helpful, so I won't give it as an answer. Linux/etc has this more figured out. There are src, lib, bin, include, and other standard directory names. When you write a library under Windows, you place your library's headers, source, etc wherever you feel like putting them, and expect the world to conform to you. Some of the libraries you mentioned are available under Linux, so probably use the standard directory scheme – Merlyn Morgan-Graham Aug 31 '10 at 01:47
  • Hmm... That's a good point. I imagine the compiled libraries go in lib and/or bin (depending on DLL/LIB-ness), and the application code goes in src? I like that. – Twisol Aug 31 '10 at 01:57
  • 3
    @Merlyn: I find it funny that Linux has standard places to put C libraries and include files, but no standard place where *binaries* are stored. Gah! +1 to comment. – Billy ONeal Aug 31 '10 at 03:02

3 Answers3

10

A structure that we use on my workplace is having one "External" folder that contains an "Include" and a "Lib" folder for the headers and external Libs. However, as we also use VS, we try to use its "Dependencies" feature as most as possible, removing manual inputs to the linker. That means only projects that are not under the same solution goes to the "External" folder. Also, as we have some third-party libraries specific to some projects, we create folders inside the project folder for these includes and libs. This is how it gets:

.\
|-Project1\ --> contains Project1.vcproj
|-Project2\ --> contains Project2.vcproj
| |-Third-Party\
|   |-Include\
|   |-Lib\
|-External\
| |-Include\
| |-Lib\
|-InternalLibrary\ --> contains InternalLibrary.vcproj
|-Solution.sln --> includes the vcproj's and link them as necessary by its dependencies

I can't tell if this is the best structure ever, but everything is under source control, we can do night builds just by building the solution, and development goes by building single projects.

korbes
  • 1,273
  • 1
  • 12
  • 18
1

There's a fallacy in your statement: "I want to trim the project down to just what's relevant to the program itself."

Believe me, the dependencies are extremely relevant to the program. If you don't have these in source control then you will encounter no end of problems when introducing new team members or when switching to a new workstation.

Even if compile the "non-relevant" libraries, these compiled libraries should go into your source repository.

Andrew Shepherd
  • 44,254
  • 30
  • 139
  • 205
  • Alright... I should have said "application-specific code". I get your point, though. But what's the best way to structure this? Right now it's all in one single project. Should I just break it out into separate projects under the one solution, or is there a better way? I honestly don't have a clue what best practices are here, and I couldn't find anything with Google. – Twisol Aug 31 '10 at 01:48
  • 1
    I don't entirely agree with this. A Boost installation, once the externals are compiled, is about 5GB (10 GB if you have to support VS2010 and VS2008). That's unreasonable to have under source control. – Billy ONeal Aug 31 '10 at 03:03
0

I've seen groups do the following:

  • Separate internal code from external code (code they made vs external companies)
  • Separate their code from library code
  • Separate each program and each library
  • Check in a compiled version of their dependencies, so it isn't a part of their full build cycle (at least, not in some branches. Other branches might do a more complete build)

Projects existed for each exe or library, in the directory with the exe/library.

Solutions existed wherever the teams felt it would be beneficial, and binaries were often linked, rather than their projects included in the sub-solutions. Only a full build was guaranteed not to break on a fresh enlistment.

Caveat emptor...

Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183