Re: setting policies centrally (was: cmCMakePolicyCommand: New PARENT_SCOPE argument)
On 08/15/2015 03:56 AM, David Faure wrote: Thanks for the suggestion, however I can't make it work. Am I doing it wrong? +set(CMAKE_POLICY_DEFAULT_CMP0063 NEW PARENT_SCOPE) # don't let cmake = 3.3 warn about the above It turns out the implementation of this variable is only handled at a cmake_minimum_required(VERSION) or cmake_policy(VERSION) call. That implementation is consistent with the documented use case for the variable (set by end users in local cache). Either of those calls sets the policy version level, meaning that any policy introduced by the named version or earlier gets set to NEW and all newer policies get left unset. The policy default variables are a way to not leave newer policies unset. Now that I remember this design, I think it was done this way intentionally so that setting these variables would not be a back door for setting policies. So, I think we are back to asking projects to explicitly allow an included module to set policies by using NO_POLICY_SCOPE. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
On 08/04/2015 08:42 AM, Brad King wrote: The compatibility model for policies is that the authors of a project should be aware of changes to CMake's preferred behavior before their project is affected by it. They indicate so by updating their own source to set the policy to NEW. If your dependents want to defer this decision to you and accept the risk of the broken compatibility model then they can include you with NO_POLICY_SCOPE. That is our model. That said, you may still be able to hack this without updating your dependents by setting CMAKE_POLICY_DEFAULT_CMP0063 to NEW: http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_POLICY_DEFAULT_CMP.html The variable is meant for end users to set in their local cache to quiet policy warnings without modifying the project. The variable documents that it should not be set by project code, but you could abuse it for your use case. Setting it won't override policy settings made by your dependents but can set the default when they don't set the policy at all. This still breaks our compatibility model, but it is an option you have. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
On 08/04/2015 04:19 AM, David Faure wrote: IMHO your logic is inconsistent with the fact that set(CMAKE_CXX_VISIBILITY_PRESET hidden) and set(CMAKE_VISIBILITY_INLINES_HIDDEN 1) are ** GLOBAL OPTIONS **, they are not limited to the project. They are not global options. They have directory scope. The authors of your dependents know you're setting some things for them when they include you, and can optionally isolate these effects by including you in a subdirectory. These dependents willingly ask you to set some things for them by including your central settings module. The compatibility model for policies is that the authors of a project should be aware of changes to CMake's preferred behavior before their project is affected by it. They indicate so by updating their own source to set the policy to NEW. If your dependents want to defer this decision to you and accept the risk of the broken compatibility model then they can include you with NO_POLICY_SCOPE. That is our model. But maybe this particular behavior change shouldn't be done with a policy then, but with another global variable. Policies are for when an old behavior is deemed incorrect (as was the lack of visibility settings for all target types). Over time projects will have cmake_minimum_required(VERSION) high enough to set the policy to NEW automatically, and then no one ever notices that the old behavior ever existed. This allows us to fix wrong behavior with no long term cost. A solution that requires a project to write set(DO_IT_RIGHT_THIS_TIME 1) to enable correct behavior forces all future projects to carry that extra setting around forever, and anyone writing a new project to know they need to set this every time. Policies provide a compatible transition path to getting correct behavior without extra per-case code in the long run. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/20/2013 04:31 PM, Alexander Neundorf wrote:
The keywords won't interact well with PUBLIC/PRIVATE/INTERFACE keywords.
Let's assume there would be only PRIVATE, INTERFACE_BUILD and
INTERFACE_INSTALL.
I'll use PRIVATE for building the target.
I'll add INTERFACE_BUILD if I want to make using this target within the
project easier.
I'll add INTERFACE_INSTALL if I want to make using this target when installed
easier.
Am I correct so far ?
No. The keywords are:
* PUBLIC = use for me and my dependents
* PRIVATE = use for me but not my dependents
* INTERFACE = use for my dependents but not me
For PUBLIC and INTERFACE the my dependents is then split into
dependents using me from the build tree and dependents using
me from the install tree.
So e.g. I could do
tid(hello
PRIVATE ${Foo_INCLUDE_DIRS} ${Bar_INCLUDE_DIRS} ${CMAKE_SOURCE_DIR}/blub
INTERFACE_BUILD ${CMAKE_SOURCE_DIR}/blub ${Bar_INCLUDE_DIRS}
INTERFACE_INSTALL ${INCLUDE_INSTALL_DIR} ${Bar_INCLUDE_DIRS} )
In which way would this be problematic ?
list(APPEND somelist INTERFACE_INSTALL ${y} INTERFACE_BUILD ${x})
...
tid(hello INTERFACE_INSTALL ${somelist} ${INCLUDE_INSTALL_DIR})
The genex approach binds tightly so this does not happen.
The PUBLIC/PRIVATE/INTERFACE information belongs in the tid() call
so those keywords should not be in lists. The BUILD/INSTALL
information belongs with each (path/directory) value so the genex
binds tightly to it and can be in lists.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/21/2013 02:47 PM, Alexander Neundorf wrote: Still, is the PUBLIC part necessary ? IMO PRIVATE and INTERFACE suffice, and for me it seems more straighforward to separate only between these two. PRIVATE and INTERFACE are sufficient but need to be duplicated to produce the equivalent of PUBLIC. It is very common for an implementation dependency to also be a usage requirement, especially for include paths. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/21/2013 04:47 PM, Alexander Neundorf wrote: At least for me it is also easier to differentiate between use this when building foo and use this when using foo vs. the three options. Then don't use PUBLIC in your code. Others have the opposite view. When something does need to be in both interfaces there is room for typos and bugs if it must be duplicated. That's why tll()'s LINK_PUBLIC/LINK_PRIVATE signature was added. Before that one had to populate LINK_INTERFACE_LIBRARIES separately. Often a new public library would be added to tll() and left out of LINK_INTERFACE_LIBRARIES accidentally. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/19/2013 04:02 PM, Alexander Neundorf wrote:
On Tuesday 19 March 2013, Stephen Kelly wrote:
I don't mind renaming it, but it's a topic for the cmake list.
So, I think the variable name CMAKE_BUILD_INTERFACE_INCLUDES is to general.
Since it is similar to the effect of CMAKE_INCLUDE_CURRENT_DIR, I suggest
renaming it e.g. to CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE.
The proposed name is much better. The old name was never in a final
release so it is easy to rename now:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc43477d
applies to both the BUILD and INSTALL include interfaces. To limit it to
one or the other, you have to specify it:
target_include_directories(foo INTERFACE
$BUILD_INTERFACE:/foo/interface/only
)
Why was this generator expression approach chosen over simply adding suitable
keywords, as it is done for all other cmake commands ?
target_include_directories(foo INTERFACE_BUILD ${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/whatever/
${CMAKE_CURRENT_BINARY_DIR}
INTERFACE_INSTALL ${INCLUDE_INSTALL_DIR} )
The keywords won't interact well with PUBLIC/PRIVATE/INTERFACE keywords.
Also the arguments are likely to be built up in lists:
target_include_directories(foo PUBLIC
${foo_INCLUDE_DIRS} ${other_INCLUDE_DIRS}
)
that may or may not contain multiple entries and multiple uses of each
$BUILD_INTERFACE:... and $INSTALL_INTERFACE:... expression.
The generator expressions bind tightly.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Adding logic to CMake for -fPIE and -fPIC
On 5/3/2012 12:02 PM, Stephen Kelly wrote:
* Make set(CMAKE_POSITION_INDEPENDENT_BINARIES True) set the appropriate flags.
This is the right choice IMO, though the variable should just
initialize a POSITION_INDEPENDENT target property. The target
property would then map to the right flag. You'll need to factor
out and generalize the CMAKE_SHARED_LIBRARY_${lang}_FLAGS platform
information variable:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Compiler/GNU.cmake;hb=v2.8.8#l24
currently used to add -fPIC to compilation of objects in shared
libraries. Make its use based on the new property, and simply
make the property true by default for shared libraries.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Strange commit to FindKDE4Internal.cmake
On 2/19/2012 5:53 PM, Pau Garcia i Quiles wrote: On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kellysteve...@gmail.com wrote: How would FindFoo.cmake know where to look? Exactly like it does know now: trial and error looking for the most common places. If it does not find the headers, libraries, etc, then it will report an error and the user will use cmake-gui to browse for the appropriate files/directories. Windows users are used to this. If relaying on a LibFooConfig.cmake, find_package will fail saying it didn't even find LibFooConfig.cmake, which is much worse IMHO. How is that different? In the Find module case the user needs to set FOO_INCLUDE_DIR for foo.h, FOO_LIBRARY for foo.lib, and perhaps others. In the package Config case the user needs only to set *one* FOO_DIR value to the location of a single file. Furthermore the find_package config mode already searches in the common prefixes for the package configuration file just like the find_library and find_path commands used in Find modules. On the CMake dev list we're currently discussing how to make the error message clearer when it is not found. Much of the trouble with it IMO is that it mentions the Find module case even when searching for a package Config file. Note that since CMake 2.8.5 we support a package registry: http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry so packages can be found even if their installers go to a random place so long as the installers populate the registry. Brad on the CMake list suggested that such files would belong in the documentation of libfoo (libfoo-doc package), which I thought was an interesting point (Or in any other documentation it could be a snippet). That's what I proposed at the beginning Great, then we agree. think it should be added to a /usr/share/cmake/Modules-like directory. But that place is *only* for official 3rd-party modules, not for, say, a libpng module provided by KDE. I also pointed out in the CMake list thread Stephen mentioned that there is no reason to even have a Find module for a CMake-aware package except to tweak find_package's search for the package configuration file (FooConfig.cmake). Even then it belongs in the -doc package. Even if a package upstream does not build with CMake it is still possible for it to provide a package configuration file for find_package to use, just like many projects provide pkgconfig .pc files. Stephen is doing this for Qt5 AFAIK. If a package upstream is not CMake-aware then the Find module should be contributed to CMake upstream. Otherwise there is no official Find module available from either CMake or the package upstream so it would not belong in your proposed official 3rd-party Modules directory anyway. If installed with the -dev package (even as a reference implementation or a template), it's kind of back to the situation of putting the treasure map with the treasure. I disagree. If it comes with the -dev package people think they should find and load it from there which as Stephen suggested is putting a treasure map with the treasure. If it comes with the -doc package then the documentation can tell them to put it in their project. Installing FindLibFoo.cmake with the -dev package means you a CMake module coming from the best possible author: upstream itself. This will still be the case if it comes with the -doc package. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Is this a problem with cmake or with my setup?
On 08/05/2010 03:41 PM, Alexander Neundorf wrote: On Wednesday 04 August 2010, Brad King wrote: Unfortunately implementing the TODO comment is non-trivial. CMake must first recognize shared library full-path file names from the link implementation list. Then for each shared library it finds it must also locate the full path to the file that will be loaded at runtime based on the *soname* of the library! In simple cases Wouldn't this mean to parse the ELF header, find all required shared libs, and look for them too? Perhaps, but at the point we do this we would have no more information than the linker would when it finds the library in the -rpath-link path. I think we would just have to stop here and hope it works. There is only so much we can do without the full dependency chain as imported targets. Also, I think you can't reliable figure out at build time which shared lib will be used at runtime. LD_LIBRARY_PATH may be set, /etc/ld.so.conf may be different, it could be executed on a different system, etc. True; I worded that poorly. We actually want to find the soname library file or symlink that the linker will load when creating the target. This is still a build-time thing. The path to the soname-ed file needs to be used in the analysis I described. The KHTML imported target *should* come with libphoton.so listed in the IMPORTED_LINK_DEPENDENT_LIBRARIES property. It does not right now because - libphoton.so was not imported as a target when khtml was built - CMake did not recognize it as a runtime dependency of khtml due to the lack of implementation at the above-mentioned TODO Hmm, wouldn't we still have a problem ? Qt has been built with phonon, and some parts of Qt most probably link against this phonon in qt/lib/. khtml has been linked against phonon in kdesupport/lib/, and we'd like to use that one, since it is newer. Yes. At runtime the dynamic linker may not be able to satisfy both Qt and khtml. But, if cmake would have the full information, i.e. that Qt would like to have the one in qt/lib/, and that khtml the one in kdesupport/lib/, wouldn't we get a conflict then ? Yes. It would generate a warning that no safe rpath-link search path can be computed. Is maybe the whole situation just a mess with phonon being built as part of Qt and also independent from it ? The problem is that there are two libphoton.so libraries with the same soname but that are not interface-compatible. If they had different soname values then the two separate libraries might be able to load into the same process. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [CMake] rpath problems with kdevplatform
Andreas Pakulat wrote: On 26.06.10 13:26:29, Andreas Pakulat wrote: Ping? Any further ideas on this? Could someone at least point me to the source code in cmake that decides wether to add RPATH_REMOVE or RPATH_REPLACE to the cmake_install.cmake file? Look at cmInstallTargetGenerator::AddChrpathPatchRule. Its job is to generate the install-time script to fix up the RPATH in the installed binary. The default is *no* RPATH, unless the INSTALL_RPATH target property is set: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:INSTALL_RPATH Elsewhere in this thread (at least on the kde list) you mention this seems to be working for some targets and not others. Look for where the INSTALL_RPATH gets set on the targets where it is working. Found it already, I've patched a cmake checkout here to give some diagnostic output and looking at the differences its apparent that for kdevplatform the installation prefix is not added to the OrderRuntimeSearchPath list in cmComputeLinkInformation, but this is done for kdevelop targets. This has nothing to do with RPATH_REMOVE or RPATH_CHANGE calls during installation. The only time this code would be used with install-tree information is during the relink step used on non-ELF platforms used to build a new RPATH into the binaries for installation. The reason seems to be that when building kdevplatform there are no libraries in the install-prefix that the to-be-built targets link against. So it seems that this is rather a cmake bug, hence I'm cc'ing to the cmake list (and including all the quotes). @CMake-List readers: Am I right that cmake simply should add the install-prefix to the ORderRuntimeSearchPath at some point during initialization? No, this is intentional behavior. CMake sets the RPATH up in the build tree to help the binary find its dependencies at runtime. If it does not link to anything in prefix/lib then there will be no RPATH entry for it. That should help in this case (I didn't test this yet) As I said above it won't affect the install tree. See the INSTALL_RPATH target property. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: [CMake] CMake 2.8.0 RC 4 ready for testing!
Alexander Neundorf wrote: On Tuesday 03 November 2009, David Faure wrote: Oh wow, that rocks. OK, the benefits clearly outweight the formatting change. Maybe the addfitional output could be skipped if ctest is run without -j ? At first I found the Start lines strange too, but after just a few days I got used to them. When running ctest -j 8 it feels much more responsive to see the Start lines pop up right away instead of waiting for tests to finish. The current behavior resulted after a long internal discussion during which many alternatives like the above were covered. I'd rather not repeat the whole thing here. The summary is that any alternative to the current behavior requires extra code paths which we do not want to implement or maintain. Eventually we'll have the interactive tty approach I described, and the problem will go away. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: [CMake] CMake 2.8.0 RC 4 ready for testing!
David Faure wrote: On Thursday 29 October 2009, Alexander Neundorf wrote: Hi, please give this RC4 of CMake 2.8.0 try, it is getting close to the final 2.8.0. OK, I switched to CMake-2-8 cvs branch today. Everything seems to go smoothly, no problems. Great, thanks for trying it. Just one cosmetic remark: why does the output of `make test` now look like this? Start 1: klocaletest 1/46 Test #1: klocaletest .. Passed0.08 sec Start 2: klocalizedstringtest 2/46 Test #2: klocalizedstringtest . Passed0.03 sec Start 3: kstandarddirstest 3/46 Test #3: kstandarddirstest Passed0.09 sec Start 4: kaboutdatatest 4/46 Test #4: kaboutdatatest ... Passed0.02 sec Start 5: kurltest 5/46 Test #5: kurltest .***Failed0.03 sec [...] I think this makes it harder to read (twice longer, with one line out of two saying nothing really interesting; the Start N: footest line seems useless). This is because we now support parallel testing: ctest -j 8 The problem is that we do not know the order in which tests will start or end. No partial lines can be printed. Originally we just printed output only when tests ended. However, that leaves no indication of what tests are currently running. If the first tests are long, there is no indication anything happens. In the future, we plan to solve this problem by detecting whether the output pipe is a tty. If not, then we can just write the ending lines and no start lines. If it is a tty then we can use escape sequences to keep pending tests listed on the bottom as each test finishes and a new one starts. All of this requires quite a bit of work to do cross-platform, so for now we just went with the starting lines. We purposely arranged the columns so that the most important information on the ending lines sticks out. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: dependency on generated header (Fwd: [Kde-dashboard] Failed trunk/kdesupport r1027553)
David Faure wrote: Can someone remind me how to add a dependency on a generated header? tplugins.cpp (from taglib-extras) includes taglib_export.h (from toplevel/taglib) which includes the generated taglib_config.h (in toplevel/taglib too), a common problem for all buildsystems; afaik there is no way to detect that dependency automatically, it needs to be specified explicitely; but how? If the header is supposed to be generated in another library or target than the one in which tplugins.cpp is built, just add a target-level dependency: # extras depends on the library api add_dependencies(tag-extras tag) If the header is generated in the same target, just list the header in the target's sources. -Brad -- Forwarded Message -- Subject: [Kde-dashboard] Failed trunk/kdesupport r1027553 Date: Thursday 24 September 2009 From: Dirk Mueller muel...@kde.org To: kde-dashbo...@kde.org Running kdesupport build-test for revision 1027553 architecture head-i586 failed with: Scanning dependencies of target tag-extras [ 97%] Building CXX object taglib-extras/taglib-extras/CMakeFiles/tag- extras.dir/tplugins.cpp.o In file included from kdesupport-1027553/taglib/include/taglib_export.h:1, from kdesupport-1027553/taglib-extras/taglib-extras/tplugins.cpp:29: kdesupport-1027553/taglib/include/../taglib/taglib_export.h:39:27: error: taglib_config.h: No such file or directory make[2]: *** [taglib-extras/taglib-extras/CMakeFiles/tag-extras.dir/tplugins.cpp.o] Error 1 make[1]: *** [taglib-extras/taglib-extras/CMakeFiles/tag-extras.dir/all] Error 2 make: *** [all] Error 2 --- ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: branches/KDE/4.3/kdelibs/nepomuk/core
David Faure wrote: Works indeed, fix committed. Great! -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: branches/KDE/4.3/kdelibs/nepomuk/core
David Faure wrote:
The first one only says:
# Create imported target KDE4__nepomuk
ADD_LIBRARY(KDE4__nepomuk SHARED IMPORTED)
while the second one says:
# Import target KDE4__nepomuk for configuration debugfull
SET_PROPERTY(TARGET KDE4__nepomuk APPEND PROPERTY IMPORTED_CONFIGURATIONS
DEBUGFULL)
SET_TARGET_PROPERTIES(KDE4__nepomuk PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUGFULL
/d/kde/src/4/qt-copy/lib/libQtCore.so;-lpthread;KDE4__kdecore;KDE4__kdeui;/d/kde/inst/kdesupport-for-4.3/lib/libsoprano.so
IMPORTED_LOCATION_DEBUGFULL /d/kde/inst/kde4/lib/libnepomuk.so.4.3.0
IMPORTED_SONAME_DEBUGFULL libnepomuk.so.4
)
I just tried this example:
---
add_library(jpeg SHARED IMPORTED)
set_property(TARGET jpeg APPEND PROPERTY
IMPORTED_CONFIGURATIONS DEBUGFULL
)
set_target_properties(jpeg PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUGFULL -lpthread;/usr/lib/libm.so
IMPORTED_LOCATION_DEBUGFULL /usr/lib/libjpeg.so.62.0.0
IMPORTED_SONAME_DEBUGFULL libjpeg.so.62
)
add_executable(foo foo.c)
target_link_libraries(foo jpeg)
---
I built with CMAKE_BUILD_TYPE=Debug and the link line for foo contains
... /usr/lib/libjpeg.so.62.0.0 -lpthread -lm
as expected. In other words, I cannot reproduce the problem in a simple
test case. Then I tried the real thing.
The problem is in kdepim/akonadi/resources/nepomuktag/CMakeLists.txt:
target_link_libraries(akonadi_nepomuktag_resource ... ${NEPOMUK_LIBRARIES})
It should be
target_link_libraries(akonadi_nepomuktag_resource ... ${KDE4_NEPOMUK_LIBS})
The imported target isn't even named otherwise, so of course its link
interface is not used.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: branches/KDE/4.3/kdelibs/nepomuk/core
Andreas Pakulat wrote: So maybe link-interface-libs really only works within the same cmake project (I've always wondered where cmake stores this information so that it works across projects)? The LINK_INTERFACE_LIBRARIES property for a target is recorded when the target is installed by install(TARGETS) with the EXPORT option. The EXPORT option associates the installation rule with a named export group. Later the install(EXPORT) command installs a .cmake file containing rules to create IMPORTED targets from their installed locations. See this page for details: http://www.cmake.org/Wiki/CMake_2.6_Notes The IMPORTED targets have IMPORTED_LINK_INTERFACE_LIBRARIES properties which contain their link interfaces. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: branches/KDE/4.3/kdelibs/nepomuk/core
Andreas Pakulat wrote:
On 26.06.09 12:56:09, Brad King wrote:
Andreas Pakulat wrote:
The cmake manpage pretty clearly explains what you're seeing here, the
_CONFIG versions correspond to the config of the project into which the
library is imported. Which totally makes sense, but also means you have to
build the whole stack with the same config option (which basically means
enforcing a limiation that comes from one platform onto all others)
We've already anticipated the case of importing from a project that
uses different configurations:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG
An imported configuration is chosen for a given local configuration
as follows:
1.) Check for MAP_IMPORTED_CONFIG_LOCAL property. If set, one of
the listed configurations must be available or it is not found.
2.) Check for an exact-match for the LOCAL configuration name.
3.) Accept any available imported configuration. The lack of any
MAP_IMPORTED_CONFIG_LOCAL property indicates any config is
acceptable.
Unfortunately the MAP_* properties must be set by the importing
project on every imported target. I needed to gain experience
with a real project facing this problem before designing a simple
way to set all these properties.
I don't think I can understand the reasoning for this being explicit
(except on windows where there's a real problem mixing libs from
differing configs).
Windows is a first-class platform for CMake.
Our interface must support all platforms.
Anyway, the mapping does not *have* to be explicit. The default
is to fall through to #3 and choose any available configuration.
We *permit* the explicit mapping for those that need to deal with
incompatible configurations.
The question in this thread is why don't all configurations just
follow #3 and accept DEBUGFULL? David: In your 'kdepim' source
try adding the code
get_property(loc TARGET KDE4__nepomuk PROPERTY LOCATION_DEBUG)
message(neopumk=[${loc}])
where KDE4__nepomuk is the name of the target on which that
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUGFULL property you posted
was set. What does it print?
Lets take KDevelop and the KDevPlatform module. The
latter has quite some libraries in it, one of them may link against
kdecore+kdeui+kfile and has all three of them in its link-interface
(because it actually has one symbol from kfile in one of the methods in
it). Now there's this plugin, it uses the library, but itself it only
uses symbols from that library, kdeui and kdecore. Hence it looks to be
fine, but a linker that is as strict as MSVC's or gold's will probably
complain about the missing kfile library when linking.
Hence this plugin would need to set the above mentioned variable on
Linux/Unix/Mac. Along with all other plugins and all other apps etc.
What does this have to do with imported configuration matching?
Your example appears to be asking about LINK_INTERFACE_LIBRARIES.
The link interface doesn't *have* to be set explicitly, and the
default is to include all the libraries to which a target links.
The link interface is an optimization to reduce dependencies.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Modular building of kde modules
Parker Coates wrote:
I've often wished CMake had a construct equivalent to Python's if
__name__ == '__main__' : that would let you run certain code only if
the current file was being run as the top level CMakeLists.txt.
if(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FILE(REMOVE) and FILE(APPEND) don't resolve relative filenames the same way
David Faure wrote: Testcase: macro(mymacro) FILE(REMOVE out) FILE(APPEND out hello\n) endmacro(mymacro) add_subdirectory(subdir) and in subdir/CMakeLists.txt: mymacro() mymacro() Expected result: only one line hello in the file subdir/out. Actual result: two lines hello in the file subdir/out. It looks like FILE(REMOVE out) uses the current dir of the macro (i.e. the toplevel) while FILE(APPEND out) uses the real current dir (subdir/). Is this a bug, or is it expected behavior? I'll play with the commands to get absolute paths in order to fix this for now... At one time we just required people to always use full paths, but around 2.4 we established the convention that relative paths are interpreted with respect to the location of the CMakeLists.txt file. It looks like file(REMOVE) was never taught this convention. However, don't you want this file to be manipulated in the *build* tree? That will require full paths anyway. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FILE(REMOVE) and FILE(APPEND) don't resolve relative filenames the same way
David Faure wrote:
= Before QT4_CREATE_MOC_COMMAND calls
FILE(REMOVE ${_moc_parameters_file}), could you make it check that
${_moc_parameters_file} is an absolute path and not a relative one,
since that's bound to fail and give unexpected results?
Please file a feature request in the bug tracker.
(And the reason for all this: there doesn't seem to be a way to generate
a foo.moc when foo.cpp defines a Q_OBJECT itself (rather than the header file)
and foo.cpp includes foo.moc. Well, kde4automoc handles this, but I'm abusing
this list to ask questions about a qt-only project ;) ). So I wrote this macro
macro(macro_included_moc cppfile)
GET_FILENAME_COMPONENT(_basename ${cppfile} NAME_WE)
SET(_moc ${CMAKE_CURRENT_BINARY_DIR}/${_basename}.moc)
qt4_generate_moc(${cppfile} ${_moc})
macro_add_file_dependencies(${cppfile} ${_moc})
endmacro(macro_included_moc)
Alternative solution: including kde4automoc into cmake. I know we discussed
it in the past and it was rejected, but this is another argument for it.
My boss wouldn't let me add it as dependency, he wanted an
off-the-shelf cmake solution: importing kde4automoc and integrating it
into the compilation properly sounded like a bit too much trouble
for a single cpp file that defined a Q_OBJECT...)
If every Qt project needs something like this, wouldn't it make more sense for
Qt itself to provide an executables with the capabilities of kde4automoc?
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake -E cmake_symlink_library fails without error message
Alexander Neundorf wrote: On Monday 02 March 2009, you wrote: On Monday 02 March 2009, Alexander Neundorf wrote: Can you please put this in the cmake bug tracker so it doesn't get lost ? I was hoping for a quick fix :-) Oh well -- http://public.kitware.com:80/Bug/view.php?id=8654 Well, I'm leaving for Cebit tomorrow in the morning and won't be back before sunday... I've fixed/closed the issue. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake -E cmake_symlink_library fails without error message
David Faure wrote:
On Monday 02 March 2009, Brad King wrote:
Alexander Neundorf wrote:
On Monday 02 March 2009, you wrote:
On Monday 02 March 2009, Alexander Neundorf wrote:
Can you please put this in the cmake bug tracker so it doesn't get lost ?
I was hoping for a quick fix :-)
Oh well -- http://public.kitware.com:80/Bug/view.php?id=8654
Well, I'm leaving for Cebit tomorrow in the morning and won't be back
before
sunday...
I've fixed/closed the issue.
That was quick indeed, thanks a lot ;)
I will test the fix once it's backported to CMake-2-6 branch
(which seems planned but not done yet).
Only Bill Hoffman can commit to the 2.6 branch. He commits to it only in
batches to create release candidates. I keep my changes in a private git
repo on a 2.6 tracking branch and send him patches when he does RCs.
My patch against 2.6 is below.
-Brad
commit e0a8bff0e2f278749c183debab4f25ba7191b0f0
Author: Brad King brad.k...@kitware.com
Date: Mon Mar 2 15:57:35 2009 -0500
BUG: Gracefully handle broken version symlinks
This teaches the helper commands 'cmake -E cmake_symlink_executable' and
'cmake -E cmake_symlink_library' to remove broken symlinks before
creating a symlink and report an error when the symlink cannot be
created. See issue #8654.
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 697eca6..d4a4f65 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -1363,24 +1363,28 @@ int
cmake::ExecuteCMakeCommand(std::vectorstd::string args)
if(soName != realName)
{
std::string fname = cmSystemTools::GetFilenameName(realName);
-if(cmSystemTools::FileExists(soName.c_str()))
+if(cmSystemTools::FileExists(soName.c_str()) ||
+ cmSystemTools::FileIsSymlink(soName.c_str()))
{
cmSystemTools::RemoveFile(soName.c_str());
}
if(!cmSystemTools::CreateSymlink(fname.c_str(), soName.c_str()))
{
+ cmSystemTools::ReportLastSystemError(cmake_symlink_library);
result = 1;
}
}
if(name != soName)
{
std::string fname = cmSystemTools::GetFilenameName(soName);
-if(cmSystemTools::FileExists(soName.c_str()))
+if(cmSystemTools::FileExists(name.c_str()) ||
+ cmSystemTools::FileIsSymlink(name.c_str()))
{
cmSystemTools::RemoveFile(name.c_str());
}
if(!cmSystemTools::CreateSymlink(fname.c_str(), name.c_str()))
{
+ cmSystemTools::ReportLastSystemError(cmake_symlink_library);
result = 1;
}
}
@@ -1395,12 +1399,14 @@ int
cmake::ExecuteCMakeCommand(std::vectorstd::string args)
if(name != realName)
{
std::string fname = cmSystemTools::GetFilenameName(realName);
-if(cmSystemTools::FileExists(realName.c_str()))
+if(cmSystemTools::FileExists(name.c_str()) ||
+ cmSystemTools::FileIsSymlink(name.c_str()))
{
cmSystemTools::RemoveFile(name.c_str());
}
if(!cmSystemTools::CreateSymlink(fname.c_str(), name.c_str()))
{
+ cmSystemTools::ReportLastSystemError(cmake_symlink_executable);
result = 1;
}
}
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Maciej Mrozowski wrote: On Thursday 18 of December 2008 20:31:42 Brad King wrote: Perhaps we can split it into multiple INSTALL(EXPORT) files. Then use a customized KDE4WorkspaceConfig.cmake file that loads multiple export files. The config file can check for each export file and provide it if it is available. Some boolean variables can be set to indicate what was found. [snip] results with: CMake Error: INSTALL(EXPORT libnepomukqueryclient ...) includes target nepomukqueryclient which requires target nepomukquerythat is not in the export set. How to handle such cases properly? Oops, in my proposal I didn't realize the libraries were interdependent. For some reason I was thinking they were all separate modules sharing a namespace. Currently there is no way to do this unless the builds are separated too (where each library exports itself for import by its dependents). The design of the automatic export file generation and installation was greatly simplified by enforcing the dependencies instead of having some mechanism for interdependent exports. I currently have no plans to support inter-dependent exports but it could be done in the future. Here are some other ideas: 1.) Write the export files by hand since they are for packages that always install to a specific location and always provide the same thing. This is not very maintainable though. 2.) Post-process the export file to divide up the import rules. I cannot guarantee the exact layout of these files will remain the same in future CMake versions though. 3.) Hack the export file to put if(EXISTS) around each import rule to check that the imported file exists. Perhaps in the future CMake could generate this automatically. I didn't consider it since the import rule is put in an export file that gets installed along with the target. In your case you have a packaging mechanism that splits the install tree up with more granularity than CMake knows. 4.) Keep the single export file but teach KDE4WorkspaceConfig.cmake to detect by some other means (existence of a mark file that comes with each package) whether each target is really available. Then set boolean variables or properties on the imported targets to indicate availability. Note that the import files are split into two parts. One part creates the imported targets and then loads the other part. The other part actually imports targets under a given configuration. #3 would be applied to the latter part. #4 can work because the former part always creates all the targets. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Maciej Mrozowski wrote:
3.) Hack the export file to put if(EXISTS) around each import rule to
check that the imported file exists. Perhaps in the future CMake could
generate this automatically. I didn't consider it since the import rule
is put in an export file that gets installed along with the target. In
your case you have a packaging mechanism that splits the install tree up
with more granularity than CMake knows.
Hmm, I don't understand the purpose .. to always install (somehow) those
exports and make them find libraries they 'represent'? Don't we have
FindXXX.cmake already for that purpose?
The FindXXX modules *search* for the packages. The whole point of the
export files is to *know* where to find libraries because they are
installed together. I'm proposing that the import rules say my library
would be here if it is installed. Basically each import rule would
look at its one known location to see if the library file exists before
reporting it.
4.) Keep the single export file but teach KDE4WorkspaceConfig.cmake to
detect by some other means (existence of a mark file that comes with
each package) whether each target is really available. Then set boolean
variables or properties on the imported targets to indicate availability.
Yeah, but that seems to be against of the goal to introduce out-of-the-box
library finding/importing.
Is there any way of forcing install (TARGETS EXPORT) or install (EXPORT)
without dependency information
Not currently. The dependencies must be known because otherwise there
is no way to report them when the targets are imported. Note that the
link dependencies for a shared library are needed even if the link
interface is empty (unfortunately it is needed for proper linking to the
shared lib on some platforms).
Consider:
add_library(foo SHARED foo.c)
add_library(bar SHARED bar.c)
target_link_libraries(bar foo)
set_property(TARGET bar PROPERTY LINK_INTERFACE_LIBRARIES )
install(TARGETS foo bar DESTINATION lib EXPORT myexp)
install(EXPORT myexp DESTINATION lib/myexp)
In the install tree the file
root/lib/myexp/myexp-release.cmake
contains the code
# Import target foo for configuration Release
SET_PROPERTY(TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
SET_TARGET_PROPERTIES(foo PROPERTIES
IMPORTED_LOCATION_RELEASE ${_IMPORT_PREFIX}/lib/libfoo.so
IMPORTED_SONAME_RELEASE libfoo.so
)
# Import target bar for configuration Release
SET_PROPERTY(TARGET bar APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
SET_TARGET_PROPERTIES(bar PROPERTIES
IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE foo # (*)
IMPORTED_LOCATION_RELEASE ${_IMPORT_PREFIX}/lib/libbar.so
IMPORTED_SONAME_RELEASE libbar.so
)
The line marked (*) needs to know both the name of the imported target
foo and that it exists. Linking to bar is not always possible
without it (even though foo is not in bar's link interface some linkers
want to find foo when linking to bar). If foo and bar appear in
separate exports then installed bar does not know about the installed
foo so it complains. This is why separating the exports would require
support for inter-dependent exports.
What you really want is to be able to install foo and bar in separate
packages, where bar's package depends on foo's, right? What if the
above import blocks were to appear in separate files so you could put
them in the separate packages? Each package would contain its library
and the corresponding piece of the export file. The file currently
holding the above blocks could instead do an optional include to load
the import rules for libraries that have been installed.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Alexander Neundorf wrote:
On Tuesday 09 December 2008, Brad King wrote:
Brad King wrote:
Brad King wrote:
Perhaps you can avoid this by using PATH_SUFFIXES on the inner
find_package call in your find-modules:
find_package(KFoo NO_MODULE PATH_SUFFIXES cmake)
Then you can just always install to cmake/kfoo. Once a version of
CMake supporting this location is required in the future this suffix
can be removed.
Oops, nevermind. The PATH_SUFFIXES get appended to each generated path,
not to each prefix.
I think you'll just have to require 2.6.3 if you want to move the files
from kfoo/cmake to cmake/kfoo.
No chance, it's not released yet, and people just complained enough that we
required 2.6.2, and we are about to freeze:
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule
Fortunately there is a pretty simple patch to 2.6.2 we can give to
distribution maintainers who want this to work to keep their system's clean.
I've included it below.
-Brad
diff -cp -r cmake-2.6.2-orig/Source/cmFindPackageCommand.cxx
cmake-2.6.2/Source/cmFindPackageCommand.cxx
*** cmake-2.6.2-orig/Source/cmFindPackageCommand.cxx2008-09-24
14:34:35.0 -0400
--- cmake-2.6.2/Source/cmFindPackageCommand.cxx 2008-12-18 09:09:25.0
-0500
*** cmFindPackageCommand::cmFindPackageComma
*** 218,223
--- 218,224
UNIX (U), or Apple (A) conventions.\n
prefix/ (W)\n
prefix/(cmake|CMake)/ (W)\n
+ prefix/(share|lib)/cmake/name*/ (U)\n
prefix/(share|lib)/name*/ (U)\n
prefix/(share|lib)/name*/(cmake|CMake)/ (U)\n
On systems supporting OS X Frameworks and Application Bundles
*** bool cmFindPackageCommand::SearchPrefix(
*** 1710,1715
--- 1711,1730
common.push_back(lib);
common.push_back(share);
+ // PREFIX/(share|lib)/cmake/(Foo|foo|FOO).*/
+ {
+ cmFindPackageFileList lister(this);
+ lister
+ / cmFileListGeneratorFixed(prefix)
+ / cmFileListGeneratorEnumerate(common)
+ / cmFileListGeneratorFixed(cmake)
+ / cmFileListGeneratorProject(this-Names);
+ if(lister.Search())
+ {
+ return true;
+ }
+ }
+
// PREFIX/(share|lib)/(Foo|foo|FOO).*/
{
cmFindPackageFileList lister(this);
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Alexander Neundorf wrote: On Thursday 18 December 2008, Brad King wrote: Fortunately there is a pretty simple patch to 2.6.2 we can give to distribution maintainers who want this to work to keep their system's clean. I've included it below. Hmm, but I can't test for it. Right now I do if(cmake = 2.6.3) install( to lib/cmake/foo) else install( to lib/foo/cmake) endif Which means that if somebody has built KDE with 2.6.3, then he needs 2.6.3 to build other software using it. I'm not sure this patch helps a lot. Or is it time for a 2.6.2.1 ? I meant that the distro maintainers could patch both CMake 2.6.2 and their KDE 4.2 package to tuck these things down in lib/cmake/foo. This just provides a way for distro maintainers to keep things clean for themselves without bumping requirements for anyone or rushing the 2.6.3 release. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Alexander Neundorf wrote: To have a KDE4WorkspaceConfig.cmake, you need to install it completely. YOu don't want to do it but instead do it separately. I think the correct solution would be to have separate FindKScreenSaver.cmake, FindKPlasmaSomething.cmake etc. files, and they could be installed additionally and used to the complete FindKDE4Workspace.cmake. So, IMO this would be correct and clean, but at the same time also some additional work. You could also use a modified (old-style) FindKDE4Workspace.cmake file, which does find_library() for all the different libs, and then you would have these libs set whioch have been actually found. I'm not sure what a good solution is. I would understand if you would say you wan to install e.g. libkhtml separately, for kdeworkspace I'm not sure it makes that much sense. I mean, it's just a few small libraries. Since this is for Gentoo packaging then if a piece of KDE4Workspace is installed we know where it will be. Perhaps we can split it into multiple INSTALL(EXPORT) files. Then use a customized KDE4WorkspaceConfig.cmake file that loads multiple export files. The config file can check for each export file and provide it if it is available. Some boolean variables can be set to indicate what was found. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Maciej Mrozowski wrote: On Tuesday 09 of December 2008 11:23:18 Modestas Vainius wrote: Okay, but then I wouldn't mind e.g. /usr/lib/kde4/cmake or something similar, just please do not pollute /usr/lib namespace directly. Likewise, pkg-config has /usr/lib/pkgconfig. In my opinion /usr/lib/cmake/ would be fine to place those files - even without creating subdirs inside like KdepimLibs and similar. Many projects have a /usr/lib/name[-version] directory containing platform-specific data for the package. Placement of the files near to the libraries in the installation is a *feature* of the find_package command. It avoids all problems with multiple installations and multiple versions. The command magically finds the files burried in the installation instead of in some central place which can have conflicts. Furthermore, the relative path from the config files to the libraries remains fixed no matter where the package is installed. This ensures that the locations reported by the file are correct with no special packaging or versioning work. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Modestas Vainius wrote: Hello, antradienis 09 Gruodis 2008, Brad King raĀe.: Many projects have a /usr/lib/name[-version] directory containing platform-specific data for the package. Some do, some do not. Placement of the files near to the libraries in the installation is a *feature* of the find_package command. /usr/lib/liba.so.1.0.0 /usr/lib/liba.so.1 /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake /usr/lib/libb.so.2.0.0 /usr/lib/libb.so.2 /usr/lib/libb.so /usr/lib/B/cmake/BConfig.cmake now multiply this by the number of libraries usually installed on the system. Sorry, but I call this /usr/lib pollution. You may not be violating FHS but you're sort of violating spirit of it. What saves the day a bit is that /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake can stay in the development package which end users usually do not have installed. It avoids all problems with multiple installations and multiple versions. It may be, but at least the current KDE solution does not support development stuff of multiple versions under the same prefix. The command magically finds the files burried in the installation instead of in some central place which can have conflicts. instead of prefix/(share|lib)/name*/(cmake|CMake)/ you can also search for prefix/(share|lib)/cmake/name*/ or prefix/(share| lib)/cmake/name*Config.cmake. No conflicts. Furthermore, the relative path from the config files to the libraries remains fixed no matter where the package is installed. Yeah, it also remains fixed if you use: /usr/lib/liba.so.1.0.0 /usr/lib/liba.so.1 /usr/lib/liba.so /usr/lib/cmake/A/AConfig.cmake or just /usr/lib/cmake/AConfig.cmake after s#/usr/lib/## liba.so.1.0.0 liba.so.1 liba.so cmake/A/AConfig.cmake or just cmake/AConfig.cmake Looks pretty fixed to me. So I really want find_package() to support /usr/lib/cmake search path as an alternative search path. Please give distributors a choice. When I first designed the find_package search procedure I proposed prefix/(share|lib)/cmake/name* (see http://www.cmake.org/Bug/view.php?id=3659, 2006-08-25 10:04) just as you suggest. The idea was that packages that already have a lib/name directory can put all their files together (including the cmake related files), but others can use lib/cmake/name* if they prefer. Later Alex convinced me that providing two places is confusing. I agree that cluttering /usr/lib with directories just for this one purpose is not pretty. I'll look at updating CMake to search the above locations too. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Brad King wrote: When I first designed the find_package search procedure I proposed prefix/(share|lib)/cmake/name* (see http://www.cmake.org/Bug/view.php?id=3659, 2006-08-25 10:04) just as you suggest. The idea was that packages that already have a lib/name directory can put all their files together (including the cmake related files), but others can use lib/cmake/name* if they prefer. Later Alex convinced me that providing two places is confusing. I agree that cluttering /usr/lib with directories just for this one purpose is not pretty. I'll look at updating CMake to search the above locations too. I've fixed this in CMake HEAD: /cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v -- Source/cmFindPackageCommand.cxx new revision: 1.52; previous revision: 1.51 We'll include it in the 2.6 release branch. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Alexander Neundorf wrote:
On Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Brad King raÅ”Ä:
I've fixed this in CMake HEAD:
/cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v --
Source/cmFindPackageCommand.cxx
new revision: 1.52; previous revision: 1.51
Thank you for such quick response and fix. Now I wish Alex could add
support for this path to KDE. /usr/lib/Kdepimlibs and
/usr/lib/KDE4Workspace currently contains only cmake stuff which are
found via
cmake/modules/Find{Kdepimlibs,KDE4Workspace}.cmake anyway. So it is easy to
workaround lack of native cmake support for this path in 2.6.2.
So we'll have to do something like:
if (${CMAKE_VERSION_MAJOR}.${CMAKE_VERSION_MINOR}.${CMAKE_VERSION_PATCH}
VERSION_GREATER 2.6.2)
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo)
else ()
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo/cmake)
endif ()
Unfortunately the version of CMake that is doing the *finding* needs to
be higher than 2.6.2 in order for the cmake/kfoo path to work. The
version doing the installing does not matter. Often they will be the
same cmake, but sometimes not.
Perhaps you can avoid this by using PATH_SUFFIXES on the inner
find_package call in your find-modules:
find_package(KFoo NO_MODULE PATH_SUFFIXES cmake)
Then you can just always install to cmake/kfoo. Once a version of CMake
supporting this location is required in the future this suffix can be
removed.
Should we include the version number ?
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo-x.y.z/cmake)
or perhaps
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo-x.y.z)
? Anyway, yes, I think the version number should be on the directory.
This will help support multiple KDE versions in the same prefix. Even
if that is not a design goal, having the version number in the path does
not affect CMake's ability to find the package. It may also give more
information when helping users remotely.
Brad: is this version number considered when specifying a minimum version for
the package or is it ignored and only a fooVersion.cmake file will be used ?
The latter. The directory name is purposely and completely ignored (for
various reasons I'll omit here). The FooConfigVersion.cmake files are
the only way to enforce version constraints.
I think you should put the version files in now. If an installation
doesn't have one, then versioned requests will not find anything because
there is no version file to say it supports a particular version. Once
you have installations distributed like this it will be hard to add
versioning later.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Brad King wrote: Brad King wrote: Perhaps you can avoid this by using PATH_SUFFIXES on the inner find_package call in your find-modules: find_package(KFoo NO_MODULE PATH_SUFFIXES cmake) Then you can just always install to cmake/kfoo. Once a version of CMake supporting this location is required in the future this suffix can be removed. Oops, nevermind. The PATH_SUFFIXES get appended to each generated path, not to each prefix. I think you'll just have to require 2.6.3 if you want to move the files from kfoo/cmake to cmake/kfoo. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Brad King wrote: Perhaps you can avoid this by using PATH_SUFFIXES on the inner find_package call in your find-modules: find_package(KFoo NO_MODULE PATH_SUFFIXES cmake) Then you can just always install to cmake/kfoo. Once a version of CMake supporting this location is required in the future this suffix can be removed. Oops, nevermind. The PATH_SUFFIXES get appended to each generated path, not to each prefix. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: another cmake problem on osx
Boudewijn Rempt wrote: With Brad's patch, I can compile again -- and it does fix another thing, namely the endless stream of CMake Warning at /Users/boudewijn/src/kde/ins/share/apps/cmake/modules/KDE4Macros.cmake:570 (add_library): Cannot generate a safe linker search path for target xsltimport because files in some directories may conflict with libraries in implicit directories: link library [libxml2.dylib] in /usr/lib may be hidden by files in: /opt/local/lib link library [libz.dylib] in /usr/lib may be hidden by files in: /opt/local/lib link library [libbz2.dylib] in /usr/lib may be hidden by files in: /opt/local/lib Some of these libraries may not be found correctly. Call Stack (most recent call first): filters/xsltfilter/import/CMakeLists.txt:11 (kde4_add_plugin) messages I had before. However, now the linking path seems wrong. Most dependencies come from macports in my case and are located in /opt/local/lib. This used to be no problem, but now the -L/opt/local/lib line is missing, which gives linker errors, first in kdebase: Linking CXX shared module ../../../lib/exrthumbnail.so ld: library not found for -lIlmImf collect2: ld returned 1 exit status make[2]: *** [lib/exrthumbnail.so] Error 1 Are there any other warnings produced by CMake, such as CMP0003? Try running make VERBOSE=1 and post the actual link line that fails. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: another cmake problem on osx
Boudewijn Rempt wrote: On Wed, 26 Nov 2008, Brad King wrote: Are there any other warnings produced by CMake, such as CMP0003? No... Try running make VERBOSE=1 and post the actual link line that fails. Linking CXX shared module ../../../lib/exrthumbnail.so cd /Users/boudewijn/src/kde/bld/kdebase/runtime/kioslave/thumbnail /usr/local/bin/cmake -E cmake_link_script CMakeFiles/exrthumbnail.dir/link.txt --verbose=1 /usr/bin/c++ -fno-common -Woverloaded-virtual -g3 -fno-inline -bundle -headerpad_max_install_names -multiply_defined suppress -o ../../../lib/exrthumbnail.so CMakeFiles/exrthumbnail.dir/exrthumbnail_automoc.o CMakeFiles/exrthumbnail.dir/exrcreator.o -L/Users/boudewijn/src/kde/ins/lib /Users/boudewijn/src/kde/ins/lib/libkio.5.2.0.dylib -lIlmImf -lz -lImath -lHalf -lIex -lIlmThread /Users/boudewijn/src/kde/ins/lib/libkdeui.5.2.0.dylib -F/usr/local/Trolltech/Qt-4.4.3/lib -framework QtSvg /Users/boudewijn/src/kde/ins/lib/libkdecore.5.2.0.dylib -F/usr/local/Trolltech/Qt-4.4.3/lib -framework QtDBus -F/usr/local/Trolltech/Qt-4.4.3/lib -framework QtCore -lpthread -framework Carbon -F/usr/local/Trolltech/Qt-4.4.3/lib -framework QtNetwork -F/usr/local/Trolltech/Qt-4.4.3/lib -framework QtXml -F/usr/local/Trolltech/Qt-4.4.3/lib -framework QtGui /Users/boudewijn/src/kde/ins/lib/libsolid.4.2.0.dylib ld: library not found for -lIlmImf collect2: ld returned 1 exit status make[2]: *** [lib/exrthumbnail.so] Error 1 make[1]: *** [runtime/kioslave/thumbnail/CMakeFiles/exrthumbnail.dir/all] Error 2 make: *** [all] Error 2 If I tack a -L/opt/local/lib to that line, it works. What CMakeLists.txt code adds IlmImf? -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
Alexander Neundorf wrote: On Tuesday 25 November 2008, Benjamin Reed wrote: On Wed, Nov 19, 2008 at 5:27 PM, Marijn Kruisselbrink [EMAIL PROTECTED] wrote: When I try to compile any module other than kdelibs on Mac OSX, I get lots and lots of CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdecore, and similar lines. Fortunately cmake still manages to generate correct Makefiles, but it still is annoying. Is this something that is wrong in our usage of cmake, or I can confirm this issue with the 4.1.80 packages that were just released on the packaging list as well -- kdepimlibs errors out as well. I've made a minimal test-case (attached). Is this really minimal ? Based on possible paths in source code, I've produced this minimal test case that does not depend on KDE: cmake_minimum_required(VERSION 2.6) project(FOO C) add_library(foo SHARED IMPORTED) add_executable(bar bar.c) target_link_libraries(bar foo) install(TARGETS bar DESTINATION bin) The problem is created only on Mac. It is when CMake constructs the install_name_tool call for target 'bar' to try to map the install_name embedded in 'bar' to look for 'foo'. The code that does this incorrectly assumes 'foo' is a non-imported target. I'm looking into a fix. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
Brad King wrote: The problem is created only on Mac. It is when CMake constructs the install_name_tool call for target 'bar' to try to map the install_name embedded in 'bar' to look for 'foo'. The code that does this incorrectly assumes 'foo' is a non-imported target. I'm looking into a fix. Okay, the solution is to just ignore imported targets to which 'bar' links. Their install_name will not change anyway. /cvsroot/CMake/CMake/Source/cmInstallTargetGenerator.cxx,v -- Source/cmInstallTargetGenerator.cxx new revision: 1.67; previous revision: 1.66 We'll include this in the 2.6 branch. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Weird cmake 'errors'
Marijn Kruisselbrink wrote: When I try to compile any module other than kdelibs on Mac OSX, I get lots and lots of CMake Internal Error (please report a bug) in CMakeLists.txt: GetLibraryNamesInternal called on imported target: kdecore, and similar lines. Fortunately cmake still manages to generate correct Makefiles, but it still is annoying. Is this something that is wrong in our usage of cmake, or is cmake 2.6.2 (and cmake cvs trunk) just broken on Mac OSX? CMake is expected to work on OSX. Your usage is exposing a problem with CMake. We did not expect that line to get hit. Does the message have any context information? Where does it appear in the CMake output? Can you please try to strip this down to a minimal example? Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMAKE_CONFIGURATION_TYPES considered harmful
Manuel Sput Nickschas wrote:
Hi guys,
we at Gentoo have recently discovered that KDE's packages always use the
Debugfull configuration for installation:
-- Install configuration: Debugfull
This happens also if CMAKE_BUILD_TYPE=Release. We have hunted down that
issue and traced it back to FindKDE4Internal.cmake line 1033:
set (CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} Debugfull)
That should be more like
if(CMAKE_CONFIGURATION_TYPES)
list(APPEND CMAKE_CONFIGURATION_TYPES Debugfull)
endif(CMAKE_CONFIGURATION_TYPES)
While in theory and according to cmake docs this should just add the
additional build configuration to a list of existing ones, in reality this
adds Debugfull to an empty list, since CMake does not set this variable
(anymore? Dunno if that was always the case...). This results in CMake always
installing Debugfull, since it's set to be the only valid type.
The variable is used by the IDE generators like VS and Xcode which have
multiple configurations in a single build tree. It should not be set
for Makefile generators.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMAKE_CONFIGURATION_TYPES considered harmful
Alexander Neundorf wrote:
On Wednesday 05 November 2008, Brad King wrote:
Manuel Sput Nickschas wrote:
...
While in theory and according to cmake docs this should just add the
additional build configuration to a list of existing ones, in reality
this adds Debugfull to an empty list, since CMake does not set this
variable (anymore? Dunno if that was always the case...). This results in
CMake always installing Debugfull, since it's set to be the only valid
type.
The variable is used by the IDE generators like VS and Xcode which have
multiple configurations in a single build tree. It should not be set
for Makefile generators.
So you would recommend checking the generator over setting
CMAKE_CONFIGURATION_TYPES to CMAKE_BUILD_TYPE initially ?
This is what I was about to do:
if (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE RelWithDebInfo)
set(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
${CMAKE_BUILD_TYPE} )
endif (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
The way to identify whether a generator is multi-configuration is to
check whether CMAKE_CONFIGURATION_TYPES is set. The VS/XCode generators
set it (and ignore CMAKE_BUILD_TYPE). The Makefile generators do not
set it (and use CMAKE_BUILD_TYPE). If CMAKE_CONFIGURATION_TYPES is not
already set, don't set it.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Preference for finding a kde module
Alexander Neundorf wrote: On Thursday 02 October 2008, Andreas Pakulat wrote: On 01.10.08 18:18:07, Brad King wrote: ... Ok, then I guess I'll opt for the config-mode of FindFoo.cmake, unless Alex comes up with a compelling reason not to do that (like bugs in CMake 2.6.0)... When having a small FindFoo.cmake wee can add additional output, better error messages in case it hasn't been found, maybe support for special environment variables, etc. So it enables us to tweak it a bit. Yes. In this case, the small FindFoo would consist of a call like find_package(Foo NO_MODULE) which would proceed in config-mode instead of loading the same module again. This call could be surrounded by more configuration options and messages, but these are not critical. If an application wants the nicer find interface it can have a copy of FindFoo (or get one from an already-found dependency). Otherwise at least finding will work without it. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Preference for finding a kde module
Andreas Pakulat wrote: On 01.10.08 23:59:51, Alexander Neundorf wrote: Yes, I think your third option is what I would prefer: the package installs a FooConfig.cmake file with all the necessary information and macros, and then we need only a quite simple FindFoo.cmake to find and load this file. Leaves me with two questions: a) a simple find_file( FooConfig.cmake )+include( FooConfig.cmake ) is what you mean with simple FindFoo.cmake? Why not leave that to cmake and instead uses the Config-Mode of find_package? The intention of the find_package config-mode is to avoid FindFoo.cmake altogether. b) If FindFoo.cmake is to be used, should this be installed by the module Foo, or the modules Bar+Baz should both have a copy (or preferably move the copies to a common dependency)? If one is provided it should be copied into each project that needs to find the module, or distributed with a common dependency such as kdelibs or CMake. This is the reason I created the config-mode of find_package, so that no modules need to be distributed to find Foo. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake v2.6.1 Segfault
Allen Winter wrote:
more info..
(you may recall I had this crash before)
I narrowed the crash down to this call:
FILE(RPATH_CHECK
FILE $ENV{DESTDIR}/data/kde/lib/kde4/kontact_summaryplugin.so
RPATH /data/kde/lib:/data/kde/lib:/usr/local/lib)
If I remove /data/kde/lib/kde4/kontact_summaryplugin.so and start over -- no
crash.
I will send that kontact_summaryplugin.so to whoever might want it for
debugging purposes.
I think I already fixed this in CMake HEAD from CVS. Can you try a
2.6.2 release candidate?
http://www.cmake.org/files/v2.6/
Thanks,
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH with multiple empty paths (e.g., ::::::::)
Dirk Mueller wrote: On Sunday 03 August 2008, Gavin Beatty wrote: A lot of KDE libraries are being given strange RPATHs. I'm getting link lines giving this: installed or uninstalled libraries? for uninstalled that's normal, cmake reserves some space in the binary to be able to fill in the correct path during installation without relinking (which is somewhat slower). if it breaks your scripts (it breaks mine), -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON If someone can tell me how to reserve space in the RPATH entry through standard linker interfaces and without creating bogus paths, I would love to use it. Until then, this is the only option to avoid relinking. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH with multiple empty paths (e.g., ::::::::)
Thiago Macieira wrote: On Monday 04 August 2008 15:13:38 Brad King wrote: If someone can tell me how to reserve space in the RPATH entry through standard linker interfaces and without creating bogus paths, I would love to use it. Until then, this is the only option to avoid relinking. There isn't one, not without help from binutils guys. But the point is: this kind of paths shouldn't appear in final, installed binaries. Gavin hasn't replied yet if that was the case. Can we approach the GNU binutils people? They seem to be very friendly when it comes to suggestions. Sure. It shouldn't be too hard to implement because I can easily create what I want by linking with the :: and then applying a second step which replaces all those characters with '\0' bytes. However, that approach doesn't work for people whose ld tools check the RPATH immediately. We just need a flag that says how many extra zero bytes should be allocated. Are you volunteering, or asking me to do approach them? -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Patch for KDE4Macros to use extra target on Windows
Matthias Kretz wrote: On Friday 18 July 2008 23:38:45 Brad King wrote: Can someone point me to discussion of the original problem, please? I think most of this was in german and private mail. So here's a summary: Okay, thanks. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Patch for KDE4Macros to use extra target on Windows
Matthias Kretz wrote: attached is a patch to use the new automoc macro which adds a new target per default on Windows. Can someone point me to discussion of the original problem, please? This is all I've found: http://mail.kde.org/pipermail/kde-buildsystem/2008-May/004711.html Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
David Faure wrote: The -L parameters are definitely generated, by cmake. The question is how. And the answer is complex AFAIK, and depends on the cmake version. In CMake 2.4 the set of -L paths come from arguments to the link_directories() command and the locations of libraries given to target_link_libraries() by full path. In CMake 2.6 the latter case is usually handled just by passing the full path to the library file directly to the linker with no searching, but there are still some cases where it behaves similarly to 2.4. The input to the ordering algorithm is the original list of user-specified library search paths (given to link_directories) plus some set of library file full paths. The output is an ordered linker search path. We try to preserve the original order of user-specified directories, but the main rule is that the order is such that the libraries whose full paths are known will be found first if the linker searches for them with a -lfoo option. This guarantees that when a library is specified by full path that the copy of the library is favored over any other copy of the library at another place in the linker search path. CMake actually inspects all the linker search path locations to look for possibly conflicting files and builds a constraint graph. A topological sort on the resulting constraint graph produces the order. The order among an unconstrained group of paths is that in the original user-specified order. This is done much more formally in CMake 2.6 than in 2.4. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake Find Modules, HINTS, and NO_DEFAULT_PATH
Alexander Neundorf wrote:
On Monday 09 June 2008, Brad King wrote:
Hi Folks,
...
The solution I've committed to CMake HEAD in CVS is to distinguish
hint paths from guess paths. For compatibility the PATHS option
must continue to mean guess. I've added a new HINTS option that is
interpreted as hint paths. This allows the above code to be written
find_library(FOO_LIB foo HINTS ${BAR_TOLD_ME_FOO_MIGHT_BE_HERE})
The provided hint is preferred over system locations but not over the
cmake-specific user environment variables or cache entries. I've
already converted most of the Find* modules provided by CMake to take
advantage of this feature.
Nice :-)
Thanks.
Minor nitpicking: how about naming that PREFERRED_PATHS instead of HINTS ?
This may make the meaning even clearer without having to read the docs.
IMO the name HINTS is concise and exactly names the purpose of the
paths it lists...they are hints we got from something else. Ken Martin
and I considered several names before choosing it. The word PREFERRED
begs the question how strongly preferred? which requires reading the
docs anyway.
Given its semantics, a better name for the PATHS option would be
GUESS or GUESSES, but I don't want to add confusion by changing
existing options.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
CMake Find Modules, HINTS, and NO_DEFAULT_PATH
Hi Folks,
In response to this discussion:
http://mail.kde.org/pipermail/kde-buildsystem/2008-June/004747.html
http://mail.kde.org/pipermail/kde-buildsystem/2008-June/004744.html
I've committed some find_* command changes in CMake to make the search
order more intuitive (specific-to-general). An explanation of the
changes is below.
I'd appreciate if some of you try CMake HEAD from CVS to see if
everything works as expected and that no existing KDE projects break.
When all is well with the changes we'll merge them for inclusion in a
CMake 2.6 patch release. Then when KDE bumps the required version to
2.6 this feature will be available to its Find* modules.
Consider the call
find_library(FOO_LIB foo PATHS /some/hard/coded/path)
This hard-coded path is just a *guess* and should be used only as a last
resort. This is why CMake favors system library locations over the
PATHS option. On the other hand the call:
find_library(FOO_LIB foo PATHS ${BAR_TOLD_ME_FOO_MIGHT_BE_HERE})
provides a path that should be preferred over the system path because it
is more specific. Currently CMake does not distinguish this case and
still prefers the system paths. As a work-around, many Find* modules
are using a two-call approach:
find_library(FOO_LIB foo PATHS ${BAR_TOLD_ME_FOO_MIGHT_BE_HERE}
NO_DEFAULT_PATH)
find_library(FOO_LIB foo)
The problem with this is that it prevents users from being able to
override the *hint* that is provided by ${BAR...} by setting
CMAKE_PREFIX_PATH. Also, we (cmake authors) would prefer people not use
NO_DEFAULT_PATH unless the provided PATHS are known to contain the library.
The solution I've committed to CMake HEAD in CVS is to distinguish
hint paths from guess paths. For compatibility the PATHS option
must continue to mean guess. I've added a new HINTS option that is
interpreted as hint paths. This allows the above code to be written
find_library(FOO_LIB foo HINTS ${BAR_TOLD_ME_FOO_MIGHT_BE_HERE})
The provided hint is preferred over system locations but not over the
cmake-specific user environment variables or cache entries. I've
already converted most of the Find* modules provided by CMake to take
advantage of this feature.
As suggested by David Faure, I've also flipped the order of
CMAKE_PREFIX_PATH (and related variables) so that the setting from the
cache (or command line) is preferred over the environment version. The
new order is now
1.) CMAKE_PREFIX_PATH from cmake variable (typically on command line)
2.) CMAKE_PREFIX_PATH from environment (typically in ~/.bashrc)
3.) HINTS option listed in command
4.) PATH or LIB or other common system environment variables
5.) CMAKE_SYSTEM_PREFIX_PATH from cmake variable
6.) PATHS option listed in command
-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
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
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
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: problem with cmake 2.6RC6 and KDE 4
Dirk Mueller wrote: On Monday 14 April 2008, Brad King wrote: Okay, it doesn't matter how to reproduce it. The fix is the same. I've updated to RC9, and got a new problem: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file RPATH_CHANGE could not write new RPATH: /opt/kde-41/lib to the file: /opt/kde-41/bin/kde4automoc No valid ELF RPATH entry exists in the file; Call Stack (most recent call first): cmake/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:45 (INCLUDE) This is the *exact* same problem as before. The error message is just more verbose. Now I need to know how to reproduce it. What source tree do I need to checkout? Please also send me the CMakeCache.txt from the build tree, plus the cmake/automoc/cmake_install.cmake file, and /opt/kde-41/bin/kde4automoc, and the kde4automoc from the build tree. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Benjamin Reed wrote: On Tue, Apr 15, 2008 at 1:26 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Does it now also work with Brads fix and without local modifications ? Hm, nope. With CMake CVS as of Apr 15 14:10 EST, I still get the error cmake'ing kdebase: CMake Error at apps/kwrite/CMakeLists.txt:6 (install): install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable target kwrite. Did you try Alex's small test case with the CMake you built? Are you 100% sure the new CMake is in use for kdebase? You can grep for CMAKE_COMMAND in the CMakeCache.txt at the top of the build tree to see which one is used. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Christian Ehrlicher wrote: Benjamin Reed schrieb: On Tue, Apr 15, 2008 at 1:26 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Does it now also work with Brads fix and without local modifications ? Hm, nope. With CMake CVS as of Apr 15 14:10 EST, I still get the error cmake'ing kdebase: CMake Error at apps/kwrite/CMakeLists.txt:6 (install): install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable target kwrite. Why not add your fix for cmake 2.6 only? The goal is to debug CMake 2.6 to support all existing projects without modification (but perhaps with warnings). After that you can fix KDE to build without the warnings. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
Dirk Mueller wrote: I've switched to cmake 2.6 for dashbot (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file CHRPATH could not write new RPATH /opt/testing/lib to the file /var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc: No valid ELF RPATH entry exists in the file; CMake 2.6 comes with an ELF binary parser. It is used to change the RPATH or RUNPATH of an existing binary before installation. This is much faster than relinking with a new RPATH as was done by CMake 2.4 (relinking is still used on non-ELF systems). Alex originally added this feature using the chrpath tool. I updated it to use a builtin parser. how can I get rid of that? this is KDE trunk, configured with: cmake -DKDE4_BUILD_TESTS=ON -DCMAKE_INSTALL_PREFIX=/opt/testing -DCMAKE_BUILD_TYPE=release Add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to switch back to the relinking approach. a slightly related and annoying note: for some projects (e.g. strigi) it writes an empty rpath into the binaries during installation instead of removing the rpath. that breaks certain checks and is dangerous, as some ld.so versions interpret empty as current directory which allows trivially to hijack applications by e.g. adding a hacked libc.so.6 to the start up directory. Ugh, I didn't know that about ELF linkers. IMO that's pretty stupid because users can always put '.' in the RPATH if they want that behavior. The builtin CHRPATH support in CMake, and AFAICT the chrpath tool itself, just locates the RPATH string entry in the binary and overwrites it with the new RPATH, possibly empty. It has only read support for the DYNAMIC section and its string table. For now I'll change CMake to use relinking when the installed rpath is empty. Later we can look at adding support to remove the RPATH entry from an existing binary. Do you know any safe way to remove the RPATH entry without changing the binary size? Is it safe to just swap the DT_RPATH or DT_RUNPATH entry to the end of the dynamic section and replace it with DT_NULL (and replace the rpath string with all 0 bytes)? -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
Dirk Mueller wrote: I've switched to cmake 2.6 for dashbot (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file CHRPATH could not write new RPATH /opt/testing/lib to the file /var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc: No valid ELF RPATH entry exists in the file; I'm having trouble reproducing this. If CMake sees that the installed file should have an RPATH then it makes sure the build system puts a placeholder RPATH in the built binary. Then during installation the built file is copied to the destination and the placeholder RPATH is replaced. Somehow your installed file is ending up with no RPATH entry. Even if it already existed with no RPATH before installation it should have had a different file time than the to-be-installed file and therefore been replaced with a copy that had a placeholder. How did you get to the situation reporting the error? Was this a completely clean build and install tree, or was it an existing tree from CMake 2.4 that was upgraded? Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
Brad King wrote: Dirk Mueller wrote: I've switched to cmake 2.6 for dashbot (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file CHRPATH could not write new RPATH /opt/testing/lib to the file /var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc: No valid ELF RPATH entry exists in the file; I'm having trouble reproducing this. [snip] How did you get to the situation reporting the error? Was this a completely clean build and install tree, or was it an existing tree from CMake 2.4 that was upgraded? Okay, it doesn't matter how to reproduce it. The fix is the same. I've committed changes to CMake HEAD in CVS to address this problem and the one about removing the RPATH entry. Before installing CMake now checks if there is an existing binary that has the wrong RPATH and removes it. That will make sure the new copy from the build tree gets installed and subsequently patched to update or remove the RPATH entry. These fixes will be in the 2.6 release. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Extra CACHE options
Allen Winter wrote: On Monday 14 April 2008 13:19:18 Brad King wrote: FindAkode.cmake I see CACHE INTERNAL in FindAkode.cmake. Isn't that ok? It will work, but there is no reason to be in the cache. The variable being set is just summarizing results for the project. FindGettext.cmake I see CACHE FILEPATH in FindGettext.cmake. Isn't that ok? No, because the FIND_LIBRARY call uses a different variable. The SET CACHE line is just copying the result from the first run and never changes it. Again, the variable is supposed to be reporting results cached by another variable. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Benjamin Reed wrote: On Mon, Apr 14, 2008 at 4:11 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: add_executable(hello MACOSX_BUNDLE main.cpp) install(TARGETS hello RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib) Yeah, even that small sample fails. I guess no one has been using CMake from CVS on the mac. This has been broken since Aug 22 2007: http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/cmInstallCommand.cxx?root=CMaker1=1.26r2=1.27 I've got a test case with a version that fails and a version that passes, here: http://ranger.befunk.com/debug/cmake-bundle-destination-test.tar.gz Adding BUNDLE DESTINATION lib fixes it; but I would say that if BUNDLE DESTINATION is not set, cmake should fall back to whatever LIBRARY DESTINATION is set to. CMake 2.4 uses the RUNTIME DESTINATION for bundles and the LIBRARY DESTINATION for frameworks. Therefore these should be the fallbacks. I'll look at fixing it. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Benjamin Reed wrote: I'm getting even more confused then... RUNTIME means executables in this context, doesn't it? Then maybe I was wrong in my assessment of what BUNDLE means in the install command in the first place... does it mean loadable modules (.bundle) or does it mean app-bundles? It means app bundles. bundle is such an overloaded term in OSX that without explicit context it's hard to know what you're referring to specifically. It would be clearer in the documentation if it was more like this: The TARGETS form specifies rules for installing targets from a project. There are five kinds of target files that may be installed: ARCHIVE, LIBRARY, RUNTIME, FRAMEWORK, and BUNDLE. Executables are treated as RUNTIME targets, except that those marked with the MACOSX_BUNDLE property are treated as BUNDLE targets on OS X. Static I've updated the documentation accordingly. I've also committed a fix that should make the old code continue to run (and use the RUNTIME destination). I added a new policy CMP0006 that will warn about not providing a BUNDLE destination. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: [CMake] CMake 2.6.0 Beta ready for testing!
Alexander Neundorf wrote: cmake 2.6.0beta has been released :-) Everybody who is using cmake cvs with a version 2.5.x, please update your cmake cvs (to 2.7) or to the 2.6 branch or just get the 2.6.0beta release. FYI, the problem described here: http://mail.kde.org/pipermail/kde-buildsystem/2008-January/004401.html is no longer handled via the CMAKE_LINK_OLD_PATHS compatibility mode so setting the variable for CMake 2.6 is useless. Instead the new CMake Policy mechanism handles the situation in a more compatible way. Basically the compatibility linker search paths are added by default (with a warning) until a policy is set to tell it not to do so. For more information, see: http://www.cmake.org/Wiki/CMake_Policies cmake --help-policy CMP0003 -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs and runtime path resolution
Brad King wrote: Thiago Macieira wrote: You could also simply read the ELF header from inside cmake. That would make the process A LOT faster. Unlike chrpath, which actually modifies the target executable, this is simply reading (load header, load sections, find the DYNAMIC section, find DT_SONAME in there, then read the string at the address on the STRTAB section). /usr/include/elf.h is present in all platforms. I'm actually working on that right now :) I've just committed changes to parse ELF files and read the SONAME directly. The implementation supports both 32-bit and 64-bit ELF files. I also implemented byte swapping so that MSB files can be read on LSB host platforms and vice versa. Shared library ordering should now always use the real soname for shared libraries on ELF target platforms. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs head - dependencies broken
David Faure wrote: Sorry, me again :) With cmake cvs from today, when I modify a header file, the corresponding .cpp file (which obviously includes it) doesn't get recompiled !?!? I tried touching the CMakeLists.txt in that dir, I tried forcing a recompile of foo.cpp (to let it recompute dependencies if that's when it happens), but after that the same happens: changing the header file triggers no recompilation. I cannot reproduce this. Everything rebuilds correctly for me. Did you start with a fresh build tree or run CMake from CVS on a tree initially generated by 2.4? Can you reproduce it in a new build tree? What generator are you using? If you're using the Makefiles generator, look in the build tree under CMakeFiles/target-not-rebuilding.dir. There should be files like depend.make and CXX.includecache. Please send them to me. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs head - dependencies broken
David Faure wrote: CMakeFiles/kdecore.dir/depend.make is empty (# Empty dependencies files, # This may be replaced when dependencies are built) CXX.includecache is up at http://web.davidfaure.fr/tmp/CXX.includecache (strange syntax, is the target the first line after an empty line?) Ask Alex, he wrote the include cache stuff, and it does make dependency scanning amazingly fast. I think the syntax is meant to be very fast to parse. Can you reproduce it in a new build tree? OK, that was it. I deleted the kdecore build dir and ran cmake again, and now it works as expected. [snip] Maybe cmake could do like Qt's moc and say this build tree was generated with cmake-2.4, you need to delete it and regenerate it to use this version of cmake or something like that? Well, the intention is to work with existing build trees. I just tried generating a simple example project with 2.4 and then running CMake from CVS on it. Everything still rebuilds correctly (both with and without building between the cmake runs). Are you able to reproduce this if you create a kdecore tree with cmake 2.4 and then run cmake HEAD on it again? -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs and runtime path resolution
David Faure wrote: I just updated my cmake cvs, (cmake version 2.5-20080220), and I get this in kdelibs: WARNING: Cannot generate a safe runtime path for target kio because there is a cycle in the constraint graph: dir 0 is [/d/kde/build/4/kdelibs/lib] dir 1 is [/d/kde/inst/kdesupport_trunk/lib] dir 2 is [/d/kde/src/4/qt-copy/lib] dir 3 is [/usr/lib] dir 1 must precede it due to [libstreamanalyzer.so] dir 2 must precede it due to [libQtSvg.so] dir 4 must precede it due to [libacl.so] dir 4 is [/lib] dir 3 must precede it due to [libbz2.so] which comes down to: dir 3 is [/usr/lib] dir 4 must precede it due to [libacl.so] dir 4 is [/lib] dir 3 must precede it due to [libbz2.so] Which comes from the fact that libacl.so and libbz2.so are not in the same system dir, as far as cmake can see. But they are: ls -l /usr/lib/libbz2.so* lrwxrwxrwx 1 root root 18 2007-12-17 17:04 /usr/lib/libbz2.so - /lib/libbz2.so.1.0 ls -l /usr/lib/libacl.so lrwxrwxrwx 1 root root 14 2007-12-18 20:03 /usr/lib/libacl.so - /lib/libacl.so (seems standard on kubuntu gutsy) Hmm, why does cmake even care for the .so symlinks when looking at runtime paths? Runtime only uses .so.1 anyway, not .so... Ah, but obviously it doesn't look at that, only at what the cache has to say: CMakeCache.txt:ACL_LIBS:FILEPATH=/lib/libacl.so CMakeCache.txt:BZIP2_LIBRARIES:FILEPATH=/usr/lib/libbz2.so (because there is no /lib/libbz2.so, only a .so.1) I'm not sure what the right fix is -- apart from yelling at ubuntu :) What's for sure is that this is a false positive; any ordering between /lib and /usr/lib would work out just fine in this setup. Here are some comments: 1.) The path ordering should probably always leave system directories (/lib and /usr/lib) out of the analysis since they will be searched by default anyway. 2.) The reason it gets the false positive is because there is no easy way to know for sure the soname of a library found on disk (unless someone can tell me how to do it which would be great). Therefore the analysis is conservative and assumes that any file starting in the original name of the library is a possible soname conflict. I guess we could update this to check if the library is a symlink and assume that the destination is its soname. 3.) The full fix would be to setup an imported library. CMake HEAD in CVS provides support for importing libraries as logical targets which allows one to provide more information about a library including its soname. This solution however requires cooperation from the distribution providing the library. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs and runtime path resolution
David Faure wrote: On Thursday 21 February 2008, Brad King wrote: 2.) The reason it gets the false positive is because there is no easy way to know for sure the soname of a library found on disk (unless someone can tell me how to do it which would be great). Therefore the analysis is conservative and assumes that any file starting in the original name of the library is a possible soname conflict. I guess we could update this to check if the library is a symlink and assume that the destination is its soname. What you call soname here is the libfoo.so devel lib? Sorry I forgot what soname really is. No. The soname is the name used to look for the library at runtime. Here are the three parts involved: linkname: libfoo.so - libfoo.so.3 soname:libfoo.so.3 - libfoo.so.1.2 realname: libfoo.so.1.2 Some libraries have just an implementation version: linkname:libfoo.so - libfoo.so.4 real/soname: libfoo.so.4 The soname is needed to determine runtime path order because that is the name of the file for which the dynamic linker will search. When CMake does not know the soname it conservatively assumes that the soname is of the globbing form libfoo.so* and adds corresponding constraints. From the name /path/to/libfoo.so for a third-party library there is no easy way to reliably detect its soname (which is encoded inside the file in a native binary format). I'm looking at adding something to guess that if the file name given is a symlink with no path component that the symlink points at the soname. Anyway I updated and I saw a commit from you about all this, thanks! The warning seems to be gone now. Wow, thanks for testing it so quickly. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs and runtime path resolution
David Faure wrote: On Thursday 21 February 2008, Brad King wrote: I'm looking at adding something to guess that if the file name given is a symlink with no path component that the symlink points at the soname. Would this also work in these case? libpng.so - libpng12.so libpng12.so - libpng12.so.0.15.0 I guess the soname is libpng12.so.0.15.0 in this case, but looking at the first symlink wouldn't tell that. libcurses.so - libncurses.so libncurses.so - /lib/libncurses.so.5 The soname is libncurses.so.5, right? First symlink will make you think it's libncurses.so, no? Yeah, it's hard to do reliably. Since this is used only to reduce cases of false positives I'm making the test more conservative by also requiring the symlink file name itself to be a substring at the beginning of its own destination value. With this restriction both cases you give will not guess the soname and instead use libpng.so* and libcurses.so* to look for conflicts. Unfortunately if there are in fact instances of libncurses.so.5 in other directories the rpath ordering will not take them into account (which is a false negative). At least the guessing process will reduce the false positive rate. Later we can try to add more powerful soname determination. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs and runtime path resolution
Thiago Macieira wrote: David Faure wrote: libpng.so - libpng12.so libpng12.so - libpng12.so.0.15.0 I guess the soname is libpng12.so.0.15.0 in this case, but looking at the first symlink wouldn't tell that. $ objdump -p /usr/lib/libpng.so | grep SONAME SONAME libpng12.so.0 $ readelf -d /usr/lib/libpng.so | grep SONAME 0x000e (SONAME) Library soname: [libpng12.so.0] $ eu-readelf -d /usr/lib/libpng.so | grep SONAME SONAMELibrary soname: [libpng12.so.0] This could be helpful, thanks. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake cvs and runtime path resolution
Thiago Macieira wrote: You could also simply read the ELF header from inside cmake. That would make the process A LOT faster. Unlike chrpath, which actually modifies the target executable, this is simply reading (load header, load sections, find the DYNAMIC section, find DT_SONAME in there, then read the string at the address on the STRTAB section). /usr/include/elf.h is present in all platforms. I'm actually working on that right now :) -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: 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
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
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: Getting rid of the LIB_INSTALL_DIR hack on windows
Christian Ehrlicher wrote:
install(TARGETS kfoo kbar USE_PROPERTIES foo)
where foo contains all informations about the install locations?
How is this different from
install(TARGETS kfoo kbar ${foo_INSTALL_RULES})
which you can do right now?
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Auto-generated XML interfaces and dependencies
Alexander Neundorf wrote: Ok, so in one directory the xml file is created using add_custom_command(), and used later on in targets in other directories. The official way to express the dependency to a generated file is to add the generated file to the sources of the target. Correct. I'm not quite sure how the dependencies are handled between directories. Brad ? Custom commands are only hooked into targets in the same directory in which they are defined (not even subdirectories). I guess then one way would be to add a helper target add_custom_target(CREATE_DBUS_STUFF) which creates all the dbus xml interfaces, and have all the targets which need these interfaces depend on this helper target. Using a target-level dependency is the correct approach. Having the rule to generate the file in more than one target could result in corruption during parallel builds. OTOH, if other targets need some part of what is built when kmail is being built, then it doesn't seem to be that wrong to make them depend on kmail (or the helper target). Any approach that puts the generation rule in a single target on which all other targets that use the file depend is correct. Avoiding a helper target in favor of a target on which a dependency must be added anyway is probably good. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [CMake] Problem with to long path names on win32
Christian Ehrlicher wrote: Hi, I currently can't compile kdebase/konqueror because the paths exceeds the max path length: D:\kde-msvc\tmp\kdebase-beta3-3.94.1.20071011\work\kdebase\apps\konqueror\sidebar\trees\konq_sidebartreetoplevelitem.cpp : fatal error C1083: Datei (vom Compiler generiert) kann nicht geƶffnet werden: apps/konqueror/sidebar/trees/bookmark_module/CMakeFiles/konq_sidebartree_bookmarks.dir/__/__/__/__/__/__/kdebase/apps/ konqueror/sidebar/trees/konq_sidebartreetoplevelitem.obj: No such file or directory Any idea how to fix this problem? I already shortened the paths but they're still to long... :( CMake HEAD (in CVS) uses a much better policy to determine path names to reduce the cases in which the long names are encountered. It also has a way to automatically replace long path names with short ones in a unique manner. Unfortunately the changes are too extensive to port to the 2.4 release branch. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install
David Faure wrote: On Tuesday 02 October 2007, Brad King wrote: There is alot of discussion in that bug report. The comparison of files is not for speed on installation...it's for not changing timestamps of already installed files and causing all *other* code using the installed files to rebuild, which is potentially even slower. Yes. The real solution is a dependency from the installed file to the file-to-install, so that the file-to-install isn't installed if it isn't newer than the already-installed file. And then, when that is implemented, thre is no need for comparing files in order to avoid changing timestamps, since you get for free by not installing the file at all :) This has now been implemented in CMake HEAD: http://www.cmake.org/Bug/view.php?id=3349 Repeat installations are now lightning fast. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install
Andreas Hartmetz wrote: 2007/10/5, Brad King [EMAIL PROTECTED]: Repeat installations are now lightning fast. Swt! Do you have any release plans? I'm happy already with CVS HEAD, though. There are some major changes in CMake HEAD since the 2.4.x branch was created. We have not yet scheduled 2.6. The changes for this bug could probably be ported to 2.4 but I do not know if there will be another release of that branch before 2.6 anyway. Somebody mentioned that it would also be nice if one could suppress the Up-to-date: file lines. It's a one liner to hardcode. I don't care much about it myself, but for now I'm running a CMake that doesn't show the up-to-date lines. The idea is that you can see at a glance if the file you wanted to have reinstalled has actually been reinstalled. Not that this had ever failed for me :) Thank you, and please consider this suggestion. I can make a patch if you want. Your command-line system probably is manageable for me, and the actual suppression of output is a piece of cake. This was requested here: http://www.cmake.org/Bug/view.php?id=4141 I'm not yet sure what interface should be provided to configure the verbosity level. Please post suggestions in the bug report if you have ideas. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install
Brad King wrote: Andreas Hartmetz wrote: which I haven't readbecause you need an account to read bug reports (what were they thinking???). Our old bug tracker was cracked (spammed even without account). The current one was setup in 1 day and all the bugs converted. It hasn't been fully configured yet because our sysadmin is pretty busy. FYI, I've had the sysadmin enable public browsing of the bug tracker. You should now be able to read the bug. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install
Andreas Hartmetz wrote: Today it came up on IRC that we all don't like that make install reinstalls *everything* every time you run it. The time to do this is a considerable fraction of the total time to make install if few files changed. What's even worse is that the heavy disk activity makes the system respond very slowly during the install. AFAIK make install actually compares the installed files and the new files for equality and only installs what has changed. That doesn't help at all with speed and reducing the number of disk seeks. Apparently there is a bug report for this http://www.cmake.org/Bug/view.php?id=3349 There is alot of discussion in that bug report. The comparison of files is not for speed on installation...it's for not changing timestamps of already installed files and causing all *other* code using the installed files to rebuild, which is potentially even slower. There are also proposed solutions, but we've had higher priority things to implement. which I haven't readbecause you need an account to read bug reports (what were they thinking???). Our old bug tracker was cracked (spammed even without account). The current one was setup in 1 day and all the bugs converted. It hasn't been fully configured yet because our sysadmin is pretty busy. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote: emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Hmm, shouldn't emitted.insert(/lib); be added to that list too? Someone in the koffice irc channel just reported seeing -L/lib in his link line. Okay, instead of prediciting all the implicit link directories hard-coded in the cmake binary I've created a platform configuration variable: CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES This just lists the paths that should not be emitted. In Modules/Platform/UnixPaths.cmake it is set to have /lib, /usr/lib, /usr/lib32, and /usr/lib64 on all unix systems. This way if a new path is discovered it can just be appended to this list in the user project instead of waiting for a new CMake release. I'll try go get this in 2.4.7. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
Allen Winter wrote: On Thursday 17 May 2007 2:46:39 pm Brad King wrote: Brad King wrote: David Faure wrote: I was talking to Simon on IRC and he suggested that -L/usr/lib32 should also not be generated. Can I suggest this patch? (I see that the CMake-2-4 branch is unchanged after this discussion, so this is still TODO) [snip] emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Yes, this has been on my TODO list since that conversation. I've committed it to the main tree but need to wait for a day or two of nightly tests before I can put it on the branch. Okay, this fix is now in the 2.4 branch. It will be included in 2.4.7. Is this fix important enough to justify requiring 2.4.7 for KDE 4.0? That's up to David, but I don't think so. His problem was pretty obscure. Either way it's not worth it until 2.4.7 is actually out :) -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
Alexander Neundorf wrote: On Thursday 17 May 2007 14:51, Allen Winter wrote: On Thursday 17 May 2007 2:46:39 pm Brad King wrote: Brad King wrote: David Faure wrote: I was talking to Simon on IRC and he suggested that -L/usr/lib32 should also not be generated. Can I suggest this patch? (I see that the CMake-2-4 branch is unchanged after this discussion, so this is still TODO) [snip] emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Yes, this has been on my TODO list since that conversation. I've committed it to the main tree but need to wait for a day or two of nightly tests before I can put it on the branch. Okay, this fix is now in the 2.4 branch. It will be included in 2.4.7. Is this fix important enough to justify requiring 2.4.7 for KDE 4.0? No, I don't think so, at least not now. I mean, for most systems it works, and where it doesn't work, there people can still install cmake 2.4.7. Requiring *everybody* to update to 2.4.7 once it's released is no good idea. Also there is a simple work-around for people on the platforms causing the problem: just install the qt4-dev package. Then the proper rpaths will be computed. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote: I was talking to Simon on IRC and he suggested that -L/usr/lib32 should also not be generated. Can I suggest this patch? (I see that the CMake-2-4 branch is unchanged after this discussion, so this is still TODO) [snip] emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Yes, this has been on my TODO list since that conversation. I've committed it to the main tree but need to wait for a day or two of nightly tests before I can put it on the branch. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote: On Friday 04 May 2007, Thiago Macieira wrote: /usr/lib64/libQtCore.so Ah, doh, I removed libqt4-dev earlier today to see if that would help. This might have screwed up the tests. Here's a new log: http://web.davidfaure.fr/tmp/output_with_qt4dev.gz Checking [/d/kde/src/4/qt-copy/lib/libQtCore.so] conflict at [/usr/lib64/libQtCore.so]: yes (file) Okay, so this conflict should cause the proper order of link directories to appear. Now we need to determine why it is not happening for that target. Here is another patch that should tell us what output belongs to what target. -Brad Index: Source/cmLocalGenerator.cxx === RCS file: /cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v retrieving revision 1.132.2.11 diff -c -3 -p -r1.132.2.11 cmLocalGenerator.cxx *** Source/cmLocalGenerator.cxx 16 Mar 2007 22:05:42 - 1.132.2.11 --- Source/cmLocalGenerator.cxx 4 May 2007 12:49:12 - *** void cmLocalGenerator *** 1732,1737 --- 1732,1740 this-Makefile-GetDefinition(shared_link_type_flag_var.c_str()); } + printf(\n + Determining link dir order for target %s\n, target.GetName()); + // Compute the link directory order needed to link the libraries. cmOrderLinkDirectories orderLibs; orderLibs.SetLinkTypeInformation(cmOrderLinkDirectories::LinkShared, *** void cmLocalGenerator *** 1777,1782 --- 1780,1788 orderLibs.DetermineLibraryPathOrder(); std::vectorcmStdString orderedLibs; orderLibs.GetLinkerInformation(outDirs, orderedLibs); + printf(Done with link dir order for target %s\n + \n, + target.GetName()); // Make sure libraries are linked with the proper syntax. std::string libLinkFlag = ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote: On Wednesday 02 May 2007, Brad King wrote: Thanks for the detailed information. There seem to be two problems: In fact I would add problem number 0: it picks up system libs in /usr/lib64 over /usr/lib, while lib64 is just some compatibility symlink. I'd rather see it find PNG_LIBRARY:FILEPATH=/usr/lib/libpng.so than PNG_LIBRARY:FILEPATH=/usr/lib64/libpng.so for instance. Maybe a realpath() call would be a good idea? We used to call realpath but ended up having to remove it. The problem is that people running with network mounted disks can have the realpath corresponding to a logical directory name actually change between builds. 1.) The cmOrderLinkDirectories implementation is not detecting the conflict provided by /usr/lib64. Would you please provide a list of the libraries in /usr/lib64 and a list of those in /d/kde/src/4/qt-copy/lib? [snip] libQtCore.so /usr/lib64/libQtCore.so /d/qt/4/qt-copy/lib/libQtCore.so I'm unable to duplicate this problem. Would you please build a CMake from source, but with the following modification? In Source/cmOrderLinkDirectories.cxx, uncomment the line //#define CM_ORDER_LINK_DIRECTORIES_DEBUG and change the line this-Debug = false; to this-Debug = true; Then re-run cmake on the tree having this problem and send me the output. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote:
On Thursday 03 May 2007, Brad King wrote:
I'm unable to duplicate this problem. Would you please build a CMake
from source, but with the following modification?
No problem - I always use CMake from source (cvs, branch CMake-2-4)
Then re-run cmake on the tree having this problem and send me the output.
Wow there's output for each target so it's hard to figure out what's about
what...
Here's the whole lot: http://web.davidfaure.fr/tmp/output.gz
I do not see any reports in that output about possible conflicts between
the two directories for QtCore or similar libraries. Please apply the
attached patch to the CMake source tree and try again. (If you thought
the output was big before, wait until you see this one.)
Thanks,
-Brad
Index: Source/cmOrderLinkDirectories.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/cmOrderLinkDirectories.cxx,v
retrieving revision 1.37
diff -c -3 -p -r1.37 cmOrderLinkDirectories.cxx
*** Source/cmOrderLinkDirectories.cxx 30 Nov 2006 22:50:40 - 1.37
--- Source/cmOrderLinkDirectories.cxx 3 May 2007 18:23:22 -
*** bool cmOrderLinkDirectories::LibraryMayC
*** 670,683
--- 670,687
std::string path = dir;
path += /;
path += fname;
+ printf(Checking [%s] conflict at [%s]: , desiredLib, path.c_str());
if(this-ManifestFiles.find(path) != this-ManifestFiles.end())
{
found = true;
+ printf(yes (manifest)\n);
}
else if(cmSystemTools::FileExists(path.c_str()))
{
found = true;
+ printf(yes (file)\n);
}
+ printf(no\n);
// When linking with a multi-configuration build tool the
// per-configuration subdirectory is added to each link path. Check
*** bool cmOrderLinkDirectories::LibraryMayC
*** 689,702
--- 693,710
path += this-ConfigSubdir;
path += /;
path += fname;
+ printf(Checking [%s] conflict at [%s]: , desiredLib, path.c_str());
if(this-ManifestFiles.find(path) != this-ManifestFiles.end())
{
found = true;
+ printf(yes (manifest)\n);
}
else if(cmSystemTools::FileExists(path.c_str()))
{
found = true;
+ printf(yes (file)\n);
}
+ printf(no\n);
}
// A library conflicts if it is found and is not a symlink back to
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote: = How is the RPATH order determined? Is there any way to ensure that /usr/lib will always be after $KDEDIR/lib and $QTDIR/lib? KDE uses the INSTALL_RPATH_USE_LINK_PATH option provided by CMake which basically says that the RPATH is the same as the linker search path except for the directories in the build tree. The linker path order is computed automatically by CMake given the full paths to the libraries being linked. A safe order is supposed to be computed based on the contents of the directories containing the libraries. Please post the KDELibsDependencies.cmake file from the kdelibs you're using. It is installed to PREFIX/share/apps/cmake/modules, or is in the top of the build tree of kdelibs. Also please build konqueror and kwin with make VERBOSE=1 and post the link lines used to produce the binaries. = Why are we still using old-style rpath? Thiago, can we activate by default the runpath stuff so that $LD_LIBRARY_PATH can actually do its job? Whether or not we switch to RUNPATH on ELF systems, the old-style RPATH still has to work for other platforms. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
Thiago Macieira wrote:
Since that's just an empty file and will produce hardly any symbols,
there's no need to link.
One solution is to build the sources in a static library. The archiver
does not care about symbol resolution since it does not really link
anything:
ADD_LIBRARY(check_compile STATIC src1.cxx src2.cxx)
In order to avoid the time actually spent archiving you can remove the
object files from the link rule:
STRING(REGEX REPLACE OBJECTS[^]*
CMAKE_CXX_CREATE_STATIC_LIBRARY
${CMAKE_CXX_CREATE_STATIC_LIBRARY})
which causes the target to be created as an empty archive for all the
Makefile generators. This should be done in its own subdirectory though
so that the link rule is not broken for other directories.
For the VS IDE generators there does not seem to be a way to compile
sources without archiving them, but since the objects contain only a few
symbols they should not be too big.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: How to add a specific .o file generated (with cmake)
Laurent Montel wrote: On Wednesday 18 October 2006 17:58, Alexander Neundorf wrote: On Wednesday 18 October 2006 17:42, Laurent Montel wrote: Hi, Into kalzium we generate a .o file. We want to link it with kalzium binary. How is it possible to specify a obj file when we want to create a binary ? (obj file is a C file) Can you please explain a bit more ? It sounds a bit like a hack. We have an object file generated (into kdeedu/kalzium/src/solver/) with ocalm program. We generate directly a obj file. After we must add this object file when we will create binary kalzium. Just include the object file in the list of sources for the target. CMake will recognize it as an external object file and include it in the link line. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Exiting CMake
Allen Winter wrote: Is there a little more graceful way of exiting other than message(FATAL_ERROR message) ?? For example, in the MACRO_DISPLAY_FEATURE_LOG() macro I want to exit if there are missing required features. I want to display the messages that some requirements are missing and then exit. But I don't want to panic the user with messages like: CMake Error: Error in cmake code at /data/kde/trunk/KDE/kdepimlibs/CMakeLists.txt:1: MESSAGE some message Current CMake stack: /data/kde/trunk/KDE/kdepimlibs/CMakeLists.txt I don't see a simple Quit() or Exit() type of cmake commands. There is currently no such command but you can submit a feature request: http://www.cmake.org/Bug -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: kpovmodeler cmake opengl problem
Clarence Dang wrote: No, there doesn't seem to be a -devel package. rpm -q xorg-x11-Mesa-libGLU --list /usr/X11R6/lib/libGLU.so.1 /usr/X11R6/lib/libGLU.so.1.3 /usr/lib/libGLU.so.1 cmake people, could you please shed light on what the OpenGL test does and/or what files/packages I need? CMake uses this script to search for OpenGL: http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/FindOpenGL.cmake?root=CMakeview=markup It needs to locate the GL/gl.h header file, and a copy of the GL library that can be loaded by the linker. On Linux this is typically a symlink called libGL.so that points at libGL.so.version. Both the header and the symlink are usually installed by a mesagl-dev package or something like that (the actual name depends on your linux distro). This is not a CMake-specific problem. There is no way you can build an opengl application on your system without this package no matter what build tool it uses. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Thiago Macieira wrote: Brad King wrote: For plain old ADD_LIBRARY, the STATIC option works on all platforms to create a static library. What is not supported is the convenience part that allows multiple static libraries to be linked to form a bigger static library, or all the objects in a static archive to be copied into a shared library whether they are referenced or not. Right. CMake shouldn't allow one to add a static library as a dependency for anything other than a final executable. I don't know if it does that or not, but it shouldn't. libtool allowed that because the dependency was recorded in the .la file. When the final executable was linked, the linking was actually performed. The equivalent in CMake would be to just remove static libraries from the list of libraries put on the link line for a shared library. The static libraries should still be listed as dependencies so that when the executable links to the shared library it gets the static library too. Does this sound correct? -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Thiago Macieira wrote: Brad King wrote: The equivalent in CMake would be to just remove static libraries from the list of libraries put on the link line for a shared library. The static libraries should still be listed as dependencies so that when the executable links to the shared library it gets the static library too. Does this sound correct? No. They should be completely forbidden. If you do it like that, it'll work for a shared library that is produced in the same cmake build. But it'll fail for a 3rd-party (from a different cmake build), since the dependency isn't recorded anywhere. Unless you're proposing to create and install .la files. Sure it is recorded. Look at the EXPORT_LIBRARY_DEPENDENCIES command. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
