Re: Howto fix KDE4 Buildsystem with CMake CVS
On Wednesday 20 February 2008, Brad King wrote: Alexander Neundorf wrote: ... Shouldn't there be -L/opt/test2/lib/ included ? I have set both variables: set(CMAKE_LINK_OLD_PATHS TRUE) set(CMAKE_BACKWARDS_COMPATIBILITY 2.4) Am I missing something ? The -L options are added only if there are some -lfoo options. Otherwise they are useless anyway. I should have known that you would implement something more intelligent than just brute force :-) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Sunday 17 February 2008, Brad King wrote: Alexander Neundorf wrote: There is still the problem with OUTPUT_NAME which is a real bug. We can fix that in 2.6, but without another patch release to 2.4 that gets put in all the major distros you won't be able to depend on the fix anyway. You should probably use OUTPUT_NAME only on an executable target to give it the same name as a library. Then the library can export with the correct name. How was this all working with 2.4? Do the effects of CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that Actually I'd like to use the new style, since this will avoid the problems it is supposed to avoid :-) Whether CMAKE_LINK_OLD_PATHS is defined or not the full paths to known libraries are still given to the linker. The option only enables passing of their locations in -L paths for no reason but compatibility with projects that don't call LINK_DIRECTORIES properly. I just tried that and still got: Linking C executable hello /opt/cmake-HEAD/bin/cmake -E cmake_link_script CMakeFiles/hello.dir/link.txt --verbose=1 /usr/bin/gcc-fPIC CMakeFiles/hello.dir/main.o -o hello -rdynamic libfoo.so /opt/test2/lib/libkdefx.so -Wl,-rpath,/home/alex/src/tests/rpathtest/b2:/opt/test2/lib Shouldn't there be -L/opt/test2/lib/ included ? I have set both variables: set(CMAKE_LINK_OLD_PATHS TRUE) set(CMAKE_BACKWARDS_COMPATIBILITY 2.4) Am I missing something ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
Alexander Neundorf wrote: On Sunday 17 February 2008, Brad King wrote: Alexander Neundorf wrote: There is still the problem with OUTPUT_NAME which is a real bug. We can fix that in 2.6, but without another patch release to 2.4 that gets put in all the major distros you won't be able to depend on the fix anyway. You should probably use OUTPUT_NAME only on an executable target to give it the same name as a library. Then the library can export with the correct name. How was this all working with 2.4? Do the effects of CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that Actually I'd like to use the new style, since this will avoid the problems it is supposed to avoid :-) Whether CMAKE_LINK_OLD_PATHS is defined or not the full paths to known libraries are still given to the linker. The option only enables passing of their locations in -L paths for no reason but compatibility with projects that don't call LINK_DIRECTORIES properly. I just tried that and still got: Linking C executable hello /opt/cmake-HEAD/bin/cmake -E cmake_link_script CMakeFiles/hello.dir/link.txt --verbose=1 /usr/bin/gcc-fPIC CMakeFiles/hello.dir/main.o -o hello -rdynamic libfoo.so /opt/test2/lib/libkdefx.so -Wl,-rpath,/home/alex/src/tests/rpathtest/b2:/opt/test2/lib Shouldn't there be -L/opt/test2/lib/ included ? I have set both variables: set(CMAKE_LINK_OLD_PATHS TRUE) set(CMAKE_BACKWARDS_COMPATIBILITY 2.4) Am I missing something ? The -L options are added only if there are some -lfoo options. Otherwise they are useless anyway. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
Alexander Neundorf wrote:
There is still the problem with OUTPUT_NAME which is a real bug.
We can fix that in 2.6, but without another patch release to 2.4 that
gets put in all the major distros you won't be able to depend on the fix
anyway. You should probably use OUTPUT_NAME only on an executable
target to give it the same name as a library. Then the library can
export with the correct name.
How was this all working with 2.4? Do the effects of
CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that
Actually I'd like to use the new style, since this will avoid the problems it
is supposed to avoid :-)
Whether CMAKE_LINK_OLD_PATHS is defined or not the full paths to known
libraries are still given to the linker. The option only enables
passing of their locations in -L paths for no reason but compatibility
with projects that don't call LINK_DIRECTORIES properly. Don't let me
talk you out of doing it the right way though :)
What do you think about putting
LINK_DIRECTORIES(${LIB_INSTALL_DIR})
into the installed file from kdelibs ?
This sounds fine. Then when you switch to the new-style export in the
future your user projects won't have a bunch of extra link_directories
calls in them. What we've done for Kitware projects is have the config
file loaded after find_package has found the project just specify
everything in variables. One variable contains the name of a use file
that actually runs commands that affect the build (like link_directories
and include_directories). I don't see much of a problem with putting
the link_directories call directly in the code loaded by find_package to
avoid requiring extra code in user projects to load use files. I
suggest putting such code inside if conditions so users can block them
if desired:
if(NOT KDE4_NO_AUTO_LINK_DIRECTORIES)
link_directories(${KDE4_LIB_INSTALL_DIR})
endif(NOT KDE4_NO_AUTO_LINK_DIRECTORIES)
I could do this. How are the directories added via LINK_DIRECTORIES() handled
when determining the order of the directories, which should still be required
e.g. for the rpath ?
CMake 2.4:
The extra directories are included in the link directory set for
ordering along with the directories containing libraries known by full
path. A single ordering is computed for both -L paths and the RPATH
using the linkable library names.
CMake 2.6:
Ordering of directories is no longer done for -L paths since all
libraries whose full paths are known are passed directly as file paths
(and those for which the full path is not known cannot participate in
ordering). Ordering for RPATH computation works by taking the set of
known full paths to shared libraries by their *soname* and constructing
a safe order among all paths (both those containing libs and those
listed in link_directories). This should resolve problems like the one
last year with having to install a qt3-dev package just to get RPATH
ordering correct. It also means you can have as many extra link
directories as you want without affecting runtime loading of libraries
with known full path. The order of directories is preserved as much as
possible subject to constraints from known libraries.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Monday 28 January 2008, Brad King wrote:
Andreas Pakulat wrote:
On 28.01.08 16:04:06, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
Opinions? Better Ideas?
Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
After all we already have those variables, so we can avoid -lfoo
completely I think.
Its not quite that easy. The thing is that -lsolid is produced my
cmake's export_library_dependencies() function. So we'd have to find all
uses of all KDE_XXX_LIBS variables that include -lsolid and then add
KDE_SOLID_LIBS to the target_link_libraries() call.
And then again if compiling aborts with -lkparts or some other lib.
It looks like export_library_dependencies is misused a bit. The command
Yes, but I noticed that quite late (you showed me the intended way to use it I
think august last year) and at that time the KDE developers were already used
to using these variables, so I didn't change it anymore.
...
It is up to the project that calls export_library_dependencies to
produce a variable containing the link directory. The user project
should be able to do
find_package(XXX REQUIRED)
link_directories(${XXX_LIBRARY_DIRS})
target_link_libraries(myexe zot)
Getting all the lib dirs to CMAKE_SOURCE_DIR/CMakeLists.txt, where
export_library_dependencies() is called has two problems:
-everybody who uses not the project-default install dir has to remember that
he has to do something so that his dir also ends up in the installed file
-getting information from some subdir to the parent dir is hard (easier with
2.6)
I think having export_library_dependencies() really export the install
location of the libraries would be a good thing (in the 2.6 part of the
created file).
I just noticed that export_library_deps() doesn't respect the OUTPUT_NAME
property of a library, exporting the full install location would also fix
this problem:
add_library(foo foo.c)
set_target_property(foo PROPERTIES OUTPUT_NAME notfoo)
add_library(bar bar.c)
target_link_libraries(bar foo)
export_library_dependencies(deps.cmake)
will have foo in it, although no libfoo.so will exist, so a project which
uses that file will not work.
Can you have a look at that ?
I can try to come up with a patch, but you can fix this much faster.
If you want I can create a bug report for the OUTPUT_NAME bug.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
Alexander Neundorf wrote:
On Monday 28 January 2008, Brad King wrote:
It is up to the project that calls export_library_dependencies to
produce a variable containing the link directory. The user project
should be able to do
find_package(XXX REQUIRED)
link_directories(${XXX_LIBRARY_DIRS})
target_link_libraries(myexe zot)
Getting all the lib dirs to CMAKE_SOURCE_DIR/CMakeLists.txt, where
export_library_dependencies() is called has two problems:
-everybody who uses not the project-default install dir has to remember that
he has to do something so that his dir also ends up in the installed file
-getting information from some subdir to the parent dir is hard (easier with
2.6)
Kitware projects have done it this way for years. Instead of trying to
send information from the subdirs to the top we send it the other way.
The top directories configure the install locations and tell the child
dirs where to install. Then the locations are placed in the config file
to be loaded by user projects. It is a bit of work for the developer,
but that is how we did it and how the export_library_dependencies
command was meant to be used.
CMake 2.6 provides a much better alternative as discussed below.
I think having export_library_dependencies() really export the install
location of the libraries would be a good thing (in the 2.6 part of the
created file).
I don't think changing 2.6's export_library_dependencies command to use
full paths is the solution. It would only be redundant work for a
command I don't want people to use anymore (see below). The command
does not have access to the install locations of targets. The content
it produces was meant for use both from build trees and from install
trees. Changing it to use full install paths would break projects
depending on that capability (VTK, ITK, vxl, and ParaView at least).
Besides, how would someone using 2.6 to build their project deal with
kdelibs built and installed by 2.4? The paths would not be available.
How was this all working with 2.4? Do the effects of
CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that
means that some of the libraries were getting found and linked using
full paths. Otherwise the -L paths would not have been there before.
How are the full paths to some libraries getting passed to the user?
CMake 2.6 will provide full support for executables and libraries with
that install(EXPORT)/IMPORTED-target feature we designed last summer.
It is already working and tested in CMake HEAD.
I think the solution is to start using the new export/import feature
when 2.6 is released. As long as both the exporter and importer are
using 2.6 it will work well. If both are using 2.4 then the current
stuff can be used and will work as it does now. If the exporting
project is built with 2.6 and the importing project with 2.4 the current
approach should also continue to work. What remains is to try to
support exporting with 2.4 and importing with 2.6. For that case we
could just define CMAKE_LINK_OLD_PATHS in the old-style export.
Once this dual scheme is setup then you can start building pre-compiled
distributions with 2.6. Setup the installed config files to load the
new-style exports when the user uses 2.6 and the old-style exports when
the user uses 2.4. Then tell anyone that has too many problems with the
old-style exports to start using 2.6. Eventually when you drop support
for 2.4 you can just get rid of the old-style exports altogether.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Tuesday 29 January 2008, Andreas Pakulat wrote:
On 29.01.08 18:11:48, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
I must be blind. FindKDE4Internal.cmake already advertises
KDE4_LIB_DIR, so this is simply a matter of fixing the projects that
need to use link_directories( ${KDE4_LIB_DIR} ).
Can't we just do that in kde4_add_executable and kde4_add_library etc.?
Or is that too much hidden magic?
Its a global setting, like include_directories. IMHO we could just put
it into FindKDE4Internal, after all there's no point in finding KDE and
then not link to it...
No, we shouldn't add LINK_DIRECTORIES() somewhere global. We would do it only
for KDE4_LIB_DIR, but the same breakage can happen with just any other
library in any other dir.
Maybe we need to put that compatibility switch into KDE4Defaults.cmake or
something like this.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On 05.02.08 23:41:43, Alexander Neundorf wrote:
On Tuesday 29 January 2008, Andreas Pakulat wrote:
On 29.01.08 18:11:48, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
I must be blind. FindKDE4Internal.cmake already advertises
KDE4_LIB_DIR, so this is simply a matter of fixing the projects that
need to use link_directories( ${KDE4_LIB_DIR} ).
Can't we just do that in kde4_add_executable and kde4_add_library etc.?
Or is that too much hidden magic?
Its a global setting, like include_directories. IMHO we could just put
it into FindKDE4Internal, after all there's no point in finding KDE and
then not link to it...
No, we shouldn't add LINK_DIRECTORIES() somewhere global. We would do it only
for KDE4_LIB_DIR, but the same breakage can happen with just any other
library in any other dir.
So you want to add that to the top level CMakeLists.txt in each module?
(I've got patches at hand for what I have of trunk/) I'm using the
top-level CMakeLists.txt as thats also the place where most if not all
modules put the INCLUDE_DIRECTORIES(${KDE4_INCLUDE_DIR}) call.
Maybe we need to put that compatibility switch into KDE4Defaults.cmake or
something like this.
But isn't that global as well, i.e. inside a CMake module that gets
automatically loaded when you do find_package(KDE4)? At least thats what
I meant with global, put it into one of the files that get read as
soon as you search for KDE4.
Andreas
--
You have literary talent that you should take pains to develop.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Tuesday 05 February 2008, Andreas Pakulat wrote:
On 05.02.08 23:41:43, Alexander Neundorf wrote:
...
No, we shouldn't add LINK_DIRECTORIES() somewhere global. We would do it
only for KDE4_LIB_DIR, but the same breakage can happen with just any
other library in any other dir.
So you want to add that to the top level CMakeLists.txt in each module?
No, this shouldn't be used at all.
Because as I said, the same problem can not only happen for libraries which
are incidentially in KDE4_LIB_DIR, but also for any other libraries in any
other directories.
Additionally I think using LINK_DIRECTORIES() might mess with cmake library
searching/ordering mechanisms.
(I've got patches at hand for what I have of trunk/) I'm using the
top-level CMakeLists.txt as thats also the place where most if not all
modules put the INCLUDE_DIRECTORIES(${KDE4_INCLUDE_DIR}) call.
Maybe we need to put that compatibility switch into KDE4Defaults.cmake or
something like this.
But isn't that global as well, i.e. inside a CMake module that gets
automatically loaded when you do find_package(KDE4)?
Yes, but this would make it work for all directories, not only for
KDE4_LIB_DIR.
Additionally KDE4Defaults is not loaded automatically when you do
find_package(KDE4), it is loaded explicitely using include(KDE4Defaults), so
if somebody doesn't want these defaults he can simply skip using that file.
At least thats what I meant with global, put it into one of the files that
get read as soon as you search for KDE4.
I'll try to get a better picture of that problem, so we can come up with a
good solution for KDE (I had to catch up with over a week of emails...)
Bye
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On 06.02.08 00:00:55, Alexander Neundorf wrote:
On Tuesday 05 February 2008, Andreas Pakulat wrote:
On 05.02.08 23:41:43, Alexander Neundorf wrote:
...
No, we shouldn't add LINK_DIRECTORIES() somewhere global. We would do it
only for KDE4_LIB_DIR, but the same breakage can happen with just any
other library in any other dir.
So you want to add that to the top level CMakeLists.txt in each module?
No, this shouldn't be used at all.
Because as I said, the same problem can not only happen for libraries which
are incidentially in KDE4_LIB_DIR, but also for any other libraries in any
other directories.
Obviously, however as far as I understood with CMake 2.6 thats simply a
bug in the buildsystem of that library/app.
Additionally I think using LINK_DIRECTORIES() might mess with cmake library
searching/ordering mechanisms.
Uhm, well, according to Brad its the right thing to do, i.e. if you want
to use -lsolid (which we seem to want, or else we'd have to hardcode the
XXX_LIBS variables instead of using cmake for this) then you have to set
the link directory for this via LINK_DIRECTORIES.
(I've got patches at hand for what I have of trunk/) I'm using the
top-level CMakeLists.txt as thats also the place where most if not all
modules put the INCLUDE_DIRECTORIES(${KDE4_INCLUDE_DIR}) call.
Maybe we need to put that compatibility switch into KDE4Defaults.cmake or
something like this.
But isn't that global as well, i.e. inside a CMake module that gets
automatically loaded when you do find_package(KDE4)?
Yes, but this would make it work for all directories, not only for
KDE4_LIB_DIR.
Which other directories? There's no other link dir than KDE4_LIB_DIR,
except if you have extra libs in other modules used in yet another
module. So for example FindKDEPimLibs.cmake should export
KDE4_PIMLIBS_LIB_DIR or similar and all apps that want to link against
pimlibs need to do an link_directories(...).
Either that (and doing the same for KDE4_LIB_DIR, i.e. setting it in
each svn module's CMakeLists.txt) or putting the link_directories(
KDE4_PIMLIBS_LIB_DIR) into FindKDEPimLibs.cmake (and similarly for
KDE4_LIB_DIR).
Additionally KDE4Defaults is not loaded automatically when you do
find_package(KDE4), it is loaded explicitely using include(KDE4Defaults), so
if somebody doesn't want these defaults he can simply skip using that file.
Ah, ok.
At least thats what I meant with global, put it into one of the files that
get read as soon as you search for KDE4.
I'll try to get a better picture of that problem, so we can come up with a
good solution for KDE (I had to catch up with over a week of emails...)
No hurry, I've got the fixes locally so far and can continue to use
cmake cvs (as its s much faster for installing).
Andreas
--
You are taking yourself far too seriously.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Monday 28 January 2008, Andreas Pakulat wrote:
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
I must be blind. FindKDE4Internal.cmake already advertises KDE4_LIB_DIR,
so this is simply a matter of fixing the projects that need to use
link_directories( ${KDE4_LIB_DIR} ).
Can't we just do that in kde4_add_executable and kde4_add_library etc.?
Or is that too much hidden magic?
--
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
Howto fix KDE4 Buildsystem with CMake CVS
Hi, CMake CVS changed some behaviour in how it treats target_link_directories. Specifically it now doesn't -L switches to the linker call unless one explicitly calls link_directories() and sets the needed paths. This breaks building any module in KDE4 (except kdelibs) because we get some libraries with absolute path in the KDE_XXX_LIBS variables. Easiest way to reproduce is building kdelibs + kdepimlibs with cmake cvs. It will error out on linking kresources, because it doesn't find -lsolid. The linker line doesn't contain any -L switches, but some libraries like QtCore, kdecore and other are referenced with absolute paths which works. There are a couple of ways to fix this: a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add link_directories calls for kde libdir and qt libdir in all CMakeLists.txt all over trunk/. pro: clean solution con: takes quite some time and effort b) call link_directories for KDE libdir and Qt libdir in FindKDE4Internal. pro: also relatively clean con: needs adjustments still in FindKDEPimLibs and also FindKDevPlatform. Hides some things from the cmakefile-writer. c) set CMAKE_BACKWARDS_COMPATIBILITY to 2.4 or activate CMAKE_LINK_OLD_PATHS in FindKDE4Internal.cmake pro: works without any modifications anywhere else con: ugly workaround IMHO Opinions? Better Ideas? Andreas -- You will be Told about it Tomorrow. Go Home and Prepare Thyself. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On 28.01.08 16:04:06, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
Opinions? Better Ideas?
Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
After all we already have those variables, so we can avoid -lfoo completely I
think.
Its not quite that easy. The thing is that -lsolid is produced my
cmake's export_library_dependencies() function. So we'd have to find all
uses of all KDE_XXX_LIBS variables that include -lsolid and then add
KDE_SOLID_LIBS to the target_link_libraries() call.
And then again if compiling aborts with -lkparts or some other lib.
Hmm, maybe export_libraries_dependencies could just generate absolute
library paths instead of simply -l if the target is in the same cmake
project.
Andreas
--
Someone whom you reject today, will reject you tomorrow.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
Andreas Pakulat wrote:
On 28.01.08 16:04:06, David Faure wrote:
On Monday 28 January 2008, Andreas Pakulat wrote:
Opinions? Better Ideas?
Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
After all we already have those variables, so we can avoid -lfoo completely
I think.
Its not quite that easy. The thing is that -lsolid is produced my
cmake's export_library_dependencies() function. So we'd have to find all
uses of all KDE_XXX_LIBS variables that include -lsolid and then add
KDE_SOLID_LIBS to the target_link_libraries() call.
And then again if compiling aborts with -lkparts or some other lib.
It looks like export_library_dependencies is misused a bit. The command
creates a file that contains lines like
set(zot_LIB_DEPENDS bar;foo)
When this is loaded into an outside project, that project may then write
target_link_libraries(myexe zot)
and the link dependency analysis will see zot and load its
dependencies out of the zot_LIB_DEPENDS variable automatically. The
resulting link line will contain
... -lzot -lbar -lfoo ...
Note that there is no explicit reference to ${zot_LIB_DEPENDS} anywhere.
It is up to the project that calls export_library_dependencies to
produce a variable containing the link directory. The user project
should be able to do
find_package(XXX REQUIRED)
link_directories(${XXX_LIBRARY_DIRS})
target_link_libraries(myexe zot)
The XXX package should provide settings for XXX_LIBRARY_DIRS and
zot_LIB_DEPENDS. The latter may be provided by loading the file created
by export_library_dependencies.
The above is all documented in the Mastering CMake book with an
example of handling exactly this case.
Hmm, maybe export_libraries_dependencies could just generate absolute
library paths instead of simply -l if the target is in the same cmake
project.
I've actually been working on a new solution to this entire problem for
the last couple of weeks. CMake 2.6 will include the necessary
features. I haven't finished the documentation yet, but here is a taste
of what how things will work. The project exporting libraries will have
code like
add_library(mylib mylib.c)
install(TARGETS mylib DESTINATION lib EXPORT myexp)
install(EXPORT myexp DESTINATION lib/myproject)
Other projects will import libraries
find_package(XXX REQUIRED) # module loads lib/myproject/myexp.cmake
add_executable(myexe myexe.c)
target_link_libraries(myexe mylib)
Under the hood, the install(EXPORT) command creates and installs the
myexp.cmake file. It contains code like:
add_library(mylib IMPORTED)
set_target_properties(mylib PROPERTIES
IMPORTED_LOCATION /path/to/lib/libmylib.a)
Then when the file is included in the other project the IMPORTED target
mylib is created and can be referenced for linking like any other target.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
Andreas Pakulat wrote:
CMake CVS changed some behaviour in how it treats
target_link_directories. Specifically it now doesn't -L switches to the
linker call unless one explicitly calls link_directories() and sets the
needed paths.
I'll elaborate on this point. CMake's link line generation uses a new
approach to implement proper linking in more cases. Consider these
libraries:
/path/to/libfoo.a
/path/to/libfoo.so
Previously if someone wrote
target_link_libraries(myexe /path/to/libfoo.a)
CMake would generate this code to link it:
... -L/path/to -Wl,-Bstatic -lfoo -Wl,-Bdynamic ...
This worked most of the time, but some platforms (such as OS X) do not
support the -Bstatic or equivalent flag. This made it impossible to
link to the static version of a library without creating a symlink in
another directory and using that one instead.
Now CMake will generate this code:
... /path/to/libfoo.a ...
This guarantees that the correct library is chosen.
There is a side-effect of this fix. Projects used to be able to write
this (wrong) code and it would work by accident:
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so -lB)
where -lB is meant to link /path/to/libB.so. This code is incorrect
because it asks CMake to link to B but does not provide the proper
linker search path for it. It used to work by accident because the
-L/path/to would get added as part of the implementation of linking to
A. The correct code would be
link_directories(/path/to)
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so -lB)
or even better
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)
In order to support projects that have this bug, we've added a
compatibility feature that adds the -L/path/to paths for all libraries
linked with full paths even though the linker will not need those paths
to find the main libraries. The compatibility mode is enabled when a
link line contains a non-full-path library (like B or -lB) and either
CMAKE_BACKWARDS_COMPATIBILITY is set to 2.4 or lower or
CMAKE_LINK_OLD_PATHS is set to true.
This breaks building any module in KDE4 (except kdelibs) because we get
some libraries with absolute path in the KDE_XXX_LIBS variables. Easiest
way to reproduce is building kdelibs + kdepimlibs with cmake cvs. It
will error out on linking kresources, because it doesn't find -lsolid.
The linker line doesn't contain any -L switches, but some libraries like
QtCore, kdecore and other are referenced with absolute paths which
works.
This is correct. The -lsolid is an example of the problem I describe above.
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
pro: clean solution
con: takes quite some time and effort
In other projects we've used this approach.
find_package(XXX REQUIRED)
include_directories(${XXX_INCLUDE_DIRS})
link_directories(${XXX_LIBRARY_DIRS})
KDE is already using it for include directories:
include_directories( ${KDE4_KDEUI_INCLUDES} )
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Monday 28 January 2008, Andreas Pakulat wrote:
Opinions? Better Ideas?
Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
After all we already have those variables, so we can avoid -lfoo completely I
think.
PS: Thanks Brad for the explanation about the changes, seems very sensible
indeed.
--
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: Howto fix KDE4 Buildsystem with CMake CVS
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
I must be blind. FindKDE4Internal.cmake already advertises KDE4_LIB_DIR,
so this is simply a matter of fixing the projects that need to use
link_directories( ${KDE4_LIB_DIR} ).
I'm going to do that for the parts of trunk/ I have checked out.
Andreas
--
Be careful! UGLY strikes 9 out of 10!
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On 28.01.08 23:31:34, Andreas Pakulat wrote:
On 28.01.08 10:32:15, Andreas Pakulat wrote:
There are a couple of ways to fix this:
a) introduce KDE_XXX_LIBRARY_DIR (or KDE_LIBRARY_DIR) and add
link_directories calls for kde libdir and qt libdir in all
CMakeLists.txt all over trunk/.
I must be blind. FindKDE4Internal.cmake already advertises KDE4_LIB_DIR,
so this is simply a matter of fixing the projects that need to use
link_directories( ${KDE4_LIB_DIR} ).
Hmm, this leads to another question: Should we also add Qt's lib dir
using link_directories?
I mean currently export_libraries_dependencies provides the full path to
the Qt libs, but if that changes builds will break too...
I'm going to do that for the parts of trunk/ I have checked out.
I'll delay comitting this until we've got some more discussions wether
to fix this on individual files or somewhere in FindKDE4Internal.cmake
Andreas
--
Your present plans will be successful.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
