[CMake] Re: Find* and cross compiling

E. Wing ewmailing at gmail.com
Sat Dec 29 20:15:25 EST 2007


Ugh, sorry, accidentally botched the first replies because the
original reply was not to the list.

On 12/28/07, Rodolfo Lima <rodolfo at rodsoft.org> 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


More information about the CMake mailing list