[CMake] What does `cross-platform' mean?

[Bill Hoffman]

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
> toolchain.
> 
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:
> 
>   http://github.com/jedbrown/cmake-modules/tree/master/ResolveCompilerPaths.cmake
> 
>
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
> 
>   http://github.com/jedbrown/cmake-modules
> 
> are public domain and I'm willing to maintain them if they are added to
> CMake.
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?


-Bill