Sup with all of the linking and project organization issues with OF?

I ask this delicately, and after a good deal of time having used OF through various iterations.

At first I thought this was a user error issue on my part, but as time goes on, it seems to be an OF issue, or community issue.

Long story short, it’s rare that projects that people put together are organized/linked properly.

You open the file in where it seems it should be opened, add ons, link correctly, but then CoreOF and/or OpenFrameworks.lib isn’t linked right. You move it a level, and then CoreOF / whatever links correctly, but whoops, the add ons aren’t there.

Yeah, it’s not always a big deal to go ahead and find the files and re-add to the project, but what is the deal? Some projects, rarely, are setup totally as expected, perfectly. Very rarely.

In many ways, it seems as though the shift to Project Generator with the github branch has further exacerbated this problem, as now none of the organizational files are there. With more complex projects, it just takes a ridiculous amount of time setting it up, when I have the impression that the idea behind OF is to be a handy, intuitive, toolset.

Is there some kind of change in approach that could solve this? Am I the only one (rhetorical, I’ve seen tons of threads with people having similar issues). I think maybe one problem is that people don’t pay attention to the stock organization, upload add ons and examples that are some mix of correct in some ways, wrong and others… and that this is much of what’s out there for other people to take their queues from.

1 Like

I agree that code pollution definitely hurts the library’s reputation…

The simple reality why things are broken all the time is because the slightest change inside the core (usually for the better) can break 1000nds of other lines in other people’s code. But there is no way to avoid that unless the library stops evolving and focuses just on bug fixing.
Currently there is no concern on maintaining backwards compatibility. Hopefully it can be a greater priority maybe after the 2.0 milestone when the library is more stable and has a better vision on what it wants to be.

openFrameworks is indeed not just a library or a toolkit but a community built around a core and sometimes we completely forget that people are releasing things out of the goodness of their heart and it is highly unlikely they come back to fix or update anything. Even if it is something as simple as changing testApp to ofApp, creative people are just not going to be bothered because they are probably already consumed with working on something else…

Once you get beyond using OF core addons it becomes easy for this to happen and really relies on personal organization in order to keep projects intact.

I used to work on OF projects where I would need to hand off to other people without them going and looking for external addons and the best way I found was to include the ofxAddons into an “addons” folder inside the project folder and configure the projects path to look there. So to weigh the benefits:

Pros:

  • I could just say “download OF version 0.71” and open the project

Cons:

  • addons may contain bugs that were fixed
  • takes more time to initially setup
  • duplicated code/addons
  • doesn’t fit in well with the default/popular OF/addons structure

So even in doing this because OS updates/Xcode not containing older SDKs I can’t just give someone on a new machine access to a project and have it compile. I disagree with “Currently there is no concern on maintaining backwards compatibility.” as it comes up quite often in github issues. OF has quite a bit of effort to maintain compatibility with the last 2 releases of the current OSes.

It is also not just an OF issue - Node/Python/C all have similar issues once you go beyond the core support.

You may also want to look at https://github.com/bilderbuchi/ofStateManager which was created from a previous discussion around maintaining encapsulation

Really now, this is just a baseless and unnecessary accusation. >:-( There is concern, and care taken to maintain backwards compatibility, but it’s often, as you state, necessary to break things to keep OF moving forward/becoming better.

I have vested interests…
:see_no_evil:

we all have. what’s your point?

I am just joking, regarding this issue

https://github.com/openframeworks/openFrameworks/issues/3125

guess who didn’t compile today under 1.1… (glfw empty example)