Ugh, sorry, accidentally botched the first replies because the original reply was not to the list.
On 12/28/07, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > On Fri, Dec 28, 2007 at 05:40:59PM -0800, E. Wing wrote: > > I didn't know cross-compiling was a feature now. > > Yes, works very well once you provide a 'toolchain file' with the correct > setup. > > > But the FindLua, FindFreeType modules should be fine. According to the > > documentation, the listed paths should only be searched last, after > > all other CMake standard paths have been searched. If those paths are > > being picked up, it means nothing in the standard environment produced > > a hit. > > But then something would be found that wasn't compiled for the target. The > scripts should make <LIB>_FOUND false. The standard paths you specify are > already taken in consideration by cmake as long you don't pass > NO_DEFAULT_PATHS to find_library/path. And it manages them quite well in a > cross-compiling build. So the explicit path listing is somewhat of an anachronism. Once upon a time, on some platforms, these search paths which should have been searched were not. I think some of these have been fixed by now, but I think some of them have not. The problem is that people just add them to the script and don't report the problem to Kitware so this remains unfixed. So I can't really remove these safely without breaking somebody. Since they are simply redundant and searched last, it didn't matter much before this feature. (I might mention there is also a psychological support side to this where somebody tries CMake and nothing is found. They automatically assume their path wasn't searched (even though it has). The redundancy seems to keep people quiet because it offers explicit documentation/assurance that their path was searched and forces them to take responsibility for their own problems.) But I would argue that removing these doesn't really fix the problem because other scripts that are not in the CMake distribution are going to suffer the same problem. I would argue that a more powerful mechanism within CMake may be needed to deal with this cleanly. -Eric _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
