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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
