File Structure Change

[ghost]

Initial discussion on #1

I think its beneficial to change the file structure now(at least headers) to make the use of the project as a lib more straightforward and practical.

• OSInteraction
  • src
  • include
  • examples

The src and include conventions are pretty much everywhere i touched until now on (Not a lot of experience). I am a big fun of SFML structure: SFML altogh i am not sure about include/PROJECT-NAME src/PROJECT-NAME.

What i normally do for my projects both on windows and linux is the following:

• Project
  • src
  • include
  • build
  • windows-x86
  • linux-x86_64
  • data
  • extlibs
  • OSInteraction
    • src
    • include
    • lib
    • windows-x86_64
      • osi.lib
    • windows-x86
      • osi.lib
    • linux-x86_64
      • libosi.so
  • Makefile
  • Project.vsproj

I am pretty sure Makefile and Visual Studio files covers pretty much all users. but i am going to create another issue for this.

Also, i think a ready-to-go examples dir very attractive when i am testing a new shiny thing i just found.

[alec101]

My concern about changing the dir structure is, that it should be done once and it should be set in stone from that point on, because changing it multiple times would be bad. Therefore, this should be not rushed.

My dir structure is kinda the same:

project

• source - this might be better src
• output - output stuff - compiled library, etc
• build - temporary build dir for the compilers
• vstudio - in this dir are the project files
• nbeans - net beans - this project dir is the same for linux / mac. I'm using netbeans for the other OSes - the only problem with net beans is, when it crashes, you need to know where the cache dir is, and delete it, or else, the intelli-sense won't work anymore.
• cblocks - code blocks ide proj file. Similar to vstudio as the project structure.
• codelite - code lite ide - this one has a complicated project file - makefiles lots of stuff - and i think you can't change easily where it builds, so it builds in codelite/.clang codelite/.[compiler name]
• eclipse - the C plugin is ... $#@ unfortunately, but if ppl want to use this... i think there are not many problems setting this up
• xcode - the ide of macs - well, there are tons of files in the xcode project - you can't change the build location easily, i think (from what i'm seeing i have tons of garbage dirs with build as a name)

I kinda like the proposed directory change. Lemme lay down my thoughts:

• source to src- fine by me
• new include dir- seems ok - there can be benefits and this is a 'standard', but i try not to follow standards, maybe invent something new :) but it's an ok change
• extlibs- not sure what ext means - maybe just lib? and a dir for every os... there will be 12 files, if the name is self explanatory (libOSI32linux / libOSI64win) there is not a big need for dirs... heavily depends on the filename - if it's self explanatory or not
• makefile / cmake - im a noob. No really, i maybe did 1-2 makefiles and that's it.

The examples, are very nice... A proj file for each of them? so the user should only compile and run? dunno.

I'll sleep more on the matter, more input is welcome! [EDIT: formatting]

[ghost]

I agree this should not be rushed.

About "src" and "include" i think it will make the project look more familiar to people used to open-source but only that. I have a very high respect for standards but i dont mind it if you wanna take the project to a different path, it's still a standard, just a project-specific one.

"extlibs" or "extlib" are the libs that your project needs to use to work properly whereas lib is the compiled lib for the current project. For me at least, of course.

About the lib subdirectories, every single lib i have used till date only outputed libLIB-NAME.so and libLIB-NAME.a(if static) under linux and LIB-NAME.lib under windows for different architectures. I found it best to split them into folders. So a example Makefile would look something like this:

all: gcc -std=c++11 -Wall -pedantic -Iextlibs//include src/.cpp src/util/.cpp -o build/$(OS)-$(ARCH)/binary.bin -Lextlibs//lib/$(OS)-$(ARCH)/ -lLIB1 -lLIB2 -lLIB3

With this line i referenced all headers for all the libs my project depends on and their "libfiles" since the name of the lib is the same on all Archs. This pseudo code can compile the project in every single platform and arch.

[alec101]

Updated everything. If everything is ok... maybe the project dirs can be prj.vstudio / prj.nbeans / prj.blabla.

[ghost]

The project dirs sounds good if you insist in providing more than a visual studio and a makefile (I'am ok with that)

Just one more thing, the extlib dir should be structed like

• extlib/
  • directx
  • lib
  • include
  • src (not on this case ofc)

Right now DirectX headers are on {$root}/include

I will commit some examples today after i learn a bit more of the API.

[alec101]

done

[ghost]

Aww yeah! Closing this one.