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
2012/1/7 Darrell Anderson humanreadable@yahoo.com
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
-DINCLUDE_DIRECTORIES="/usr/include/speex" Generally later there should be added a check via pkg_config in ConfigureChecks.cmake. so it would be handled out of the box.
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?
-DINCLUDE_DIRECTORIES="/usr/include/speex"
Thanks! I did not find that when I searched the web.
Generally later there should be added a check via pkg_config in ConfigureChecks.cmake. so it would be handled out of the box.
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?
2012/1/7 Darrell Anderson humanreadable@yahoo.com
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?
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.
Fat-Zer wrote:
2012/1/7 Darrell Anderson humanreadable@yahoo.com
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?
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?
-- Bruce
Fat-Zer wrote:
2012/1/7 Darrell Anderson humanreadable@yahoo.com
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?
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?
-- Bruce
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.
Tim
Timothy Pearson wrote:
Fat-Zer wrote:
2012/1/7 Darrell Anderson humanreadable@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.
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.
-- Bruce
On Saturday 07 January 2012 19:16:43 Bruce Dubbs wrote:
Timothy Pearson 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:
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
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
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.
That is how the process should work. Let the downstream packagers handle what they want. As upstream providers we need to ensure everything works.
cmake should not try to detect things at any cost. Everywhere is possible, is used pkgconfig.
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
On Sunday 08 January 2012 00:16:33 Darrell Anderson wrote:
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.
That is how the process should work. Let the downstream packagers handle what they want. As upstream providers we need to ensure everything works.
I won't to argue about this, but I will never agree with it :) However, if someone want to patch cmake files to do this, I will not be against.
cmake should not try to detect things at any cost. Everywhere is possible, is used pkgconfig.
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?
Actually cmake don't care too much about INCLUDE_DIRECTORIES, will stop anyway if speex.pc doesnt'e exists (I assume that every sane system have this .pc file).
Darrell
Timothy Pearson wrote:
Fat-Zer wrote:
2012/1/7 Darrell Anderson humanreadable@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.
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.
Thanks!
Tim
On Saturday 07 January 2012 20:01:26 Timothy Pearson wrote: [...]
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 strongly disagree. In my opinion, this is a bad approach. Current implementation did exactly what you want, not what cmake build system think that is good for you (e.g. skipping/building modules based on existence/non existence of a dependency; these dependencies can be missing because a mistake).
Thanks!
Tim
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 \
$KDEGRAPHICSThis 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
Darrell Anderson wrote:
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.
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 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.
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
On 7 January 2012 16:15, Bruce Dubbs bruce.dubbs@gmail.com wrote:
Darrell Anderson wrote:
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.
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
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.
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: gccCompiler 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
Calvin Morrison wrote:
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?
Yes, that seams reasonable, but I'd also add an option to disable an option and continue with a message if a prerequisite is not found.
-- Bruce
On Saturday 07 January 2012 23:35:32 Calvin Morrison wrote:
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?
Just use ccmake.
Calvin morrison
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?
No. When important features like HAL or SASL are disabled by default, various apps in the package are rendered useless. Any app needing authentication with SASL, for example, which includes the staple app of KMail, is no longer functional. Likewise with HAL.
I disagree with disabling everything. We as the upstream providers need to test everything. The downstream packagers decide what to disable for their distros or personal usage.
Darrell
On Sunday 08 January 2012 00:06:18 Darrell Anderson wrote: [...]
No. When important features like HAL or SASL are disabled by default, various apps in the package are rendered useless. Any app needing authentication with SASL, for example, which includes the staple app of KMail, is no longer functional. Likewise with HAL.
Before building something, packager should be aware about all features are available for package. I do not want to dictate which feature are "important" and which is not.
I disagree with disabling everything. We as the upstream providers need to test everything. The downstream packagers decide what to disable for their distros or personal usage.
Darrell
I disabled every feature intentional, because I think this behavious is very consistent, and packager will don't need to guess which features are OFF and which are ON.
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.
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.
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.
Darrell
On Sunday 08 January 2012 00:11:15 Darrell Anderson wrote: [...]
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.
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.
Actually I do not understand the problem. If you want to check all features, enable they.
On Sunday 08 January 2012 00:11:15 Darrell Anderson wrote: [...]
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.
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.
Actually I do not understand the problem. If you want to check all features, enable they.
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
On Sunday 08 January 2012 02:02:22 Timothy Pearson wrote: [...]
Actually I do not understand the problem. If you want to check all features, enable they.
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
ccmake should be enough.
On Sunday 08 January 2012 02:02:22 Timothy Pearson wrote: [...]
Actually I do not understand the problem. If you want to check all features, enable they.
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
ccmake should be enough.
How do I get a list of all TDE-specific CMake flags with that command?
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. ;-)
I agree that the experience and knowledge of packagers will vary and I'm a good example. :) I'm still learning.
A deeper problem is without a simple way to enable all build options there is no way to test all the features. Each distro is different. Developers and packagers are inclined to test only what applies to their distro. If all build options were enabled as the default, yes, developers and packagers would see immediate build failures because various dependency packages are not installed, etc. That's good for raising awareness. The worst that happens with enabling everything as a default is with each such build "failure" developers and packagers have to disable those build options until they are happy.
Enabling all options as the default helps developers and packagers know what is going on. I don't think ccmake will help the same way the simple option of ./configure --help did. Enabling all build options as the default exposes everything immediately.
Or as Bruce mentions, some kind of stdout of which options are enabled and which are not.
This ties into a point I raised some time ago about quality assurance testing. We are the upstream supply for the Trinity sources. We don't have a quality assurance plan for developers and packagers to follow. When we don't test all the various build options then that reflects on us when others downstream use those options and the build fails. We need a way to test all build options and respective usability features.
An example of this shortfall is the problems people have building KOffice. GraphicsMagick is not a standard package installation in many distros and thus, is not tested by many people. Those who did install that package ran into build problems.
I'm more or less one of the "back breakers" who finds these types of bugs. That is what I do when I test Trinity packages. I enjoy doing that kind of work to help the project. :) I don't mind doing this kind of testing but we need a way to easily enable all build options.
Another thing that seem to commonly break with building packages is not looking in /usr/include subdirectories for header files. To me that should be automatic, whether or not cmake supports that by default.
Once in a blue moon I see this same problem in *.cpp and *.h files where a header include is hard-coded to /usr/include and has no if-then to look for a subdirectory.
Darrell
On Saturday 07 January 2012 06:12:51 Fat-Zer wrote:
2012/1/7 Darrell Anderson humanreadable@yahoo.com
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?
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.
This check is already exists in kdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/ConfigureChecks.cmake
-
Bruce Dubbs -
Calvin Morrison -
Darrell Anderson -
Fat-Zer -
Serghei Amelian -
Timothy Pearson