Just add this to ConfigureChecks.cmake:
if( WITH_SPEEX ) pkg_search_module( SPEEX
speex )
if( NOT SPEEX_FOUND ) tde_message_fatal(
"speex is required, but was not found on your
system" ) endif( NOT SPEEX_FOUND ) endif( WITH_SPEEX )
# haven't tested but should work. # and check the name of speex *.pc file in
/usr/lib/pkgconfig.
Why make it a fatal error when it can be built
without speex?
There should be a global flag defined (WITH_SPEEX)
if speex support is
desired. If that flag is not set then there
will be no fatal error when
speex is not found.
To me, this is a drawback of cmake. You have to
specify everything.
I'm not an expert in cmake, but with configure, you
generally can do
--help and get a list of acceptable parameters.
Most of the time it
also tells you if the dependency is (auto) or not, or
what the default
is. For example, in kdegraphics-3.5.10, a simple
./configure gives:
checking for sane-config... not found checking if doc should be compiled... yes checking if kamera should be compiled... no checking if kcoloredit should be compiled... yes checking if kfax should be compiled... yes checking if kgamma should be compiled... yes checking if kghostview should be compiled... yes checking if kiconedit should be compiled... yes checking if kmrml should be compiled... yes checking if kolourpaint should be compiled... yes checking if kpdf should be compiled... yes checking if kpovmodeler should be compiled... yes checking if kruler should be compiled... yes checking if ksnapshot should be compiled... yes checking if ksvg should be compiled... yes checking if kuickshow should be compiled... yes checking if kview should be compiled... yes checking if kviewshell should be compiled... yes checking if libkscan should be compiled... no checking if kfile-plugins should be compiled... yes checking if kfaxview should be compiled... yes checking if kdvi should be compiled... yes checking if kooka should be compiled... no
But kdegraphics-3.5.13 requires:
cmake -DCMAKE_INSTALL_PREFIX=$TRINITY_PREFIX \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DQT_VERSION=3\-DCMAKE_CXX_FLAGS="-fpermissive" \
-DWITH_TIFF=ON\-DWITH_PAM=ON\-DBUILD_ALL=ON\-DBUILD_KAMERA=OFF\
-DBUILD_KSVG=OFF\-DBUILD_KUICKSHOW=OFF\-DBUILD_LIBKSCAN=OFF\
-DBUILD_KOOKA=OFF\-DBUILD_KGHOSTVIEW=OFF \
-DBUILD_KFILE_PLUGINS=OFF \
$KDEGRAPHICSThis is fine for a developer, but a lot more difficult
for someone who
just wants to build the package once.
In TDE most modules have a -DBUILD_ALL flag that enables the "default" build options without having to manually specify all of the individual submodules to build.
It might be a good idea to add a -DBUILD_AUTO flag that causes any failing checks to simply disable the associated functionality as Autotools does. If you want to see this please file an enhancement bug report.
I am noticing that -DBUILD_ALL does not encompass all features. In several of my build scripts I have had to specify various options because the default is for many features to be disabled.
If we enable all features by default, we end up with larger packages sizes, but the advantage is things breaks faster. One of the challenges I see in Trinity development is many developers do not build all packages. When a person comes along who is interested in building such a package, that person usually finds problems. If all features were enabled by default, collectively we would discover these problems much faster.
I understand the desire to build minimally but from an upstream development perspective we should enable all features as the default and let downstream packagers disable what they don't want. To me this seems the saner and safer approach. If many features are disabled, how do we know there might be breakage? We don't.
I vote to enable all features as the default. Collectively we spend too much time chasing compiling issues. I want to see things break right away. If the breakage is a feature I know I don't want or never will use, then I can disable that feature in the cmake options. Hunting for every option so I can enable them is challenging and tiring.
For most packagers, building packages for many downstream users basically requires every feature be supported and tested because a packager never knows what end-users need or want.
For example, I built my kdepim 3.5.13 package without SASL support because that support is disabled by default. Obvious now, but not when I first built the package. In another package HAL support is disabled by default and that caused havoc with device detection.
Serghei is not to blame. He took a conservative route. I just believe we need to enable all features as the default to reduce build issues and more quickly expose building problems. Let downstream packagers decide what they want but let's us ensure everything "just works."
I too miss the simplicity of ./configure --help. Allegedly cmake supports something similar --- perhaps somebody can explain how to expose that information.
Darrell