On Saturday 07 January 2012 22:47:47 Darrell Anderson wrote:
> > > > 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.
> >
> > Is not a drawback, is intentional. If you request speex,
> > build system should
> > fail if is not found on your system.
> >
> > > 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:
>
> In a previous post I raised the issue of enabling all features as the
> default to more quickly expose build failures and reduce the time we spend
> collectively solving build issues. Some people might not like that idea
> because they want a minimal system, but without enabling all features as
> the default we never discover related bugs.

Try to see the reverse of the coin. For distros like gentoo, packages are 
splitted. So, if everything are enabled by default, ebuilds should disable 
_every_ unneeded stuff, for each package.

> As the upstream providers of the sources, we need to test all features even
> when our personal usage never uses some of those features.
>
> Second, does the cmake built process know to look for all subdirectories in
> /usr/include and /usr/lib? That is, declaring -DWITH_SPEEX let's the build
> process know I want that support, but are the cmake configurations written
> to find the speex header files in /usr/include/speex rather than fail
> because the header files are not found in /usr/include?

cmake should not try to detect things at any cost. Everywhere is possible, is 
used pkgconfig.

> Darrell


-- 
Serghei