Here's an inventory of modules that have EXCLUDE_FROM_DEFAULT in their module configuration, organized by their group. Note that group membership is purely a function of directory location, and not something that's explicitly specified in a CMake file.
Also note that if a module contains an "itk-module-init.cmake" file, then it is still not enabled even if its respective Group_* option is enabled. These _should_ be "bridge" modules that require system-installed third-party libraries [1]. These modules can only be enabled by directly enabling their respective Module_* option. These are indicated in the list below with a "*". Finally, note that while Module_ITKGDCM and Module_ITKOpenJPEG are flagged as EXCLUDE_FROM_DEFAULT, they are typically enabled as dependencies of Module_ITKIOGDCM, which is a "default" module. Group_Bridge *Module_ITKVtkGlue Group_Compatibility Module_ITKDeprecated *Module_ITKV3Compatibility Group_IO *Module_ITKIODCMTK *Module_ITKIOMINC Module_ITKIOPhilipsREC Group_Nonunit Module_ITKReview Group_Segmentation *Module_ITKLevelSetsv4Visualization Group_ThirdParty *Module_ITKDCMTK *Module_ITKGDCM Module_ITKMINC Module_ITKOpenJPEG Group_Video *Module_ITKVideoBridgeOpenCV *Module_ITKVideoBridgeVXL Group_Remote (there is no CMake option for this group) Module_LesionSizingToolkit Module_MGHIO Module_SCIFIO Module_SmoothingRecursiveYvvGaussianFilter [1] http://itk.org/gitweb?p=ITK.git;a=commit;h=8170063fa0832003974f1066313b48016253cae1 On Wed, Jan 15, 2014 at 9:23 AM, Bradley Lowekamp <[email protected]>wrote: > Hello, > > I would like to propose that we need a Contrib group. > > There has been recent push to migrate many contributions into remote > modules. I believe this is premature. > > A remote module is a good solution for medium to large contributions which > are maintained by contributors. However, the current system does not > leverage CDash or Gerrit. There is no easy way to review and comment on > remote module code. Gerrit can not do builds for cross platform testing, > and the night build systems does not easily test these modules. Yes, the > module can be enable in certain cases, but this is not a sustainable > practice. > > Also for smaller contribution of just a class or two, the burden of code > maintenance in increased when compared to just having it in the repository. > > I would like to propose that we create a Contrib group, were these > contributed remote modules and internal modules can exist. The goal here is > that users can more easily turn on all the contributed modules if needed. > Also I believe it would be do able to an option to our nightly build > script, so that after the normal build a separate > configure/build/test/coverage/submit can be done on the group. > > This is my initial thought how how we can improve the current situation > before it gets too unmanageable. > > > Brad > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.itk.org/mailman/listinfo/insight-developers > -- Brian Helba Medical Imaging Kitware, Inc.
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
