I have some concerns about the way openFrameworks is currently built and deployed on the Linux platform, which I would like to discuss. I noticed that prebuilt versions of all of the dependencies are included in the source tree. This general practice of deploying software is IMHO generally very error-prone and not reasonable for different reasons which I would like to elaborate.
I see the idea is for the project to be ‘self-contained’ in order to simplify deployment at first glance. For the Windows and Mac OS platforms, this might be a reasonably pragmatic way of deploying. This practice, however, fails to acknowledge the general heterogenity of Linux systems. I see that you support specific Ubuntu version by supplying binaries for it, however I work, among others, on Arch and Gentoo, which generally use more up-to-date and more rapidly changing versions of programs and libraries. I see (and have experienced with many projects) the following problems with the self-contained deployment approach:
- You can not account for the vast amount of different standard library / compiler versions out there.
- People might be interested in using, apart from the openFrameworks API, one of the libraries on which it depends directly, and have specific requirements on it regarding versions / features compiled in.
- Libraries can have certain runtime behavior, such as using sockets or other IPC mechanisms, depending on global system configuration, writing to temporary files, etc. which creates conflicts if different versions of the same library are used in parallel on the same system.
- For some libraries, continuous and quick updating via distribution means is critical. Supplying a custom-built openssl library which will not get updated in case of a critical vulnerability is just insane in my opinion.
- Certain libraries will depend on having been built against other libraries on the system, e.g. if you supply glew and glu, you should probably also supply libGL, which you can’t since it will be different GPU vendor’s implementations.
- Having 1.1Gb of binary files in a Git repository which needs to be cloned over and over is a waste of people’s time and bandwidth, and just plain nonsense. One thing that should be done in any case is to remove those binaries from version control and provide a separate zip-file or whatever with the third-party libs (as you probably will still want to do for Mac/Win).
Of course having to account for different versions of a library on which you depend, with possibly incompatible APIs, introduces some additional complexity and maintenance effort, no question about that. However it will allow users of all the different target systems to use the library without running into any of the abovementioned problems. I’m also a firm believer in that it will increase overall code quality of a project, since you have to think about, and account for, those differences and structure your code more clearly, abstracting those variations in a meaningful way. Thus, in my opinion, getting rid of all the third-party libs, at least on Linux, would be the Right Thing To Do.
An important aspect is also that, in order to lower the effort (of non-Ubuntu users) to get in touch with the software and increase its adoption, the ideal scenario is of course to have it in the main software repositories of the big Linux distributions. However as things stand right now, no distribution will ever think about including it if it will not integrate with the rest of the system. Something like supplying an own libssl version etc. will keep every distributor from including that software, and in my opinion rightfully so! I was actually (probably naively) expecting, since oF is a rather mature lib by now, that I will find it in the repos of my favorite distros. But as things stand, that is not going to happen.
I would be interested in your opinions on those matters! Since I seem to be the only one right now with such requirements / concerns, I would be gladly willing to do the work, at least porting to those platforms on which I can test everything, and adapt the build system accordingly. I might need some help getting a grip on the specific build mechanisms you use (it seems you are not using standard tools such as CMake/autotools/scons, which is another issue…), so a little help of experienced oF devs will be useful, but I’ll manage to work the stuff out either way.