On 05/06/2011 03:09 AM, Serghei Amelian wrote: I think we are not talking apples-to-apples: users - means some new user with no build experience that downloads the binaries and expects to run and use the software; developers/packages - the monkeys that run cmake I see and agree with your point though - it will be up distro packagers to turn the options on/off. However, that has a downside. That leads to differing functionality for Trinity depending on which distro the user has installed. If we go that route, then we need to document what options are EXPECTED to be enabled for each of the trinity modules so that the packagers have a reference for what should be working. This would also provide links to the modified sourced needed to enable the options like the modified carddav/caldav sources: http://quickbuild.pearsoncomputing.net:58080/2056019/libcarddav_0.6.2-2debi… http://quickbuild.pearsoncomputing.net:58080/2055979/libcaldav_0.6.5-2debia… At least that way the packagers know where they can get working sources to enable the available options. Some options should just be enabled in the Trinity source. SASL is a perfect example. Without SASL requires no additional 3rd party packages and without SASL enabled, kmail can't connect to even a simple imap server. Maybe we should look at what COULD/SHOULD be enable in the code by default that doesn't require any additional packages. -- David C. Rankin, J.D.,P.E.