[CMake] What does `cross-platform' mean?
bill.hoffman at kitware.com
Sun Nov 9 17:55:12 EST 2008
Jed Brown wrote:
> Is my environment not `working' simply because I'm asking to link the
> versions of libraries that are found at a path other than the system
> defaults? Using something else and asking the user to edit the cache is
> like ignoring CC and requiring the user to edit CMAKE_C_COMPILER,
> CMAKE_LINKER, CMAKE_AR, CMAKE_RANLIB, etc to support a different
OK, so you have version of libraries that are not in default locations,
how is any build system supposed to find stuff like this? No I don't
expect users to edit CMAKE_AR, CMAKE_C_COMPILER and the tool chain
variables. I expect that the environment has the right PATH to the tool
chain setup before CMake is run. Just like the correct
CMAKE_LIBRARY_PATH needs to be set if you want CMake to find libraries
not in a standard location.
> See this:
There is some code inside CMake that does library path searching. It
might make sense to have a command that parses link lines and finds the
libraries. I am thinking a new command might be a good idea.
>> Also, if anyone knows of a build system that does any of this, we can
>> always copy what that system does. Although, I don't think any of
>> them do much of this stuff...
> Yes, the build system world is kind of a mess and resolving external
> libs is hard. BuildSystem (http://petsc.cs.iit.edu/petsc/BuildSystem)
> hand-tuned automake scripts can deal as well. CMake is definitely
So, what does BuildSystem do to handle this? Is there anything that
can be learned? A hand-tuned cmake project could deal as well, you have
some examples showing that.
> BTW, all the modules in my repository
> are public domain and I'm willing to maintain them if they are added to
Thanks, lets figure out what parts of all this belong in the C++ part of
CMake before adding lots of helper modules to CMake.
In summery, I see three things:
1. CMake needs a command to parse compiler link lines that may come from
pkg-config, makefile fragments or some other config file. The parsing
should act like a linker, and give the results in full paths to the
libraries. This can be done ad-hoc and is done by some folks now using
custom macros. We should be able to use some of the internal CMake
library path resolution code to do this.
2. CMake needs a way to easily chain variables together so that you can
clear stuff out if a dependent variable is changed by the user. So, if
you have MY_PATH_TO_TOOL=/path/to/tool, and it changes to
/new/path/to/tool, then all the libraries that where found using
MY_PATH_TO_TOOL should be reset and rediscovered. Currently, this is
done ad-hoc in CMake, for example Clinton just added something to the
FindQt4 that will reset all the qt variables if the qmake one is
changed. However, this issue has come up more than once and needs a
more consistent API for dealing with the issue.
3. How to best find libraries and headers not is system locations.
Currently, CMake uses environment variables like PATH,
CMAKE_LIBRARY_PATH, etc to do this. I have not seen a new suggestion in
this area. Do you have one?
More information about the CMake