All,
At one time I was told the minimum version of cmake required to
compile Trinity is 2.8.4. Where is that explicitly declared,
identified, or tested in the Trinity sources?
Thank you. :-)
Darrell
All,
In preparation for the R14.0.0 release, we would like to establish
minimum system requirements for installing and running Trinity.
Please refrain from "by gosh, by gum" guessing. :-) Please only
share real-world experiences using Trinity with older hardware and
distros as well as limited environments, such as the Raspberry Pi
or ARM.
We don't want to create absurd minimum requirements as has popular.
We want to establish realistic minimum requirements.
Thank you!
Darrell
>You could reference e.g. gentoo bugzillaand other:
>https://bugs.gentoo.org/show_bug.cgi?id=490194
>It's resolved here so I haven't
>The trinity is not the only project that is affected the gentoo
>also mentions ldc(d compiller) and openvas.
Consider this: KDE is completely cmake based. Slackware 14.1 comes
with cmake 2.8.12.0. All of the KDE packages compiled for the
official Slackware 14.1 release. I'm assuming without these
problems. Convincing the Slackware maintainer that cmake 2.8.12.0
is problematic needs a good explanation.
That KDE compiled without failure and Trinity does not compile
leads to an obvious question of what are the Trinity folks doing
"wrong" that the KDE folks are doing "right"?
Right now I don't understand the issues involved. I'm not a
developer or coder. I'm a packager and tester who is devoted to
keeping Trinity alive. These cmake problems are above and beyond my
full understanding. I can't ask the Slackware maintainer to update
to cmake 2.8.12.1 "just because." Trinity is not "officially"
supported in any distro. Emphasis on "officially." Asking distro
maintainers to update cmake needs a clear explanation --- something
I am not able to do. Somebody who understands the details of all of
these problems could write something that I could forward to the
Slackware maintainer.
That said, as I reported in a previous post, I still can't build
Trinity after I updated to 2.8.12.1 on my own. :-)
Darrell
>I think that this is a bug in cmake - see:
>http://cmake.org/gitweb?p=cmake.git;a=commit;h=239b0c6b0ed821fd012a
>2a980961b9a9d43793e5
>You need update cmake to at least 2.8.12.1.
_I_ could do that, but convincing the distro maintainer is another
story.
I ran a quick test for backwards compatibility. With the patch I
saw a bazillion undefined reference errors.
Darrell
>I see this on my workstation with a flaky USB mouse. Do you see
>frequent USB device disconnect/reconnect events in dmesg?
I'm not seeing anything in the logs. Would you please show me a
snippet of what you have seen?
Darrell
All,
Using git, creating fresh package sets frequently the past many
days.
Recently my mouse is not working correctly. I don't know whether
the problem is me, the mouse, X, or Trinity. I don't think the
mouse because I have tried two different devices.
The recent problem is a single click does not always function like
a single click. Sometimes the single click acts like a double-click
and sometimes a single click does nothing at all.
For example, single-click selecting an app icon in the taskbar or
the launcher menu button might do nothing at all. I have to click
again. Sometimes a single-click on a file opens the file rather
than just selecting, like a double-click.
Another problem is click-and-drag does not always hold. That is, I
click-and-drag to select a snippet of text but when I release the
mouse button the selection highlight disappears as though I single-
clicked outside the selected area.
I have the double-click time configured to 700 msecs (fairly slow)
and I have tested different times. I have double-click set as the
default icon selection action.
I don't want to use a different desktop for a day or two to decide
whether Trinity is involved.
Has anybody else experienced these or similar events of late? Any
ideas?
Thanks. :-)
Darrell
>I think that this is a bug in cmake - see:
>http://cmake.org/gitweb?p=cmake.git;a=commit;h=239b0c6b0ed821fd012a
>2a980961b9a9d43793e5
>You need update cmake to at least 2.8.12.1.
Slavek,
I updated cmake to 2.8.12.1. In the dependencies and core packages
I saw no cmake warnings or errors and all packages built without
error. Then tdebase failed to build.
Here is the build log:
http://humanreadable.nfshost.com/misc/trinity-tdebase-pre_R14.0.0-
i586-14.1_32_git_2882_1-build.log
The CMakeCache.txt file is part of the build log.
These are the same types of errors I saw when I tried a patch
backwards compatibility test building Trinity in Slackware 14.0
with cmake 2.8.10.2.
Side note: I will approach the Slackware maintainer and ask to
update cmake 2.8.12.1 as a bug fix, but I won't do that until all
related bugs are resolved. I have to provide a good reason for the
request, including how updating to 2.8.12.1 helped. :-)
Darrell
>Therefore, I have prepared a patch that could solve both of these
>problems. Please, test it.
I started testing the patch in Slackware 14.1, which uses cmake
2.8.12. I have not yet tested backwards compatibility with older
versions of cmake.
Thus far I saw no cmake warnings in arts (good!), but tdelibs is
filled with many instances of a single CMP0022 warning:
CMake Error:
Error evaluating generator expression:
$<LINK_ONLY:-Wl,-whole-archive>
$<LINK_ONLY> expression requires exactly one parameter.
CMake Warning (dev) in tdecore/tdehw/networkbackends/network-
manager/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the
link
interface. Run "cmake --help-policy CMP0022" for policy details.
Use the
cmake_policy command to set the policy and suppress this warning.
Static library target "network_manager_backend-static" has a
INTERFACE_LINK_LIBRARIES property. This should be preferred as
the source
of the link interface for this library. Ignoring the property
and using
the link implementation as the link interface instead.
This warning is for project developers. Use -Wno-dev to suppress
it.
I am not seeing any of the original warning messages.
Darrell
>Therefore, I have prepared a patch that could solve both of these
>problems. Please, test it.
I will test. Will be a few hours before I can provide results.
Darrell
All,
I gave a pass at compiling R14 on the newly released Slackware
14.1, which contains cmake 2.8.12.
The arts package compiled with cmake warnings I never saw before
and tdelibs FTBFS with the same warnings. The arts warnings:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in flow/gsl/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in flow/gsl/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
tdelibs:
CMake Warning (dev) in tdecore/tdehw/CMakeLists.txt:
CMake Warning (dev) in tdecore/tdehw/networkbackends/network-
manager/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in tdecore/svgicons/CMakeLists.txt:
CMake Warning (dev) in tdeio/tdeio/CMakeLists.txt:
CMake Warning (dev) in libltdl/CMakeLists.txt:
CMake Warning (dev) in tdehtml/java/CMakeLists.txt:
Following the colon of each warning:
Common to both arts and tdelibs:
CMake Warning (dev) in libltdl/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the
link
interface. Run "cmake --help-policy CMP0022" for policy details.
Use the
cmake_policy command to set the policy and suppress this warning.
Static library target "ltdlc-static" has a
INTERFACE_LINK_LIBRARIES
property. This should be preferred as the source of the link
interface for
this library. Ignoring the property and using the link
implementation as
the link interface instead.
This warning is for project developers. Use -Wno-dev to suppress
it.
If I understand correctly from reading around the web, the cause is
cmake 2.8.12 changed LINK_INTERFACE_LIBRARIES to
INTERFACE_LINK_LIBRARIES.
If that is correct, then seems TDEMacros.cmake:696 needs to be
updated to handle both variables:
target_link_libraries( ${_target} LINK_INTERFACE_LIBRARIES
${_shared_libs} )
I'm wild guessing something similar to this (I'm not a cmake guru):
If (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${
CMAKE_PATCH_VERSION } GREATER 2.8.11)
target_link_libraries( ${_target} INTERFACE_LINK_LIBRARIES
${_shared_libs} )
else()
target_link_libraries( ${_target} LINK_INTERFACE_LIBRARIES
${_shared_libs} )
endif()
I presume others will experience these same warnings and build
failures when they update to cmake 2.8.12.
Regardless, this requires a change to the common cmake sources,
which need to be propogated through the source tree.
Darrell