trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: January 2012

Re: [trinity-devel] cmake options

From: Darrell Anderson <humanreadable@...>
Date: Sat, 7 Jan 2012 12:47:47 -0800 (PST)
> > > 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.

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?

Darrell