All,
I ran some more testing against the cmake 2.8.12 CMP-0022 problem.
The TL;DR version:
The proposed patch partially works but needs attention. If we refine the patch to eliminate certain errors we probably will be able to place this entire cmake episode behind us. :-)
The longer story:
On Slackware 14.0 I have no problems compiling Trinity packages. The stock Slackware 14.0 came with cmake 2.8.8, but a while ago I updated my 14.0 build environment to cmake 2.8.10.2. I updated cmake because I was trying to anticipate what eventually would become Slackware 14.1. Along the way of developing the 14.1 branch after Slackware 14.0, cmake was updated to 2.8.10.2. Regardless, I have had no problems with 2.8.8 or 2.8.10.2.
Slackware 14.0 comes with gcc 4.7.1 and glibc 2.15.
In all of the following tests I attempted to build only the dependencies and core packages through tdebase. In each test I rebuilt all packages except TQt3 because that package has no cmake requirements.
On Slackware 14.0, I built and installed cmake 2.8.12.0. I did not apply the proposed patch. I saw a slew of CMP0022 warnings for arts and tdelibs. While arts did compile, I was unable to build tdelibs.
Next on Slackware 14.0, I built and installed cmake 2.8.12.1. I did not apply the proposed patch. I again saw a slew of CMP0022 warnings for arts, tdelibs, and tdebase. This time I was able to build tdelibs and tdebase. Thus 2.8.12.1 does provide a work-around to 2.8.12.0.
Next on Slackware 14.0, I returned to cmake 2.8.8 (the version provided in the original 14.0). I applied the proposed patch. This was to test backwards compatibility of the patch in distros using cmake < 2.8.12. I got as far as tdelibs with no errors or warnings. tdebase failed to build, with a slew of errors such as the following:
/dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference to `TQString::TQString(char const*)' /dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference to `TDEGlobal::locale()' /dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference to `TDELocale::removeCatalogue(TQString const&)' CMakeFiles/kgreet_winbind- module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTI7TQGList[_ZTI7TQGL ist]+0x8): undefined reference to `typeinfo for TQPtrCollection' CMakeFiles/kgreet_winbind- module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTI15KWinbindGreeter[ _ZTI15KWinbindGreeter]+0x10): undefined reference to `typeinfo for TQObject' CMakeFiles/kgreet_winbind- module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTV7TQGList[_ZTV7TQGL ist]+0xc): undefined reference to `TQGList::clear()'
Next on Slackware 14.0, I returned to cmake 2.8.10.2. I applied the proposed patch. Again no build failures through tdelibs while tdebase failed to build with the same errors.
Next on Slackware 14.0, I returned to cmake 2.8.12.0. I applied the proposed patch. tdelibs failed to build, but I saw the same failures in Slackware 14.1. Apparently at least part of the patch is required to build tdelibs with cmake 2.8.12.0.
Next on Slackware 14.0, I returned to cmake 2.8.12.1. I applied the proposed patch. Again no build failures through tdelibs while tdebase failed to build with the same errors.
The original cmake 2.8.12 problems I reported occurred with Slackware 14.1 and not 14.0. I used 14.0 as a test environment to establish some kind of baseline.
The primary differences between Slackware 14.1 and 14.0: cmake 2.8.12.0 vs. 2.8.8, gcc 4.8.2 vs. 4.7.1, and glibc 2.17 vs. 2.15. Yet by using Slackware 14.0 I believe I affirmed the failures I am experiencing are not related to gcc, glibc, etc.
Some Trinity members report they can build Trinity with cmake 2.8.12.0 although they witness the slew of CMP0022 warnings. With 2.8.12.X I always have been able to build arts but always either fail to build tdelibs or tdebase. The proposed patch allows me to build tdelibs but not tdebase.
I don't believe the problem is Slackware 14.1. Just cmake 2.8.12.X.
Darrell
2013/12/21 Darrell Anderson darrella@hushmail.com
All,
I ran some more testing against the cmake 2.8.12 CMP-0022 problem.
The TL;DR version:
The proposed patch partially works but needs attention. If we refine the patch to eliminate certain errors we probably will be able to place this entire cmake episode behind us. :-)
Try this patch... expected results are: <cmake-2.8.12: works fine as always were =cmake-2.8.12: no warnings; but the same LINK_ONLY-bla-bla error /* I still can't reproduce it, but I suspect it's because of some link flags e.g. I don't use hidden-visibility*/ cmake-2.8.12.1: no warnings; clean build.
Some my conclusions: 1. The warnings, you saw, have not a lot common with the error which leads to FTBFS. 2. cmake-2.8.12 was a buggy release. It seems, the only widely-used distro which still uses it is Slackware. 3. The bug is fixed in the next cmake release and there is no known workaround for it rather that the fix (see your own link on bugzilla)
A 2 cents about the patch: cmake_policy and cmake_required declaration won't affect includers. see CMP0011 cmake_required added for make policy CMP0011 work as new.
Using cmake_policy is a normal and legal way to keep old code working (without warnings) on newer versions and on the same time to make it work on older ones. AFAIK It's not some sort of hack, a quick fix or a deprecated syntax. It won't break at least unless version 3 (Or I don't know when/if they are going to break the compatibility).