On May 4, 2014, at 11:39 PM, Michal Orynicz <michal.orynicz@xxxxxxxxx> wrote:
> Personally, I'd think that it should fail, as the features that were specified to be active cannot be activated. This way the user is forced to consciously change desired configuration to one not containing the packages, or install the required packages.
Personally, I think that, for many features requiring third-party libraries, there are *THREE* choices:
1) include the feature iff the third-party library is present, which is the default with autotools, and should be the default for CMake;
2) fail if the third-party library is present;
3) don't even try to link in the third-party library.
Autotools supports all three for those features - you can:
give no --with-XXX or --without-XXX option, and get the first choice;
give --with-XXX, and get the second choice;
give --without-XXX, and get the third choice.
We currently don't offer all three choices with CMake; I have filed bug 10074 about that.
> On the other hand, we could just make CMake turn off the features which findpackage could not find.
That's the best compromise, if bug 10074 isn't fixed, and was the behavior before the recent change. I have checked in changes CMakefile.txt to
1) properly set the XXX_REQUIRED variables, so that for packages for which XXX_REQUIRED is set, the configure will fail in find_package;
2) *not* fail merely because a non-required package is missing.
(Note also that, for third-party libraries that are platform-specific, the build should *NEVER EVER EVER* fail if a library is absent because it doesn't exist for, or isn't relevant to, your platform. Builds should, for example, *NEVER EVER EVER* fail on any non-Linux OS if libnl is missing.)
