[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] Question and Help
From: |
Martin Lambers |
Subject: |
Re: [Mingw-cross-env-list] Question and Help |
Date: |
Thu, 18 Mar 2010 21:57:05 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, 18. Mar 2010, 21:16:54 +0100, Volker Grabsch wrote:
> > According to <http://www.cmake.org/Wiki/CMake_Cross_Compiling>, you can
> > make a "toolchain file" that contains all the macros, and then call
> > 'cmake -DCMAKE_TOOLCHAIN_FILE=...'.
> >
> > It might make sense to generate such a file in Mingw-cross-env, but it
> > would have to be updated if the MCE directory is moved. I do not think it
> > is worth the trouble.
>
> But, why does CMake need absolute paths at all?
>
> The tools are in ${PATH}, and include/lib directories can be found with
> pkg-config. So why does CMake need absolute paths at all?
CMake should of course be able to find the tools in PATH, and a
well-written CMake file should use i686-pc-mingw32-pkg-config
or use some other sane method to find include and lib directories.
But most CMake files do not work that way, and that includes the files
that are provided as part of CMake.
Examples from Debian lenny:
- /usr/share/cmake-2.6/Modules/FindPkgConfig.cmake uses the host
pkg-config unconditionally and has to be forced to use
i686-pc-mingw32-pkg-config.
- /usr/share/cmake-2.6/Modules/Find<SOME_LIB>.cmake files usually
contain a long list of fixed directories where they will look for
headers and libraries.
For cross-compilation, the FIND_* macros of CMake have to be forced
to look into user-specified directories and (additionally) ignore
these explicitly listed directories. This has to be done via the four
CMAKE_FIND_ROOT_PATH* macros.
In my opinion, this approach is just wrong and creates problems not only
for cross-compilation. Just do a quick
'grep /include /usr/share/cmake-2.6/Modules/*'
to see the different and inconsistent lists of fixed include directories
that are used by many different Find*.cmake files.
To be fair, it seems that newer releases of CMake try to clean up this
mess.
> So the issing support for platform triplets is just a minor issue.
> The real problem is the requirement for absolute paths.
Well-written CMake files would probably not need absolute paths, but
such files are very rare, see above. Maybe this situation will improve
over time.
Martin