Restructuring OF

[ofZach]

this isn't done yet -- just want to start a PR to try to re-organize the OF folder a bit.

• most importantly: created a tests folder, we should figure out how to organize tests, maybe having different folders for different types of tests? (performance, platform, etc)
• moving PG to one folder so we can start merging and working on the next gen PG.
• moved devapps to the tests folder for now

I also want to push here for a different project structure that doesn't put all project files in one place, this will help greatly for cross platform development and PG related issues.

[bilderbuchi]

quickly: this sounds good. however, I think it would be better to divide this up into several PRs, as this would make integration much easier. for example, the PG reunion and the tests folder business are not related at all, but if this stays in one PR, a problem/todo in one will keep us from merging the other. also, this would help keep the diff (and the diff view on github) at a manageable size, and such more easily reviewable (along with descriptive commit messages).

As for the (automated) tests business, I'd like to point to #1068. lots of info already collected in the discussion, and @diasbruno even started a running implementation of unit tests, with some tests already written.

also, for the PG reunion, I think it would be smart to not have duplicate folder names in the new structure, i.e. projectGenerator/advanced/projectGenerator/, even if it's only temporary. this will only lead to confusion during discussion and development, and while we're moving files around, we are not constrained by directory names, so why not choose better ones (e.g. advancedPG as the subfolder for the advanced project generator)?

[diasbruno]

@ofZach @bilderbuchi

It is really hard to maintain tests on the main repo of the OF project.
I ended up trying some different approaches to make it work.

Some ideas:

1. Write all tests in another repository and use OF library as a "dependency".

openFrameworks/ofTester (repository)
   |----- openFrameworks/openFrameworks (git clone)
   |----- tests
   |       |---------- graphics
   |----- ./test_runner

2. Split the OF library in smaller libraries, using something like the 'addons' folder structure (ofGraphics,
   ofMath, ofSound...), and write tests on each "module".

openFrameworks/ofGraphics (repository - depends on ofMathLib and other libs.)
   |----- lib?
   |----- src
   |----- tests 
   |----- Makefile

openFrameworks/openFrameworks (repository)
   |----- libs
   |       |---------- ofGraphics (core submodule)
   |       |---------- ofMath (core submodule)
   |       |---------- ofSound (core submodule)
   |       |---------- ofAddon (git clone or managed by some app)
   |----- apps
   |       |---------- MyOFApp 
   |       |---------- ofGraphic"Example" (git clone)
   |       |---------- of3dGraphicExample (git clone)
   |       |---------- ofAddonExample (git clone or managed by some app)
   |       |---------- ofProjectGenerator (git clone or submodule)
   |----- tests
   |       |---------- graphics
   |       |---------- math
   |       |---------- sound
   |----- scripts

3. Same as 2), but with tests in another repository.

openFrameworks/ofGraphics (repository - depends on ofMathLib and other libs.)
   |----- lib?
   |----- src
   |----- tests 
   |----- Makefile

openFrameworks/ofTester (repository)
   |----- libs
   |       |---------- ofGraphics (submodule)
   |       |---------- ofMath (submodule)
   |       |---------- ofSound (submodule)
   |       |---------- ofxiPhone (?)
   |----- ./test_runner

openFrameworks/openFrameworks (repository)
   |----- libs
   |       |---------- ofGraphics (core submodule)
   |       |---------- ofMath (core submodule)
   |       |---------- ofSound (core submodule)
   |       |---------- ofAddon (git clone or managed by some app)
   |----- apps
   |       |---------- MyOFApp 
   |       |---------- ofGraphicExample (git clone)
   |       |---------- of3dGraphicExample (git clone)
   |       |---------- ofAddonExample (git clone or managed by some app)
   |       |---------- ofProjectGenerator (git clone or submodule)
   |----- scripts

1. is a lot simpler and has no impact on the architecture.

2), IMHO, seems to be nice, but it adds some complexity, it has a big impact on the architecture of the library and it will have a lot repositories to manage.

Hope this makes some sense. :)

[bakercp]

IMHO -- From a software architecture standpoint, I'd love to see 2 or 3. From a pragmatic standpoint, 1 would create the least amount of major surprises before version 1.0. A restructuring like 2 or 3 would affect everything right down to the makefiles, project templates and many existing projects.

I'd vote for integrating option 1 leading up to release 1.0 and once we get a good testing system figured out, a re-architected openFrameworks for 2.0 will be able to respond to (and reuse portions of) what we learned from testing in 1.0.

[bilderbuchi]

Thanks for your feedback, Bruno! I agree that 1) sounds most reasonable right now.

I'm curious, what were the problems you encountered when having the tests in the same repository (e.g. in a root folder "tests")? I think it would be best from a synchronicity perspective to keep the tests in the same repo as the source itself, and don't introduce (many) more submodules.

We already have the folder in libs/openFrameworks/* which differentiate the different parts of OF, I think we should just work incrementally on separating those more during future development, to reduce interdependencies, but I'm not sure why it's necessary to split them out into separate git submodules for that...?

[diasbruno]

@bakercp yep, that's the problem, 2 is a big change...it's a great solution, but it introduces a lot of complexity...

@bilderbuchi those are just ideas i had while I was trying to write a solution for theses tests.
writing tests in the another repo would be nice because if a developer only needs to clone OF and start playing, they don't need to get all those tests and build scripts...so it just keep things separated. also, it doesn't pollute the history of the main repo.

2 and 3 are ideas for restructuring the OF's core. more for curiosity...although, it would make smaller "modules" and make dependencies, it adds a lot of complexity, need a review in all the build process, and it does not seems to be the intent of the OF's project. so, it's just an idea :)

[bilderbuchi]

only needs to clone OF and start playing, they don't need to get all those tests and build scripts...so it just keep things separated. also, it doesn't pollute the history of the main repo.

the problem I see with this is that it's very easy for tests and the code they test to get out of synch, which is really undesirable. plus, more commits, as you have to commit every change (+ its tests) into two repos. also, the size savings for anyone only wanting to "play" would probably be very small (compared to the baggage of binaries we are already dragging along), and I think the tests folder will probably be removed for packaged releases, anyway. history pollution I don't buy really, as a proper policy would dictate that any new feature would have to be accompanied by testing code (which can go in the same commit, typically).

[arturoc]

going to move this back to 0.10 since it's kind of a complex PR and it doesn't seem to merge anymore, @ofZach feel free to move it back to 0.9 if you think you can have it ready before the deadline

[arturoc]

we moved the PG to a different repo so this won't merge anymore