2008/11/7 Jed Brown <[EMAIL PROTECTED]>: >> >> If the underlying tool is efficient then CMake FIND module should find >> the appropriate version. > > Thank you Eric, this greatly clarifies some design decisions. May I > interpret this to mean that CMake does not intend to be concerned with > finding the `right' version of a library,
[...] ok let's go on with this discussion. > Unfortunately not every environment with multiple versions has the > `module' tool and users will expect to be able to have a reasonable way > to find specific versions of software. I do perfectly understand your point I do remember similar problem when I had a patchwork of versions (compiler, lib etc...) > My development box has 4 MPI > implementations and 4-16 (ABI-incompatible) versions of many libraries. Nice environment indeed :=) [...] > It's much clearer if CMake never intends to support this usage. I think this was not designed for that, just as CMake 2.4 was not designed for cross-compiling. The need came-in again and again and CMake developpers did a good job to make it possible in CMake 2.6. So not initially designed for it does not meant it won't ever be supported. > With the `module' tool, I would load the appropriate modules, run cmake > without any > parameters, and (if the `module'-modules were set up with appropriate > discipline) get a working build. I agree that this is nicer for > everyone (provided `module' is available), My point of view, using the right tool for the right task and avoid tool features bloat. So should we/you put development effort to port/design a portable "module tool" or should the needed constrained be included in CMake? I think I did have a look for a "CRAY module" tool port for linux in the past and I did find something but I cannot put the hand on it right now. > but perhaps the CMake > documentation could be explicit that you need to do something external > to ensure that `incorrect' versions of libraries cannot be found by the > system. I think you cannot document something which has not been _widely_ encountered. -- Erk _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake