Make install target, shared object build

Hello again,

oF compiles nicely on current Arch Linux! Regarding proper deployment, I wonder, where can I find the make install target, and how can I perform a shared object build, the default seems to be static libraries?


Ok relating to the CMake effort in the linked thread, I want to take this one to discuss the matters of deployment and building the libraries as shared objects. This would greatly simplify the way other applications/libraries can make use of oF. Since it depends on many third party libraries, supplying all the dependant library locations etc. at link time of the application (as @procedural kindly pointed out) is a bit of a struggle although possible of course. I think that this should be done only in the cases where it’s absolutely necessary, e.g. when you need the dependant project’s include paths because of oF headers including library headers (one important reason to use forward declares wherever possible), heavy use of templated code, or the like. So you sometimes need the include paths / headers for that. For libraries and their specific locations, the application build should not have to care about finding them on the system, since those transitive dependencies will already have been localized by the linker stage of the shared object, and referenced via RPATH entries in the shared object. So in order to keep simple (and of course put less strain on one’s harddrive if many many little projects make use of the oF libs) I would much prefer the library to be built as shared objects, at least on Linux where we need to deal with these deployment / integration concerns. So my question is, what are your reasons for not building oF as shared libraries?

One remark, for CMake based projects, there seems to be a mechanism I wasn’t myself aware of until now, imported / exported targets. It seems like that could kinda leverage the problem a bit, however I still thing going with shared objects would be the better way to go, especially for build systems other than CMake. I again want to point out that I have a strong opinion against resolving those issues by forcing people to use a project generator which is part of the library, we need to get this straightened out, and I’m willing to invest some work in order to do so.

So is there interest in a proper CMake based build system, which allows shared object builds and proper deployment as people working with external libraries under unix/linux are accustomed to, and will reduce the cross-platform maintenance effort? I haven’t had the time to look into what @procedural maintains, but if it builds fine and works (does it?) what are the reasons for not switching over?

The point being, that I’ve looked into what the dependencies and build requirements of oF are intensively in the last days, got a working solution for the openFrameworksConfig.cmake, and since we’re doing a static build this was I think comparable effort to just going and writing a whole project configuration. Just want to ask the lead devs if there’s still interest, then I might look into this at times and issue a pull requests. No promise that I can be quick however, work and other programming stuff takes most of my time right now.

Another issue is that openFrameworks, being built completely monolithic right now, becomes rather a beast. I think the number of dependencies will rather increase than decrease in the future, and people will have to get everything onto their system and properly set up even if they only want to use specific parts of the library. A Cmake build would allow to have a nice way of disabling those subsystems/components as well…

[Edit: merged posts and expanded…]