7 Jan
2012
7 Jan
'12
1:21 a.m.
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
7 Jan
7 Jan
1:37 a.m.
New subject: [trinity-devel] cmake options
2012/1/7 Darrell Anderson <humanreadable(a)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.
1:48 a.m.
New subject: [trinity-devel] cmake options
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?
4:12 a.m.
New subject: [trinity-devel] cmake options
2012/1/7 Darrell Anderson <humanreadable(a)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.
4:24 a.m.
New subject: [trinity-devel] cmake options
Fat-Zer wrote:
2012/1/7 Darrell Anderson
<humanreadable(a)yahoo.com>
Why make it a fatal error when it can be built without speex?
-- Bruce
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. 
5:11 a.m.
New subject: [trinity-devel] cmake options
Fat-Zer 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.
Tim
2012/1/7 Darrell Anderson
<humanreadable(a)yahoo.com>
Why make it a fatal error when it can be built without speex?
-- Bruce 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.
5:16 p.m.
New subject: [trinity-devel] cmake options
Timothy Pearson wrote:
> 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.
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
5:43 p.m.
New subject: [trinity-devel] cmake options
On Saturday 07 January 2012 19:16:43 Bruce Dubbs wrote:
Is not a drawback, is intentional. If you request speex, build system should
fail if is not found on your system.
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. 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:
--
Serghei
8:47 p.m.
New subject: [trinity-devel] cmake options
> 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:
9:04 p.m.
New subject: [trinity-devel] cmake options
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
10:16 p.m.
New subject: [trinity-devel] cmake options
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
10:44 p.m.
New subject: [trinity-devel] cmake options
On Sunday 08 January 2012 00:16:33 Darrell Anderson wrote:
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.
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).
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
--
Serghei
6:01 p.m.
New subject: [trinity-devel] cmake options
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.
Thanks!
Tim
> 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.
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.
6:38 p.m.
New subject: [trinity-devel] cmake options
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
--
Serghei
8:42 p.m.
New subject: [trinity-devel] cmake options
>>>
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 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
\
-DWITH_TIFF=ON
\
-DWITH_PAM=ON
\
-DBUILD_ALL=ON
\
-DBUILD_KAMERA=OFF
\
-DBUILD_KSVG=OFF
\
-DBUILD_KUICKSHOW=OFF
\
-DBUILD_LIBKSCAN=OFF
\
-DBUILD_KOOKA=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.
9:15 p.m.
New subject: [trinity-devel] cmake options
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
9:35 p.m.
New subject: [trinity-devel] cmake options
On 7 January 2012 16:15, Bruce Dubbs <bruce.dubbs(a)gmail.com> wrote:
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
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
failing
checks to simply disable the associated functionality as
Autotools does. If you want to see this please file an enhancement
bug report.
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
9:45 p.m.
New subject: [trinity-devel] cmake options
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
9:53 p.m.
New subject: [trinity-devel] cmake options
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
--
Serghei
10:06 p.m.
New subject: [trinity-devel] cmake options
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
10:49 p.m.
New subject: [trinity-devel] cmake options
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.
--
Serghei
10:11 p.m.
New subject: [trinity-devel] cmake options
> 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.
10:51 p.m.
New subject: [trinity-devel] cmake options
On Sunday 08 January 2012 00:11:15 Darrell Anderson wrote:
[...]
Actually I do not understand the problem. If you want to check all features,
enable they.
--
Serghei
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.
8 Jan
8 Jan
12:02 a.m.
New subject: [trinity-devel] cmake options
On Sunday 08 January 2012 00:11:15 Darrell Anderson
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
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.
12:39 a.m.
New subject: [trinity-devel] cmake options
On Sunday 08 January 2012 02:02:22 Timothy Pearson wrote:
[...]
ccmake should be enough.
--
Serghei
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
3:01 a.m.
New subject: [trinity-devel] cmake options
On Sunday 08 January 2012 02:02:22 Timothy Pearson
wrote:
[...]
ccmake should be enough.
How do I get a list of all TDE-specific CMake flags with that command?
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
7:51 p.m.
New subject: [trinity-devel] cmake options
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
7 Jan
7 Jan
9:42 a.m.
New subject: [trinity-devel] cmake options
On Saturday 07 January 2012 06:12:51 Fat-Zer wrote:
2012/1/7 Darrell Anderson
<humanreadable(a)yahoo.com>
This check is already exists in
kdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/ConfigureChecks.cmake
--
Serghei
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.
4495
days inactive
4496
days old
27 comments
6 participants
participants (6)
-
Bruce Dubbs -
Calvin Morrison -
Darrell Anderson -
Fat-Zer -
Serghei Amelian -
Timothy Pearson