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

[Jed Brown]

On Fri 2008-11-07 12:57, Eric Noulard wrote:
> 2008/11/7 Jed Brown <jed at 59a2.org>:
[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081107/896245cd/attachment.pgp>