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?
↧
