Reorganize Project and Include Dependency Libraries

[ghost]

The project should be setup in a more organized fashion including a separated source folder, binaries folder, build folder, documents folder, and test folder. Then setup one of the folders (either the binaries folder or another separate folder) to include either the source or the binaries of dependencies that can be used for building the whole project. This way a developer building the project doesn't have to care if they have all the dependencies pre-installed or pre-compiled.

[j-meyer]

Considering the Boost Library alone is approximately 90 something mb, it doesn't make sense to attach the libraries to the source control. Additionally, any bug fixes in any of the libraries would then have to be integrated as well.

[FinalDoom]

Normally, in a production environment, people use tools, such as ant or maven (I prefer the latter) to handle library management, updating, downloading, and building. Libraries should absolutely not be in individual project source control, as they are separate projects, with separate source control, with separate dependencies.

A binary folder would be a good idea, if you are only building to one environment, but most source control is not built to handle binaries effectively space-wise. If you include deploys, such as exe, so, dll, deb, etc. That is one thing. Intermediary objects don't source control effectively.

[ghost]

Here's a possible setup for the project hierarchy:

• Drink-CPP (root directory)
  • src (dir)
  • test (dir)
• bin (dir)
  • dep (dir)
  • etc (dir)
• doc (dir)
  • dox (dir)
  • uml (dir)
  • other (dir)
• build (dir)
• tmp (dir)
• README (file)
• Makefile (file)

src - The directory to contain all of the project's source code. test - The directory containing the project's test code. bin - The directory containing resources used by the project but not made in the project or is some misc. binary resource. dep - The directory containing dependency binaries/source for building the project. etc - The directory containing misc. binary resources for the project. doc - The directory containing the documentation for the project. dox - The directory for the Doxygen output. uml - The directory containing uml diagrams to visualize the software. other - The directory containing misc. documentation. build - A directory set aside specifically for placing the build output files to keep the rest of the project clean. tmp - A directory for storing temporary files when needed. README - A file for containing the basic project information. Makefile - The file containing the commands to execute with the use of Make.

Edit: Changed hierarchy list to be better formatted to show correctly.

[ghost]

Nate: I see what you mean and James just explained to me how much of a pain that would be. However, the intermediate binary object files and such are not intended to be tracked. I figured such things could be placed in the "tmp" directory where the directory itself is added to the repo for the sake of everyone having a uniform hierarchy but the files placed inside folders like the "tmp" folder should not be tracked.

[FinalDoom]

A good build tool like maven will allow you to do a lot of the directory separation as far as documentation, building, etc with "one click" so to speak, without having to worry if the directories are in source control or not (mercurial, for one, does not track directories, just files), only that people have the build file (for maven, a POM), and build from it. Your divisions make sense, though. I would argue against "other" and "tmp" because they seem more like local side things, which people can do whatever they want with. If you don't have docs that fit in the other directories, you probably don't need them, or they should be restructured. The rest can simply be configured as a part of your build with target and source directories, test directories, etc.