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

[Bill Hoffman]

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