User Software :: Reorganization of the software collection

TOC:

1. References
2. Summary of current status
3. Suggested changes
4. Changelog

• Future of the LUS (Discussion on the forum)
• usg.lofar.org user account migration (Discussion on the Forum)

Surveys:

• Software changes are checked into the LUS repository, but they are not using the LUS build system to create running programs, as they are having difficulties with building part of teh software in LUS.
• There is little CMake experience in their group.

Transients:

• Contact: John Swinbank (UvA)
• They are not using the LUS repository or the build system. They are doing all their development and building/testing on local systems. Their local developments will be merged back in at some point
• There is ample CMake experience in the group.

Pulsar:

• Contact: Anastasia Alexov (UvA), Jason Hessels (ASTRON)
• They use the LUS repository for code maintenance/changes. They use the build system to set up new systems completely from scratch (apart from pgplot), which works even for the GRID . This is a feature they do not want to loose, as all software needed for pulsar data processing and analysis is now in one locations and it is all working together.
• To build it all takes a long time (especially first time), and improvements can be made; certain depencies do not have to build all the time.
• They do not have much CMake experience.

CR-Tools:

• Contact: Frank Schroeder, Daniel Huber, Katrin Link (KIT); Pim Schellart, Martin van den Akker (RUN)
• All software is developed in and committed to the LUS repository.
• They use the LUS build system. Installing the entire package is sometimes problematic on new systems (not all dependiences are detected properly).
• Also during development/testing they use the build system of LUS
• Pim and Martin are up to speed in CMake

RM Synthesis:

• Small package, but development and build has been taken out of LUS; Build time too large which didn't work for them! They intend to keep the code separated.
• Their group is Munich based, and so is quite isolated from LOFAR development → difficult to find the right people to help them out with problems.
• Uncertain of their CMake knowledge capabilities.

Design goals

1. Better modularity: split collection into smaller sub-projects.
2. (Optional) common core: allow sharing of build environment.
3. Enable stand-alone development of individual software packages.

• Demonstration of how to handle package in the case the source code is not part of the original checkout from the repository: the RM-Synthesis package now can be build both as part of a full check-out from the LUS code repository as well as being dynamically fetched in case the sources reside in another repository.

  if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/RM)
    ##
    ##  Package is part of the current code tree
    ##
    ExternalProject_Add (rm
      PREFIX ${CMAKE_CURRENT_BINARY_DIR}/RM
      DOWNLOAD_DIR download
      SOURCE_DIR source
      URL ${CMAKE_CURRENT_SOURCE_DIR}/RM
      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} -DRM_WITH_ITPP=${RM_WITH_ITPP} -DRM_WITH_ARMADILLO=${RM_WITH_ARMADILLO}
      )
  else (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/RM)
    ##
    ##  Package is not part of current code tree - fetch sources from repository
    ##
    ExternalProject_Add (rm
      PREFIX ${CMAKE_CURRENT_BINARY_DIR}/RM
      DOWNLOAD_DIR download
      SOURCE_DIR source
      SVN_REPOSITORY http://usg.lofar.org/svn/code/trunk/src/RM
      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} -DRM_WITH_ITPP=${RM_WITH_ITPP} -DRM_WITH_ARMADILLO=${RM_WITH_ARMADILLO}
      )
  endif (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/RM)

  Without going into all the the details here: the CMake scripts now have been set up such that they are able to to deal with the code of the various packages being hosted within individual repositories. One of the recurring complaints about LUS has been, that in order to get to one package a lot of material was getting check out, which was not of interest for that specific purpose. Nevertheless the option to utilize a common base framework (for system inspection and configuration) was something people were in favor of, such that an updated framework needs to be a bit more flexible - the above bit of code provides that level of flexibility. — Lars Bahren 2011/11/08 12:16

• Merged contents of src/DSP into src/contrib; as both directories contained contributed bits of code anyway, there was little reason to keep around two different collections. — Lars Bahren 2011/11/07 18:51
• Moving contents of LOFARSOFT/data/lopes to src/CR-Tools/data, as the files are used with the CR software only. Given the fact we are planning to better separate the individual packages in the software collection, we should not be keeping package-specific data in a directory shared by everybody. — Lars Bahren 2011/11/04 14:02

← User Software