public:user_software:reorganization_of_the_software_collection

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
public:user_software:reorganization_of_the_software_collection [2011-11-04 11:07] – Lars Bahrenpublic:user_software:reorganization_of_the_software_collection [2017-03-08 15:27] (current) – external edit 127.0.0.1
Line 7: Line 7:
   - [[#References]]   - [[#References]]
   - [[#Summary of current status]]   - [[#Summary of current status]]
 +  - [[#Suggested changes]]
 +  - [[#Changelog]]
  
 ==== References ==== ==== References ====
  
   * [[http://lus.lofar.org/forum/index.php?topic=683.0|Future of the LUS]] (Discussion on the forum)   * [[http://lus.lofar.org/forum/index.php?topic=683.0|Future of the LUS]] (Discussion on the forum)
 +  * [[http://lus.lofar.org/forum/index.php?topic=824.0|usg.lofar.org user account migration]] (Discussion on the Forum)
  
 ==== Summary of current status ==== ==== Summary of current status ====
Line 19: Line 22:
    
 **Transients**: **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   * 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.   * There is ample CMake experience in the group.
    
 **Pulsar**: **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.   * 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.   *  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.
Line 28: Line 33:
    
 **CR-Tools**: **CR-Tools**:
-  * //Contact//: Frank Schroeder, Daniel Huber, Katrin Link (KIT); Pim Schellart, Martin van den Akker (RUN)+  * __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.   * 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).   * They use the LUS build system. Installing the entire package is sometimes problematic on new systems (not all dependiences are detected properly).
Line 34: Line 39:
   * Pim and Martin are up to speed in CMake   * Pim and Martin are up to speed in CMake
    
-RM Synthesis:+**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.   * 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.   * 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.   * Uncertain of their CMake knowledge capabilities.
  
 +==== Suggested changes ====
 +
 +__Design goals__
 +
 +  - Better modularity: split collection into smaller sub-projects.
 +  - (Optional) common core: allow sharing of build environment.
 +  - Enable stand-alone development of individual software packages.
 +
 +==== Changelog ====
 +
 +  * 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. <code cmake>
 +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)
 +</code> 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. --- //[[bahren@astron.nl|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. --- //[[bahren@astron.nl|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. --- //[[bahren@astron.nl|Lars Bahren]] 2011/11/04 14:02//
  
 \\ \\
  • Last modified: 2011-11-04 11:07
  • by Lars Bahren