Mike Jackson wrote:
My own thoughts on this:
While I am not sure I would be able to maintain any modules directly,
I would be MORE than happy to serve as a "Mac OS X" consultant for
those who maintain modules and do not have access to OS X equipment.
I agree that some sort of consistency among all the modules is needed.
Consistent APIs help keep developer productivity high and the amount
of "surprises" to a minimum. When and how to aline the modules to a
consistent state is another whole debate. My thought is sooner rather
than later or do it at a major CMake release number, like 3.0, or have
the new modules that break current CMakeLists.txt files as an Optional
install for cmake, that way those of us working on projects can use
the newer versions.. Just some suggestions..
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.
-Bill
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
