On Fri 2008-11-07 12:57, Eric Noulard wrote: > 2008/11/7 Jed Brown <[EMAIL PROTECTED]>: [snip] > > 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.
Great, please reinterpret my claims of widespread brokenness as a proposal for 2.8. > > 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 that consistency in resolving paths and providing hints when resolving recursive dependencies is actually manageable. The problem with requiring a (hypothetical cross-platform analogue of `module') CModule tool to resolve multiple versions is that the users must have module files set up *before* they start to configure the CMake project. While it might be considered good practice (at least by developers CMake projects) for everyone with multiple versions to use CModule, users will not want to install and configure such a tool just to install your package. OTOH, if CMake becomes as pervasive as autoconf, it would be reasonable to expect people with multiple versions to use CModule. Maybe someone can think of a clever way to make CModule provide minimal version selection without the entry cost of asking the user to write lots of module files. What if find_library() and friends consulted CModule and if there are multiple versions of the library not yet assigned to an active module (as determined by looking through suggested paths) then CModule prompts the user to select which one to use and (optionally) assign other versions to modules and group related libs into modules. This way a user would assemble their CModule configuration lazily. This probably has lots of fatal flaws, but maybe it'll get the ball rolling. > 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. http://modules.sourceforge.net/ There hasn't been a release for a couple years and development looks slow, but I think this is mostly because it's mature rather than abandoned. It's frequently available on clusters. Integration with a distribution would be really cool. > > 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. You're right of course. Jed
pgpde0Hnfd4U5.pgp
Description: PGP signature
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
