The tdenetwork package has a cmake option -DWITH_SPEEX. How do I add the specific location of the speex include files? With automake I would add this: --with-extra-includes=/usr/include/speex What is the equivalent directive in cmake? Darrell

Hmm. Same problem is going to happen with several other packages, such as amarok. In amarok there is a -DWITH_MP4V2 option, but I need to ensure cmake finds the header files in /usr/include/mp4v2 and not in /usr/include/mp4. I can use the -DINCLUDE_DIRECTORIES option, but seems cmake should be configured to look in that directory automatically. How do I revise the cmake files to look there automatically?

Fat-Zer wrote: Why make it a fatal error when it can be built without speex? -- Bruce

> Fat-Zer wrote: >> 2012/1/7 Darrell Anderson <humanreadable(a)yahoo.com>

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

Timothy Pearson wrote: 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.

speex ) "speex is required, but was not found on your /usr/lib/pkgconfig. without speex? if speex support is will be no fatal error when specify everything. generally can do Most of the time it what the default ./configure gives: -DCMAKE_VERBOSE_MAKEFILE=ON \ \ -DCMAKE_CXX_FLAGS="-fpermissive" \ \ \ \ \ \ \ \ \ -DBUILD_KGHOSTVIEW=OFF \ -DBUILD_KFILE_PLUGINS=OFF \ for someone who 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.

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

Darrell Anderson wrote: It might be a good idea to add a -DBUILD_AUTO flag that causes any I am noticing that -DBUILD_ALL does not encompass all features. In There are two sets of parameters: BUILD_XXX and WITH_YYY. The BUILD_ALL parameter turns on all the BUILD_XXX parameters, but doesn't affect the WITH_YYY parameters. If we enable all features by default, we end up with larger packages The defaults are not terribly important. What I'd like to see is a WITH_ALL flag similar to BUILD_ALL. I do like the idea of a BUILD_AUTO flag. When a needed dependency is not found, a message like: libtiff.so not found. Disabling TIFF support. Even better would be a summary of findings at the end of the cmake invocation. For instance, openssh gives the following at the end of configure: OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/lib/openssh/ssh-askpass Manual pages: /usr/share/man/manX PID file: /var/run Privilege separation chroot path: /var/lib/sshd sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin Manpage format: doc PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: S/KEY support: no TCP Wrappers support: no MD5 password support: yes libedit support: no Solaris process contract support: no Solaris project support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Privsep sandbox style: rlimit Host: x86_64-unknown-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -fno-builtin-memset -fstack-protector-all Preprocessor flags: Linker flags: -fstack-protector-all Libraries: /usr/lib/libcrypto.a -ldl -ldl -lutil -lz -lnsl -lcrypt -lresolv This tells the user exactly what is being built. If the user wants something else, he has a basis to determine what is missing (or extra) and make the appropriate changes. -- Bruce

One thing with cmake that would be good is a list of options. All should be disabled by default, like samelian says, but there should be the option to enable all dependencies (not just -DBUILD_ALL) and a way to see what options are available. Agreed?

Calvin morrison

that causes any functionality as Autotools does. If you want to see this please file an enhancement The defaults are not terribly important. What I'd like to see is a WITH_ALL flag similar to BUILD_ALL. I do like the idea of a BUILD_AUTO flag. When a needed dependency is not found, a message like: libtiff.so not found. Disabling TIFF support. Even better would be a summary of findings at the end of the cmake invocation. For instance, openssh gives the following at the end of configure: ... This tells the user exactly what is being built. If the user wants something else, he has a basis to determine what is missing (or extra) and make the appropriate changes.

That is how the process should work. Let the downstream packagers handle what they want. As upstream providers we need to ensure everything works.

So basically we might still need to use the -DINCLUDE_DIRECTORIES option should the pkgconfig file be incorrect. Will the build halt when I specify -DWITH_SPEEX, don't use -DINCLUDE_DIRECTORIES, and cmake can't find the speex header files?

Darrell

Yes, this sounds palatable. As upstream providers we need to test everything. Right now doing that is cumbersome. I understand that individual packagers don't want everything enabled. I don't either, but I am looking at this as an upstream provider and not just a packager. We can't test everything if most of the features are disabled by default.

It is mainly a novice builder/user usability problem; i.e. if we need to manually enable all features then there should be a universal, simple way to get a listing of all features that can be enabled. Opening the CMakeLists.txt file and reading the entire thing does not count. ;-) Tim

It is mainly a novice builder/user usability problem; i.e. if we need to manually enable all features then there should be a universal, simple way to get a listing of all features that can be enabled. Opening the CMakeLists.txt file and reading the entire thing does not count. ;-)