Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Alexander Neundorf wrote:
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and ${CMAKE_SYSTEM_LIBRARY_PATH}?
cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
Well, if you have to use them when you write a FindFoo.cmake module, then maybe
they should be documented :)
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH and
CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure this
won't be forgotten it would be nice if you could file a bug report in the
cmake bugtracker for that.
Hmm. My old login failed to work. Grmbl. OK new account created...
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and
their
env. var equivalents) to the FIND_FILE() command in kdelibs/cmake/modules/.
If
that works fine we have to do the same in kdesupport/akonadi/ and phonon/.
Yes it works fine after copying FindAutomoc.cmake to phonon, please commit them
too.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the lib
install dir of automoc.
Works.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to all
your custom install prefixes.
Works too - nicer indeed.
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file, either
using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Yeah, I could also run moc by hand :-P
P.S. the issue here is that I try to find a file which is not a library in a
subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate, but
since it automatically adds prefixes and suffixes (lib and .so) that
doesn't work, so FIND_FILE() has to be used instead, and all paths where
FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
Not really, since ../lib can be ../lib64 or ../lib32, and in theory one doesn't
have to
set things up that way at all...
A more standard solution (except on windows) would be a pkgconfig file I
guess...
But I'm fine with the way it is now, thanks for the fix.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first and then go back and produce an approximation of it with find_file that is used for 2.4. That way the final design in a year when we require 2.6 is the right one and not a compatibility hack like the current foo_LIB_DEPENDS stuff. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Alexander Neundorf wrote: Hmm. My old login failed to work. Grmbl. OK new account created... Done, http://public.kitware.com/Bug/view.php?id=7146 I guess blogging about this once wasn't enough... ...how could anybody not remember all details from the blog of some KDE developer... Blogging? What's that? I don't have time to read blogs -and- mailinglists and fix kde bugs, sorry :) Hmm, techbase... Yes -- and of course the cmake documentation itself (added CMAKE_PREFIX_PATH to report 7146...) A more standard solution (except on windows) would be a pkgconfig file I guess... If you install automoc to a custom location, you would also have to adjust the PKGCONFIG_PATH (or what the name is) env. var, so it doesn't help for the basic issue. Sure it would need to be set, but it would help because it's more standard, so more commonly known ;) I already do this to PKG_CONFIG_PATH: headCat PKG_CONFIG_PATH $DBUSDIR/lib/pkgconfig headCat PKG_CONFIG_PATH $QTDIR/lib/pkgconfig headCat PKG_CONFIG_PATH /d/other/inst/icecream/lib/pkgconfig headCat PKG_CONFIG_PATH /d/other/inst/lib/pkgconfig # for qca headCat PKG_CONFIG_PATH /d/kde/inst/kdesupport_trunk/lib/pkgconfig :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, David Faure wrote:
On Tuesday 03 June 2008, Alexander Neundorf wrote:
BTW, what are ${CMAKE_SYSTEM_PREFIX_PATH} and
${CMAKE_SYSTEM_LIBRARY_PATH}? cmake --help-variable doesn't know them.
Hmm, maybe they are internal and intentionally undocumented.
Well, if you have to use them when you write a FindFoo.cmake module, then
maybe they should be documented :)
No, I just tried and it also doesn't say anything about CMAKE_PREFIX_PATH
and CMAKE_LIBRARY_PATH.
They are documented in the FIND_LIBRARY() documentation. To make sure
this won't be forgotten it would be nice if you could file a bug report
in the cmake bugtracker for that.
Hmm. My old login failed to work. Grmbl. OK new account created...
Ok, I added the missing paths (CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and
their env. var equivalents) to the FIND_FILE() command in
kdelibs/cmake/modules/. If that works fine we have to do the same in
kdesupport/akonadi/ and phonon/.
Yes it works fine after copying FindAutomoc.cmake to phonon, please commit
them too.
Will do.
So with cmake 2.4 you can now set the CMAKE_LIBRARY_PATH env. var to the
lib install dir of automoc.
Works.
With cmake 2.6 you can (and should) set the CMAKE_PREFIX_PATH env. var to
all your custom install prefixes.
Works too - nicer indeed.
I guess blogging about this once wasn't enough...
...how could anybody not remember all details from the blog of some KDE
developer...
Hmm, techbase...
Of course you can also manually set AUTOMOC4_CONFIG_FILE to the file,
either using -DAUTOMOC4_CONFIG_FILE or using cmake-gui.
Yeah, I could also run moc by hand :-P
P.S. the issue here is that I try to find a file which is not a library
in a subdir of the lib dirs, so FIND_LIBRARY() would be a good candidate,
but since it automatically adds prefixes and suffixes (lib and .so)
that doesn't work, so FIND_FILE() has to be used instead, and all paths
where FIND_LIBRARY() would search are added explicitely.
Maybe it would be easier to just use FIND_PROGRAM(automoc4) and then
check ../lib/automoc/ for the Automoc4Config.cmake file ?
Not really, since ../lib can be ../lib64 or ../lib32, and in theory one
doesn't have to set things up that way at all...
A more standard solution (except on windows) would be a pkgconfig file I
guess...
If you install automoc to a custom location, you would also have to adjust the
PKGCONFIG_PATH (or what the name is) env. var, so it doesn't help for the
basic issue.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Brad King wrote: David Faure wrote: On Tuesday 03 June 2008, Alexander Neundorf wrote: Hmm. My old login failed to work. Grmbl. OK new account created... Done, http://public.kitware.com/Bug/view.php?id=7146 I guess blogging about this once wasn't enough... ...how could anybody not remember all details from the blog of some KDE developer... Blogging? What's that? I don't have time to read blogs -and- mailinglists and fix kde bugs, sorry :) Hmm, techbase... Yes -- and of course the cmake documentation itself (added CMAKE_PREFIX_PATH to report 7146...) From cmake --help-command find_library: 1. Search cmake specific environment variables. ... prefix/lib for each prefix in CMAKE_PREFIX_PATH ... 2. Search cmake variables with the same names as the cmake specific environment variables. ... prefix/lib for each prefix in CMAKE_PREFIX_PATH ... ...and similarly for the other find_* commands. Yes. This is nice for the cmake-code-writer, but not for the cmake user, who doesn't know find_library is involved in the first place. If someone tells that user just set CMAKE_PREFIX_PATH, he's going to do cmake --help-variable CMAKE_PREFIX_PATH, like I did :) What's cmake --help-variable good for, if it doesn't have all useful variables? Well, == http://public.kitware.com/Bug/view.php?id=7146 :) KDE developers, always complaining, I know :) But at least phonon compiles now so I'm happy :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On 03.06.08 21:02:50, David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the PATHS
specified to find_library.
Is there a way to get check those paths first, then fallback to the default
paths behavior, without duplicating
all the default paths in the find_library call?
Yes there is, run find_library twice, first with NO_DEFAULT_PATH, then
without it. That way the directories that you list are preferred and you
can still easily search the standard system dirs if nothing is found in
the preferred dirs. Works because find_library doesn't search if the
variable it is supposed to fill is already filled with something that
doesn't end in -NOTFOUND.
Andreas
--
You will have a long and boring life.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Linker search path problems?
Hi, since some time (can't say wether its a week or two or a month), I'm getting this with latest CMake from 2.6 branch: WARNING: Cannot generate a safe linker search path for target kcm_access because there is a cycle in the constraint graph: dir 0 is [/home/andreas/kde4/lib] dir 2 must precede it due to link library [libphonon.so] dir 1 is [/home/andreas/qt-copy/lib] dir 2 is [/home/andreas/KDE-work/4.0/build/kdelibs/lib] dir 0 must precede it due to link library [libkdeui.so] WARNING: Cannot generate a safe runtime search path for target kcm_access because there is a cycle in the constraint graph: dir 0 is [/home/andreas/kde4/lib] dir 2 must precede it due to runtime library [libphonon.so.4] dir 1 is [/home/andreas/qt-copy/lib] dir 2 is [/home/andreas/KDE-work/4.0/build/kdelibs/lib] dir 0 must precede it due to runtime library [libkdeui.so.5] I recall you got similar errors a long time ago when one had qt-copy and a qt4-dev package installed at the same time. Do I need to worry? $HOME/qt-copy is qt-copy install path, $HOME/kde4 is kde4 install path and $HOME/KDE-work/4.0/build/foo is the builddir of module foo Andreas -- Don't hate yourself in the morning -- sleep till noon. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Linker search path problems?
On Tuesday 03 June 2008, Andreas Pakulat wrote: Hi, since some time (can't say wether its a week or two or a month), I'm getting this with latest CMake from 2.6 branch: WARNING: Cannot generate a safe linker search path for target kcm_access because there is a cycle in the constraint graph: dir 0 is [/home/andreas/kde4/lib] dir 2 must precede it due to link library [libphonon.so] dir 1 is [/home/andreas/qt-copy/lib] dir 2 is [/home/andreas/KDE-work/4.0/build/kdelibs/lib] dir 0 must precede it due to link library [libkdeui.so] Delete /home/andreas/KDE-work/4.0/build/kdelibs/lib/libphonon.so, it's old, phonon isn't in kdelibs anymore. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, Brad King wrote:
David Faure wrote:
From cmake --help-command find_library:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the
search.
This is in fact the reason why now kdelibs can't find phonon.
find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR}
${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR}
${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon
(correct syntax, right?)
doesn't work, because of the NO_DEFAULT_PATH. The reason why use
NO_DEFAULT_PATH almost everywhere
is simple: without it, libs in /usr/lib are preferred over those in the
PATHS specified to find_library.
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
This assumes that users specify all their lib locations as arguments. It's nice
to be able
to do that, but ideally things should just work out of the box, that's the
whole point
of that list of paths -- to try and autodetect where the stuff is installed, to
save the
user some work.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but maybe
it has
been installed into its own prefix instead. In the first case it should be
autodetected,
while in the latter case it's normal that the user has to specify a prefix --
but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting
the right
path manually!).
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
... as long as it finds that file in the first place, so I'm not sure this
changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...
Is there a way to get check those paths first, then fallback to the
default paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
On Tuesday 03 June 2008, you wrote: Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first Using just plain FIND_PACKAGE(Automoc4) (i.e. without extra FindAutomoc4.cmake) works, I checked that before. Do you mean that or something different ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Alexander Neundorf wrote: On Tuesday 03 June 2008, you wrote: Alexander Neundorf wrote: On Tuesday 03 June 2008, Brad King wrote: Finding lib/automoc4/Automoc4Config.cmake is the exact purpose of find_package(). The CMake 2.6 version is *much* more powerful than 2.4 and completely solves the problem. Please make sure that Automoc4Config.cmake is installed in a way that will work with find_package so that when CMake 2.6 is required it doesn't have to move. Yes, that works. But it also has to work with cmake 2.4, that's why I'm using that FIND_FILE() call. What I'm saying is that you should write it and get it working with find_package first Using just plain FIND_PACKAGE(Automoc4) (i.e. without extra FindAutomoc4.cmake) works, I checked that before. Do you mean that or something different ? That's all I meant. I just wanted to make sure. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
David Faure wrote:
On Tuesday 03 June 2008, Brad King wrote:
The issue here is that we (cmake devs) view the PATHS argument as a list
of last resort paths (e.g. hard-coding c:/Python25), not preferred
paths. There are a whole bunch of user-controlled places that are
searched before /usr/lib.
This assumes that users specify all their lib locations as arguments. It's
nice to be able
to do that, but ideally things should just work out of the box, that's the
whole point
of that list of paths -- to try and autodetect where the stuff is installed,
to save the
user some work.
The motivation behind our view is that users should be able to set
CMAKE_PREFIX_PATH and have CMake find things there first. Currently the
only way to override what the NO_DEFAULT_PATH stuff finds is to set the
result variable in the cache by hand for each and every library. If you
(as a project dev) want to look in a set of default locations on the
users' behalf, they should be added to the search path variables by the
project. Then none of the find_* commands needs special arguments, only
one call to each is needed, and users can override things easily.
If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
tell you where to find the library, why do you need to search for it in
default paths at all?
Because those are just hints. Maybe phonon is in the kde install dir, but
maybe it has
been installed into its own prefix instead. In the first case it should be
autodetected,
while in the latter case it's normal that the user has to specify a prefix --
but that doesn't
work because of NO_DEFAULT_PATH (which is only there so that the autodetection
prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting
the right
path manually!).
Okay, so follow the above advice:
find_package(FOO REQUIRED)
# Foo tells me where I might find other stuff.
list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})
find_library(BAR_LIBRARY NAMES bar)
# tada! BAR_LIBRARY is found under foo-prefix/lib
If the user specifies a custom CMAKE_PREFIX_PATH it will override what
FOO says. In practice the find_library will be in a find script or
something.
When CMake 2.6 is required everything should switch to using the
export/import feature:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
along with the full power of find_package and this issue should go away
completely. CMake will then just load a file that tells it exactly
where libraries are located (i.e. full paths to the library files).
... as long as it finds that file in the first place, so I'm not sure this
changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...
The idea is that that one file is found by find_package, which is
extremely powerful (more powerful than pkgconfig, in fact). It also
works well on Windows and OS X (with frameworks too).
Is there a way to get check those paths first, then fallback to the
default paths behavior, without duplicating
all the default paths in the find_library call?
Yes, and it's mentioned in the find_library documentation:
find_library(FOO_LIBRARY NAMES foo
PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)
Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)
We don't really want this done so it's okay if it's ugly. See above.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 from kdesupport now supported for building KDE
Brad King wrote: David Faure wrote: On Tuesday 03 June 2008, Brad King wrote: CMake will then just load a file that tells it exactly where libraries are located (i.e. full paths to the library files). ... as long as it finds that file in the first place, so I'm not sure this changes anything, in fact. Autodetection wanted when possible, manual setting of own prefix otherwise... The idea is that that one file is found by find_package, which is extremely powerful (more powerful than pkgconfig, in fact). It also works well on Windows and OS X (with frameworks too). Furthermore, the one file can tell CMake where to find all the libraries, headers, resources, etc. that come with the package. This avoids accidental mismatches of header files and libraries. Switching from one installation of the package to another requires only one cache variable to be changed. Unlike pkgconfig the one file can just be placed inside the package install tree instead of in a special location in the prefix. It can also do versioning (i.e. find version 4.1 of the package). -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs
On Thursday 29 May 2008, Dirk Mueller wrote: ... All fine for me, go ahead. I can help with fixing/testing it somewhen end of next week. Ok, done. On Tuesday 03 June 2008, Modestas Vainius wrote: Hi, Tuesday 03 June 2008, jūs rašėte: As discussed with Dirk, make the link interface empty by default, i.e. by default apps linking to libfoo won't be linked to the libs libfoo.so links against too anymore. Are you aware that we at Debian have already done this but to a lesser extent? Yes. (resetting all LINK_INTERFACE_LIBRARIES to empty is too drastic, imho). Setting them empty by default is the conclusion from my discussion with Dirk at LinuxTag. Anyway, checkout module/debian/patches/97_fix_target_link_libraries.diff patches from either [1] or [2]. For kdelibs, the patch is named 98_link_interface_libraries.diff. kdelibs 99_ patch adds more compatibility with previous recursive linking (only internal kdelibs stuff, which I believe can be dropped from link_interface_libraries). However, I think, kdelibs people should be consulted first before messing with their library targets. Yes. I think kde-buildsystem, Dirk and me count as kdelibs people. This is experimental for now and Dirk wants to give it a try. Then we can see what we do. All 97_fix_target_link_libraries.diff patches are supposed to work without kdelibs 99th patch applied. P.S. If you set LINK_INTERACE_LIBRARIES property for the specific target, it will have effect for linking inside the project even if experimental linking is not enabled (and when built with cmake 2.6 of course). 1. http://svn.debian.org/wsvn/pkg-kde/branches/kde4/packages 2. svn://svn.debian.org/svn/pkg-kde/branches/kde4/packages Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Linker search path problems?
On 03.06.08 21:30:11, David Faure wrote: On Tuesday 03 June 2008, Andreas Pakulat wrote: Hi, since some time (can't say wether its a week or two or a month), I'm getting this with latest CMake from 2.6 branch: WARNING: Cannot generate a safe linker search path for target kcm_access because there is a cycle in the constraint graph: dir 0 is [/home/andreas/kde4/lib] dir 2 must precede it due to link library [libphonon.so] dir 1 is [/home/andreas/qt-copy/lib] dir 2 is [/home/andreas/KDE-work/4.0/build/kdelibs/lib] dir 0 must precede it due to link library [libkdeui.so] Delete /home/andreas/KDE-work/4.0/build/kdelibs/lib/libphonon.so, it's old, phonon isn't in kdelibs anymore. That didn't help at all, not even after removing phonon from my install directory... Hmm, interesting my KDELibsDependenciesInternal.cmake in /usr/share/apps/cmake/modules contains references to my build/kdelibs directory. That is surely wrong. Hmm, interesting, the problem appears to be when one doesn't install Qt with Phonon and also not the Phonon from kdesupport. In that case kdelibs decides to use its old phonon and uses that, creating references to the builddir for some reason. Also kdebase builds with that phonon without problems - which is why I didn't yet install phonon from kdesupport. So there's an upgrade issue here, though its easily fixed by removing build+installdir (or related files if you know which ones). Another thing I just noticed during make install in kdebase is that I get a bit strange runtime paths: -- Set runtime path of /home/andreas/kde4/lib/kde4/kfontviewpart.so to /home/andreas/kde4/lib:/home/andreas/qt-copy/lib:/home/andreas/kde4/lib And the order of the qt-copy and the second kde4 paths change for some targets. Andreas -- Stay away from hurricanes for a while. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
