After a discussion with Ben it seem like the real holdups are
1) ease of commercially licensing of IMP as a whole. It is better to license something with a fast non-bonded list than without (and CGAL wants money from commercial users). The license of the package itself wouldn't be affected meaningfully by linking with QPL or LGPL or similar dependencies as it is easy enough to isolate contaminated code in particular .cpp files. Personally, I don't think we should put much effort towards the future until it arrives. As long as we abstract from the external libraries well, reimplementing the algorithms later won't be more work than writing it now (and in fact, should be easier since we have a good implementation to compare against). And wrapping it typically quite cheap to write an maintain.
2) Other people probably don't want to install another external library. Fine, as long as other people want to help develop the functionality :-) I would only propose only using libraries that are really easy to install (rpms on redhat, packages on ubuntu, and some sort of installer for mac os and windows and no more effort than "install- command --prefix=path" on the rest). My estimate is that installing a decent library isn't generally more work than than writing and maintaining a couple of lines of code. But maybe others have different weights. We also should not depend on libraries that are evolving too fast since those require the user to update frequently.
3) It is faster to test two separate runtime code paths rather than two separate compile time code paths (since the unchanged tests don't run more than once and the compilation doesn't have to be repeated). I think this is most substantial concern. The best solution I have to this so far is that we should make sure optional dependencies are independent so that simply testing with all of them and without all of them is enough. Strictly speaking, we already need tests without the dependencies (such as boost) to make sure that the installer fails properly.
Any other thoughts?
A couple less related ones:
- We should adopt the policy of building as many things as possible at once-- e.g. impem should be built/installed along with everything else when embed is found (same way modeller support is done now).
- I personally don't plan to put much effort into the grid-based nonbonded list and will use the CGAL one. With the yet-to-be-check-in cleanup, much of the code is the same and so many of the parameter tweaks will benefit both.
- we need a cleaner way of adding search paths to scons. I had to go figure out what paths IMP already uses to search for boost and find one that wasn't owned by some software in order to tell Frank were to install boost (since mac ports choked while trying to build it on his machine). This is a bit silly.