Excerpts from Tobias Dammers's message of 2016-12-11 17:53:07 +0100:
The pipe dream would be for those dependencies to be optional *at run time*, such that the application would test for their presence on startup, or load them dynamically when and if they're needed.
It's not completely unthinkable to directly interface with dlopen() and similar functions to dynamically load symbols. posix even has a (not very widely used) module for precisely this: https://hackage.haskell.org/package/unix-2.7.2.1/docs/System-Posix-DynamicLi...
However, I'm also fine with making them compile-time feature toggles, such that users can enable only the ones they need.
This is certainly what flags in Cabal files can be used for. More below.
Doing some sort of autotools-style dependency discovery would of course be cool as well (i.e., only enable mysql support if libmysqlclient is present).
This is also possible using build-type: Configure, see: http://cabal.readthedocs.io/en/latest/developing-packages.html#system-depend...
Question: I like to let the user enable extended functionality using a Cabal flag. Is this the right way?
Answer: Certainly not. Since other packages can distinguish packages only according to their name and their version, it is not a good idea to allow different APIs for the same package version. Cumbersome as it is you have to move extra features to a separate package.
Moving the features to a separate package wouldn't really solve anything AFAICT, because I'd still have to bring them together somehow.
Yeah, this is something that gets a bit of push and pull, even amongst Cabal developers. It is definitely true that there's no way to depend on a library, AND say that it must have some feature flag toggled, which makes it impossible to accurately specify the dependency. But for an executable application, this seems like less of a problem because no one can depend on you. Seems a lot more reasonable in this situation. Edward