Alan W. Irwin writes: > Thanks for running that test. As far as I am concerned that demonstrates a > gross cmake bug. > > To anticipate the first question that will be asked when I report this > issue, what version of cmake are you running? If it is a system version, I > wonder if your Linux distro applied some really dumb patch to always favor > /usr/lib64/ as the first place to look for libraries regardless of how > CMAKE_LIBRARY_PATH is set.
[furn...@ziffy]~% cat /etc/issue Fedora release 12 (Constantine) Kernel \r on an \m (\l) [furn...@ziffy]~% rpm -qa | grep cmake cmake-2.6.4-5.fc12.x86_64 > To take this further could you please try building cmake-2.8.1 (see > directions at http://cmake.org/cmake/resources/software.html) and use that > version instead for the above test if that is not what you are already > doing? That's the version I use for my testing with cmake-2.8.x these days. > > If cmake-2.8.1 built from kitware source shows the bad find result you > demonstrated above, then I will take this up further with the cmake list. Uhh. I think you just tripped another one of my rants about cmake. I really hate that our CBS won't work correctly on so many OS platforms because of cmake. For cryin' out loud, Fedora 12 is the most recently released version of Fedora, and it is using cmake 2.6.4. And that's not good enough? I have to manually construct a noveau cmake just so I can build PLplot? Just earlier today I documented that our current PLplot won't configure at all on Fedora 8. Now we see that it will configure, but wrongly on Fedora 12. What's wrong with this picture? I know exactly what's wrong: cmake Are we going to update PLplot's cmake configuration files to demand cmake 2.8.x? Honestly, I think this is nuts. I think it would be a lot more user (and our users are all developers) friendly, if we shipped cmake modules that override all the broken behavior in cmake, so that people who have cmake in their OS distro, would be able to just use it, without having to build a toolchain just so they can compile our library. I will try to run the test with cmake 2.8.1 and report the results. But personally, a "favorable" result with cmake 2.8.1 doesn't really seem like good news, if it means we conclude that every PLplot developer on earth is going to have to upgrade past their distro's cmake version, just in order to compile our library (reliably). I think we ought to be looking at an internal solution. And I don't mean to interrupt the current release push with this brouhaha. Documenting it and deferring it would be okay with me in the short term. Long term, if everyone else is really so happy with cmake, then I think we need to find a way to ship enough custom overides so that people can reliably build PLplot with whatever cmake they have on a reasonably up to date distro. I realize there would be some limites. cmake 0.2.3 is not something we should support. But I really have a hard time with the idea that Fedora 12's cmake is so old that it has to be upgraded before reliable builds will work. More when I have it. -Geoff ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
