I'm about to open source a C++ project on Sourceforge. Can I get some tips on code organization? -

i'm upload project i've been working on onto sourceforge under gpl, , hoping advice on how organize code in fashion easy understand , use developers might @ it, works git, , way sourceforge presents things.

my projects cross-platform c++ application, , consists of following:

• a library portion, actual work
• a separate gui portion, uses library portion
• open source libraries, include paths needed compile library
• modified open source libraries, have been altered, , hence in sense direct part of project well
• compiled output of of libraries

what's best way organize this?

while working on myself, project root have this:
/libportion
/guiportion
/libs/open source libraries
/libs/modified open source libraries
/libs/compiled/ hold compiled libraries, including when compiling windows aren't open source libraries, such cygwin library files

is sensible way organize things? match conventions , expectations?

when checking in project, make sense check in open source libraries part of project? figure makes sense so, because minimizes friction getting project set , running new dev. should @ least check in modified open source libraries.

also, make sense include in repository under compiled libraries? i'm thinking might best tell git ignore directory , leave empty, since contents different on every build target, since project cross-platform.

however, seems nice people don't want hassle building and/or downloading libraries offer libraries pre-compiled major platforms. what's smartest way share those? i'm looking @ sourceforge, , it's not readily apparent me how should share if not part of git repository.

in general, separate work of third parties. on basic level, root folder like:

|- gui |- library |- third-party     |- lib     |- source 

i separated "third-party" folder 2 subfolders purposes of license compliance , ease of use. how distribute third party libs depend entirely on licenses. set makefiles compiled libs land in third-party\lib folder (which place pre-compiled libs). way user can download pre-compiled libs , ignore source folder or download source code , ignore lib folder depending on whether or not want re-build third-party libs.

if required distribute modified version in binary , source code form, need host modified version in source repository (providing pre-compiled lib choice).

if using unmodified library , using subversion repository (or similar), can use externals property link repository third party library's repository such when user gets copy of source code, grabs lib's source own repo. way, don't have keep local mirror of library source. depending on third-party lib has available in repo, may able use externals link pre-compiled version of third-party lib well. not lessen amount of code have host in repo, more indicate particular third-party lib has not been modified.

when using unmodified libraries, better not include source or binary in source tree @ all. make note in documentation project depends on library x (specify version well, if important) , provide link library's project homepage/sourceforge page/repository. let developer decide whether want compile library, download pre-compiled version, or possibly use version have installed. means can't assume library or headers exist in particular directory relative source code; instead, have trust user install libraries compiler can find them. code assume in compiler's search path.

it possible modified libraries implemented such externals property cause unmodified source retrieved third-party repo, , build system can apply patch containing modifications. way, not technically distributing modified code, might mean several fewer license terms have comply.

typically, wouldn't recommend distributing pre-compiled versions of library inside source repository. sourceforge, can pre-compile library (or other "end product") major platforms , offer them downloads.