7 Jan
2012
7 Jan
'12
9:04 p.m.
On Saturday 07 January 2012 22:47:47 Darrell Anderson wrote:
Is not a drawback, is intentional. If you request speex,
build system should
fail if is not found on your system.
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.
> 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: 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