CMake/GSoC: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
(Added initial CMake 2011 ideas page for Google Summer of Code 2011)
 
No edit summary
Line 44: Line 44:
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).


=== Project: R CMake Compatibility ===


'''Brief explanation:''' The addition of a facility to the R statistics engine that increases R interoperability with CMake enabled packages.  Conceptually, this would require the generation of appropriate CMakeLists.txt files that would allow R to be built "out-of-the-box" on standard platforms along with any code changes necessary to support a standard array of compilers via CMake portability support.  This project would be synergistic with recent efforts to use R as a statistics engine from the ITK and VTK Open Source toolkits and would help make the use of the R interface from VTK and ITK more widely accepted, tractable and portable.
=== Project: CMake ninja generator ===


'''Expected results:''' A new facility added to the R statistics engine that makes it compatible with CMake enabled projects. A user of CMake enabled Open Source projects such as ITK and VTK should reasonably expect to download R code on a supported platform and be able to easily incorporate the maintenance, generation and packaging of R executables and libraries in a multi-platform/multi-toolkit project.
'''Brief explanation:''' CMake supports regular makefiles, and IDE's for all versions of Visual Studio, and Xcode.  However, the new tool Ninja http://martine.github.com/ninja/manual.html has some properties that might allow faster builds over traditional makefiles. The idea of this project would be to create a new backend build tool format for CMake.


'''Prerequisites:''' Some familiarity with CMake, C++ and R.
'''Expected results:''' A new option for any project using CMake to build with the Ninja tool.


'''Mentor:''' Wesley Turner (wes dot turner at kitware dot com).
'''Prerequisites:''' Experience with C++ programming, and a working knowledge of build tools like make.


=== Project: CDash Bug tracker integration ===
'''Mentor:''' Bill Hoffman.
 
'''Brief explanation:''' A disconnect between CDash and bug trackers currently exists. Developers often want to link a current bug fix with a dashboard submission and, in order to achieve this feature, they currently enter the bug number in the commit log message. Moreover, new failures appearing on the dashboard should be ultimately entered and tracked in a bug tracker either manually or automatically.
The goal of this project is to tie CDash and bug trackers to allow developers to link a current submission with a bug and track its evolution. Also, a continuous report should be generated to show the different builds leading to a bug fix (or bug report).
 
'''Expected results:''' Support for integration of bug trackers within CDash. Mantis (www.mantisbt.org) will be the primary bug tracker target but the framework should be flexible to support any other bug trackers (via Web API or other mechanism to be defined).
 
'''Prerequisites:''' Some familiarity with CDash. Familiar with PHP/MySQL/PgSQL.
 
'''Mentor:''' Julien Jomier.

Revision as of 22:31, 11 March 2011

Project ideas for the Google Summer of Code 2011

Guidelines

Students

These ideas were contributed by developers and users of CMake. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.

The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see GSoC proposal guidelines for further guidelines on writing your proposal.

Adding Ideas

When adding a new idea to this page, please try to include the following information:

  • A brief explanation of the idea.
  • Expected results/feature additions.
  • Any prerequisites for working on the project.
  • Links to any further information, discussions, bug reports etc.
  • Any special mailing lists if not the standard mailing list for the CMake.
  • Your name and email address for contact (if willing to mentor, or nominated mentor).

If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.

Project Ideas

Project page, mailing lists, dashboard.

Project: CMake Autoconf Compatibility

Brief explanation: One of the things that prevents some projects from migrating to CMake is their current investment and shared knowledge of the auto* family of tools. Creating improved compatibility functions matching the familiar auto* syntax for things like header checks, command line switches to cmake etc would improve this situation significantly. The student would need to assess syntax that should be replicated in both the CMake language, and common command line switches such as --prefix=... Some modules already exist that implement some of this functionality, and these could be used as a starting point.

Expected results: Improved implementation of auto* like syntax to aid projects when migrating their build systems over to CMake. Additional documentation on the migration process, and working with existing communities that have needs in this area.

Mentor: Bill Hoffman (bill dot hoffman at kitware dot com).

Project: CMake Project Generator

Brief explanation: The addition of a facility in CMake to automatically generate CMakeLists files based upon the source files present in a directory. So a developer can point CMake at a directory full of source files with a '--generate-project' argument for example, and automatically generate a project. This should detect if source files contain the QOBJECT macro, and need Qt's moc running on them, adding them to the appropriate CMake variable. This would be limited in scope to relatively simple projects wanting a single executable to be built from the source files, with some heuristics or switches to determine what toolkit etc it being used.

Expected results: A new facility added to the CMake suite of tools to generate simple CMakeLists files when supplied the path to a source directory. The user should reasonably expect to be able to run generate CMakeLists files, run CMake on these files and type make to build their project. Similar in functionality to the feature provided by qmake.

Prerequisites: Some familiarity with CMake, C++ and Qt.

Mentor: Marcus Hanwell (marcus dot hanwell at kitware dot com).


Project: CMake ninja generator

Brief explanation: CMake supports regular makefiles, and IDE's for all versions of Visual Studio, and Xcode. However, the new tool Ninja http://martine.github.com/ninja/manual.html has some properties that might allow faster builds over traditional makefiles. The idea of this project would be to create a new backend build tool format for CMake.

Expected results: A new option for any project using CMake to build with the Ninja tool.

Prerequisites: Experience with C++ programming, and a working knowledge of build tools like make.

Mentor: Bill Hoffman.