Jed Brown wrote:
My point about CC and friends is that there are often standard
environment variables for setting this stuff. I think it should be
possible to select the version of packages with one variable. For Qt4,
this is the qmake executable, for PETSc, it is (by convention) PETSC_DIR
and PETSC_ARCH. With most packages, if the wrong version is found by
default, the user is required to edit all the advanced cache entries or
to delete the cache manually and try again with the correct variable
set.
...
So, each find module should have a consistently named variable that can
control the prefix for finding the module. For example, FindFoo.cmake,
would have FOO_DIR. If that environment variable is set and CMake can
not find it, it is an error and nothing else is searched. This is how
CC,CXX, and FC work. Once it is found the environment variable is no
longer looked at. However, if the cmake cache variable of the same name
is ever changed then all variables for the module are reset.
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.
I agree, it's really painful to do this in a robust way in CMake. The
command needs significant semantics (like understanding nested shell
quoting) to handle pathological inputs (which mine doesn't). For
instance, if the library makefile system sets
FOO_CFLAGS = -I/path/to/foo/include -DBAD='"Some -Ipathological string"'
it would be nice to parse this correctly. I know this looks like
over-engineering, but logic to parse this correctly must exist somewhere
in CMake already.
We can try, but shell escaping is going to hard. I am not sure it comes
up that much. When pkg-config is run or a makefile fragment is run it
should already expand the shell quoting. I don't think CMake has any
business being a shell.
...
So, what does BuildSystem do to handle this? Is there anything that
can be learned?
It's not elegant. It always assumes that the entire dependency graph
needs to be linked (as with static libraries). The analogue of Find*
modules recognize this and behave accordingly. Component Foo can always
be selected using
--with-foo-dir=/path/to/foo
...
This is basically covered by having a FOO_DIR variable for each
FindFoo.cmake module.
rely on a stale cache entry. I sometimes find myself repeatedly running
this
$ rm -r * && cmake .. -DFOO_VAR=blah
to guarantee that the cache is not stale and all necessary tests are
actually run.
I don't think we will be getting rid of the cache. However, having
dependent variables that when changed cause re-running of tests and
find_* stuff is a good idea.
be found
there (maybe I should have spelled it -DFOO_DIR=/path/to/foo-1.2) then
the module should not silently fall back on /usr/lib/libfoo.so.
Any ideas on how to make these semantics accessible to module writers
without a lot of custom effort?
I would think that some standard functions in something like
FindPackageHandleStandardArgs.cmake should help.
-Bill
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
