[CMake] Call for Module maintainer volunteers

Miguel A. Figueroa-Villanueva miguelf at ieee.org
Wed Jul 25 12:55:25 EDT 2007


On 7/25/07, Bill Hoffman wrote:
> Mike Jackson wrote:
> > <snip>
> >
> > I think Kitware should layout the "rules" for writing a module
> > including naming conventions, formatting of the module, various
> > options, and all that stuff. THEN a DEMO Module needs to be written
> > that follows ALL the guidelines and shows lots of different scenarios
> > that can be used: Windows specific stuff, OS X Frameworks stuff,
> > Unix/Linux specific stuff.
> The rules are right here:
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/readme.txt?rev=1.12&root=CMake&view=auto
>
> Existing module variables must be maintained for backwards compatibility
> at this point.  That does
> not mean that new variables can not be added to the modules that provide
> the "correct" way of
> doing things.   We have been doing this for some time now.

This is true, although I think the readme.txt has to evolve a little.
That is, clarify some stuff maybe and remove any ambiguities that
might arise in the non-conventional cases. That will most likely
happen in the list as the patches and changes start to be implemented
and the issues arise.

Having a demo module sounds as a good idea, but I don't think that
only one will do the trick. Sometimes you have a find library module
that sets the include dirs, lib dirs, libs to link to etc. Sometimes
you have a find executable module that usually don't set those
variables but would set the XXX_EXECUTABLE (FindLATEX). And other
times you have very complex find modules like FindwxWidgets, which has
this complexity because of wxWidgets' build system (i.e., it would be
so much easier to write a wxWidgets find module if they used CMake
themselves to do things the right way ;) ).

I think an easier thing to do is to create a list at the end of the
readme.txt list with modules that have been tagged as good examples.
That is, they are clean according to the current standards and do not
have exceptions due to backwards compatibility issues. If that list
existed, then when a new module was to be implemented they would take
example from certified modules and not implement things in the "wrong
way" without knowing they are that way due to compatibility
constraints.

-- Miguel


More information about the CMake mailing list