> >>>> 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