Re: QT_NO_DEBUG, Q_ASSERT(), and release build types
Allen Winter wrote: I am undecided if kDebug+qDebug should be on for relwithdebinfo. I defer to the packagers on that one. qDebug should be off. kDebug, however, could be left on, but with all debug areas turned off. Applications should be silent in release mode (any release mode) unless the output is of interest to the user. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
Hello,
FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
not support Boost 1.37.0. You need to replace this line:
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.36.1
1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34 1.33.1
1.33.0 1.33 )
with
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.37.0
1.36.1 1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34
1.33.1 1.33.0 1.33 )
This is quite silly.
I fully agree but that's the way FindBoost.cmake is implemented in
CMake and several places in the KDE repository.
Parsing boost/version.hpp seems like the right way to do version
detection. From Boost 1.35.0 :
But how do you find that _easily_? Boost installs its headers into
prefix/include/boost-version/boost/, so we need the version to try to find
boost. The only way to avoid that is writing platform specific cmake code
that iterates for includedir/boost-* and checks in each one for a
boost/version.hpp. This would be quite a bit more code, as includedir is
different on each of the 3 major platforms.
IMNSHO we should either get Boost people to stop this insanity or just
better document that projects using FindBoost should set
Boost_ADDITIONAL_VERSIONS to a list of versions they know their project
builds with.
Andreas
--
You're a card which will have to be dealt with.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kdesupport-for-4.2 cmake error
On Sun, Jan 18, 2009 at 11:32 AM, Andreas Pakulat ap...@gmx.de wrote:
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.37.0
1.36.1 1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34
1.33.1 1.33.0 1.33 )
Or instead of that, simply _read_ the line and understand it. It also uses
a cmake variable which you can set before running find_package(), so
there's no need to patch FindBoost.cmake. The variable exists for a reason!
So in a year, after Boost 1.38.1, 1.38.0 and 1.37.1 are out, to make
FindBoost.cmake will work with CMake 2.6.2, I'll have to run cmake
-DBoost_ADDITIONAL_VERSIONS=1.38.1;1.38.0;1.37.1;1.37.0 ?
I'm sorry but I think that's not the proper way to do things. What's
the problem with parsing version.hpp? That will work forever, with no
need to specify Boost_ADDITIONAL_VERSIONS or update FindBoost.cmake
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
On Sun, Jan 18, 2009 at 11:28 AM, Andreas Pakulat ap...@gmx.de wrote:
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
Hello,
FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
not support Boost 1.37.0. You need to replace this line:
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.36.1
1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34 1.33.1
1.33.0 1.33 )
with
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.37.0
1.36.1 1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34
1.33.1 1.33.0 1.33 )
This is quite silly.
I fully agree but that's the way FindBoost.cmake is implemented in
CMake and several places in the KDE repository.
Parsing boost/version.hpp seems like the right way to do version
detection. From Boost 1.35.0 :
But how do you find that _easily_? Boost installs its headers into
prefix/include/boost-version/boost/, so we need the version to try to find
boost. The only way to avoid that is writing platform specific cmake code
that iterates for includedir/boost-* and checks in each one for a
boost/version.hpp.
FILE(GLOB ... ) and FILE( GLOB_RECURSE )... to the rescue! Using the
globbing expressions boost, boost-* and Boost-* would be
probably enough. Furthermore, you usually only have one version of
Boost installed, two or three tops, so FILE( GLOB/GLOB_RECURSE ...)
should not take long.
This would be quite a bit more code, as includedir is
different on each of the 3 major platforms.
FindBoost.cmake is already long enough (638 lines in CMake 2.6.2), so
a hundred more lines are not a problem, IMHO.
IMNSHO we should either get Boost people to stop this insanity
Good luck with that! On the other hand, this insanity allows for
different Boost versions to be co-installed.
or just
better document that projects using FindBoost should set
Boost_ADDITIONAL_VERSIONS to a list of versions they know their project
builds with.
The problem with that is when a new version is out.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
Andreas Pakulat schrieb:
On 17.01.09 20:09:44, Allen Winter wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
Hello,
FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
not support Boost 1.37.0. You need to replace this line:
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.36.1
1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34 1.33.1
1.33.0 1.33 )
with
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.37.0
1.36.1 1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34
1.33.1 1.33.0 1.33 )
This is quite silly.
You should tell that the boost people, who include these version numbers
into their libraries and include dirs. Making it pretty much impossible to
find boost.
We really should have a FindBoost that is smarter and doesn't need to be
updated each time a new Boost is released.
It doesn't, all you need to do is set Boost_ADDITIONAL_VERSIONS before
calling find_package. You can also view this as a good thing, because it
means the developers need to test-compile with a newer boost version. IIRC
kdevplatform doesn't build with newer boost, because boost broke some
backward compatibility.
Wow, FindBoost.cmake is one intense piece of CMake code.
Right and btw, why do we have our own FindBoost.cmake, the one in cmake
2.6.2 is good enough (AFAIK) and hence we should be using that one. Also in
akonadi (unless they want to support cmake 2.4).
The one in akonadi has been removed.
The one in 2.6.2 doesn't support ver 1.37, so it requires the use of the
ADDITIONAL_VERSIONS for the new ones.
Second part is that the include dir seems to be thought platform
specific (ll. 296). Guess how it is handled with KDE (of course it is
the same on windows too).
I had send a mail to cmake@ with a patch but it got eaten by the snowstorms.
Andreas
Patrick
--
web: http://windows.kde.org
mailing list:kde-wind...@kde.org
irc: #kde-windows (irc.freenode.net)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: QT_NO_DEBUG, Q_ASSERT(), and release build types
On Sunday 18 January 2009 4:04:33 am Thiago Macieira wrote: Allen Winter wrote: I am undecided if kDebug+qDebug should be on for relwithdebinfo. I defer to the packagers on that one. qDebug should be off. kDebug, however, could be left on, but with all debug areas turned off. Applications should be silent in release mode (any release mode) unless the output is of interest to the user. To summarize the changes: 1) disable asserts in release and relwithdebinfo 2) disable qDebug in release and relwithdebinfo 3) enable kDebug in release and relwithdebinfo if we can turnoff debug areas Andreas, does that just about cover it? Any objections to this plan? -Allen ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: QT_NO_DEBUG, Q_ASSERT(), and release build types
Andreas Hartmetz wrote: On Sunday 18 January 2009 16:52:29 Allen Winter wrote: On Sunday 18 January 2009 4:04:33 am Thiago Macieira wrote: Allen Winter wrote: I am undecided if kDebug+qDebug should be on for relwithdebinfo. I defer to the packagers on that one. qDebug should be off. kDebug, however, could be left on, but with all debug areas turned off. Applications should be silent in release mode (any release mode) unless the output is of interest to the user. To summarize the changes: 1) disable asserts in release and relwithdebinfo 2) disable qDebug in release and relwithdebinfo 3) enable kDebug in release and relwithdebinfo if we can turnoff debug areas Andreas, does that just about cover it? Any objections to this plan? I agree completely. Especially after talking to some people about it on IRC this looks like the right solution. It would be nice to be able to disable qDebug() at runtime but a) it's not possible and b) there are *very* few of them. Only if b) wasn't true I'd try to look for a solution for a). Technically, it is possible to disable ALL debugging at run-time, by installing a message handler in Qt. In any case, I remembered one more thing. This is more about code quality than build types, but since we're in the subject: all released code must NOT produce warnings, even in debug mode. In other words, KDE 4.2.0 should run with QT_FATAL_WARNINGS=1. (I know it doesn't and some apps would abort very early) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
On 18.01.09 12:50:32, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 11:28 AM, Andreas Pakulat ap...@gmx.de wrote:
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
Hello,
FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
not support Boost 1.37.0. You need to replace this line:
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.36.1
1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34 1.33.1
1.33.0 1.33 )
with
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.37.0
1.36.1 1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34
1.33.1 1.33.0 1.33 )
This is quite silly.
I fully agree but that's the way FindBoost.cmake is implemented in
CMake and several places in the KDE repository.
Parsing boost/version.hpp seems like the right way to do version
detection. From Boost 1.35.0 :
But how do you find that _easily_? Boost installs its headers into
prefix/include/boost-version/boost/, so we need the version to try to
find
boost. The only way to avoid that is writing platform specific cmake code
that iterates for includedir/boost-* and checks in each one for a
boost/version.hpp.
FILE(GLOB ... ) and FILE( GLOB_RECURSE )... to the rescue! Using the
globbing expressions boost, boost-* and Boost-* would be
probably enough. Furthermore, you usually only have one version of
Boost installed, two or three tops, so FILE( GLOB/GLOB_RECURSE ...)
should not take long.
The OP had 5 versions installed actually and in his case its even more
complicated, because with globbing you might find boost 1.34 and use that
(as the project works with that). That might or might not be ok for the
user...
This would be quite a bit more code, as includedir is
different on each of the 3 major platforms.
FindBoost.cmake is already long enough (638 lines in CMake 2.6.2), so
a hundred more lines are not a problem, IMHO.
I'd say that this wouldn't increase readability or understandability of
the module, but as only few people touch it thats probably true (i.e. not a
real problem).
IMNSHO we should either get Boost people to stop this insanity
Good luck with that! On the other hand, this insanity allows for
different Boost versions to be co-installed.
There are far better ways to do that.
or just
better document that projects using FindBoost should set
Boost_ADDITIONAL_VERSIONS to a list of versions they know their project
builds with.
The problem with that is when a new version is out.
Not really, if a project uses boost, one of its dev should _check_ that it
still works with the newer version (As I said in the other mail,
kdevplatform for example doesn't build with 1.37). And if he verified that,
he can simply commit the change.
IMHO you can't assume that your boost-using project will work just fine
with a newer version.
Andreas
--
There is a fly on your nose.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
On 18.01.09 23:33:21, Andreas Pakulat wrote:
On 18.01.09 12:50:32, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 11:28 AM, Andreas Pakulat ap...@gmx.de wrote:
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
Hello,
FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
not support Boost 1.37.0. You need to replace this line:
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.36.1
1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34 1.33.1
1.33.0 1.33 )
with
SET( _boost_TEST_VERSIONS ${Boost_ADDITIONAL_VERSIONS} 1.37.0
1.36.1 1.36.0 1.35.1 1.35.0 1.35 1.34.1 1.34.0 1.34
1.33.1 1.33.0 1.33 )
This is quite silly.
I fully agree but that's the way FindBoost.cmake is implemented in
CMake and several places in the KDE repository.
Parsing boost/version.hpp seems like the right way to do version
detection. From Boost 1.35.0 :
But how do you find that _easily_? Boost installs its headers into
prefix/include/boost-version/boost/, so we need the version to try to
find
boost. The only way to avoid that is writing platform specific cmake code
that iterates for includedir/boost-* and checks in each one for a
boost/version.hpp.
FILE(GLOB ... ) and FILE( GLOB_RECURSE )... to the rescue! Using the
globbing expressions boost, boost-* and Boost-* would be
probably enough. Furthermore, you usually only have one version of
Boost installed, two or three tops, so FILE( GLOB/GLOB_RECURSE ...)
should not take long.
The OP had 5 versions installed actually and in his case its even more
complicated, because with globbing you might find boost 1.34 and use that
(as the project works with that). That might or might not be ok for the
user...
This would be quite a bit more code, as includedir is
different on each of the 3 major platforms.
FindBoost.cmake is already long enough (638 lines in CMake 2.6.2), so
a hundred more lines are not a problem, IMHO.
I'd say that this wouldn't increase readability or understandability of
the module, but as only few people touch it thats probably true (i.e. not a
real problem).
IMNSHO we should either get Boost people to stop this insanity
Good luck with that! On the other hand, this insanity allows for
different Boost versions to be co-installed.
There are far better ways to do that.
or just
better document that projects using FindBoost should set
Boost_ADDITIONAL_VERSIONS to a list of versions they know their project
builds with.
The problem with that is when a new version is out.
Not really, if a project uses boost, one of its dev should _check_ that it
still works with the newer version (As I said in the other mail,
kdevplatform for example doesn't build with 1.37). And if he verified that,
he can simply commit the change.
IMHO you can't assume that your boost-using project will work just fine
with a newer version.
PS: Re-Reading my post I guess it didn't come across that, I don't object
adding some globbing to find version.hpp. I was just trying to point out
the possible problems that come with that approach.
Andreas
--
Don't tell any big lies today. Small ones can be just as effective.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FindBoost.cmake (Was: kdesupport-for-4.2 cmake error)
On Sun, Jan 18, 2009 at 11:33 PM, Andreas Pakulat ap...@gmx.de wrote: Parsing boost/version.hpp seems like the right way to do version detection. From Boost 1.35.0 : But how do you find that _easily_? Boost installs its headers into prefix/include/boost-version/boost/, so we need the version to try to find boost. The only way to avoid that is writing platform specific cmake code that iterates for includedir/boost-* and checks in each one for a boost/version.hpp. FILE(GLOB ... ) and FILE( GLOB_RECURSE )... to the rescue! Using the globbing expressions boost, boost-* and Boost-* would be probably enough. Furthermore, you usually only have one version of Boost installed, two or three tops, so FILE( GLOB/GLOB_RECURSE ...) should not take long. The OP had 5 versions installed actually and in his case its even more complicated, because with globbing you might find boost 1.34 and use that (as the project works with that). That might or might not be ok for the user... If you sort the result of FILE( GLOB ... ) so that the most recent version comes first (i. e. 1.37.0 in this case), globbing would not be any different from having a list of versions in FindBoost.cmake. This would be quite a bit more code, as includedir is different on each of the 3 major platforms. FindBoost.cmake is already long enough (638 lines in CMake 2.6.2), so a hundred more lines are not a problem, IMHO. I'd say that this wouldn't increase readability or understandability of the module, but as only few people touch it thats probably true (i.e. not a real problem). I'd say readability or understandability stopped being a problem in FindBoost.cmake a long time ago ;-) IMNSHO we should either get Boost people to stop this insanity Good luck with that! On the other hand, this insanity allows for different Boost versions to be co-installed. There are far better ways to do that. Given that CMake is being added as a new build system for Boost, my hopes are this would create and install some kind of UseBoost-version.cmake. or just better document that projects using FindBoost should set Boost_ADDITIONAL_VERSIONS to a list of versions they know their project builds with. The problem with that is when a new version is out. Not really, if a project uses boost, one of its dev should _check_ that it still works with the newer version (As I said in the other mail, kdevplatform for example doesn't build with 1.37). And if he verified that, he can simply commit the change. IMHO you can't assume that your boost-using project will work just fine with a newer version. The problem we face now is we do not even arrive that far in the checklist: 1. Write application 2. Find Boost - Here is were we fail now 3. Build my application with the found Boost version - Here is where we would fail if we parse version.hpp -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
phonon error when compiling kdebase
http://trac.macports.org/ticket/18080 It looks like x11 code needs to be disabled. QX11info isn't something we'd find on os x. Where's the proper placed to ask phonon? ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
FindBoostPython.cmake in kdeedu
Hi, while we're disussing the FindBoost.cmake - why is there a special FindBoostPython.cmake in kdeedu? Isn't this handled within FindBost? Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
FindPulseAudio.cmake
Hi all,
sorry for commiting the patch before discussing here.
Now i changed the file completle like the proposal from Alexander.
Please have a look on this.
Thanks
By
Marcus
FindPulseAudio.cmake
# Try to find the PulseAudio library
#
# Once done this will define:
#
# PULSEAUDIO_FOUND - system has the PulseAudio library
# PULSEAUDIO_INCLUDE_DIR - the PulseAudio include directory
# PULSEAUDIO_LIBRARY - the libraries needed to use PulseAudio
# PULSEAUDIO_MAINLOOP_LIBRARY - the libraries needed to use PulsAudio
Mailoop
#
# Copyright (c) 2008, Matthias Kretz, kr...@kde.org
# Copyright (c) 2009, Marcus Hufgard, marcus.hufg...@hufgard.de
#
# Redistribution and use is allowed according to the terms of the BSD
license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
if (NOT PULSEAUDIO_MINIMUM_VERSION)
set(PULSEAUDIO_MINIMUM_VERSION 0.9.9)
endif (NOT PULSEAUDIO_MINIMUM_VERSION)
if (PULSEAUDIO_INCLUDE_DIR AND PULSEAUDIO_LIBRARY AND
PULSEAUDIO_MAINLOOP_LIBRARY)
# Already in cache, be silent
set(PULSEAUDIO_FIND_QUIETLY TRUE)
endif (PULSEAUDIO_INCLUDE_DIR AND PULSEAUDIO_LIBRARY AND
PULSEAUDIO_MAINLOOP_LIBRARY)
if (NOT WIN32)
include(FindPkgConfig)
pkg_check_modules(PC_PULSEAUDIO libpulse=${PULSEAUDIO_MINIMUM_VERSION})
pkg_check_modules(PC_PULSEAUDIO_MAINLOOP libpulse-mainloop-glib)
endif (NOT WIN32)
FIND_PATH(PULSEAUDIO_INCLUDE_DIR pulse/pulseaudio.h
HINTS
${PC_PULSEADUIO_INCLUDEDIR}
${PC_PULSEADUIO_INCLUDE_DIRS}
)
FIND_LIBRARY(PULSEAUDIO_LIBRARY NAMES pulse libpulse
HINTS
${PC_PULSEAUDIO_LIBDIR}
${PC_PULSEAUDIO_LIBRARY_DIRS}
)
FIND_LIBRARY(PULSEAUDIO_MAINLOOP_LIBRARY NAMES pulse-mainloop
pulse-mainloop-glib libpulse-mainloop-glib
HINTS
${PC_PULSEAUDIO_LIBDIR}
${PC_PULSEAUDIO_LIBRARY_DIRS}
)
if (PULSEAUDIO_INCLUDE_DIR AND PULSEAUDIO_LIBRARY)
set(PULSEAUDIO_FOUND TRUE)
else (PULSEAUDIO_INCLUDE_DIR AND PULSEAUDIO_LIBRARY)
set(PULSEAUDIO_FOUND FALSE)
endif (PULSEAUDIO_INCLUDE_DIR AND PULSEAUDIO_LIBRARY)
if (PULSEAUDIO_FOUND)
if (NOT PULSEAUDIO_FIND_QUIETLY)
message(STATUS Found PulseAudio: ${PULSEAUDIO_LIBRARY})
if (PULSEAUDIO_MAINLOOP_LIBRARY)
message(STATUS Found PulseAudio Mainloop:
${PULSEAUDIO_MAINLOOP_LIBRARY})
else (PULSAUDIO_MAINLOOP_LIBRARY)
message(STATUS Could NOT find PulseAudio Mainloop Library)
endif (PULSEAUDIO_MAINLOOP_LIBRARY)
endif (NOT PULSEAUDIO_FIND_QUIETLY)
else (PULSEAUDIO_FOUND)
message(STATUS Could NOT find PulseAudio)
endif (PULSEAUDIO_FOUND)
mark_as_advanced(PULSEAUDIO_INCLUDE_DIR PULSEAUDIO_LIBRARY
PULSEAUDIO_MAINLOOP_LIBRARY)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
