>>>
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
\
$KDEGRAPHICS
This 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