mingw-cross-env-list
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]