slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Transitioning VisIt to CMake PowerPoint Presentation
Download Presentation
Transitioning VisIt to CMake

Loading in 2 Seconds...

play fullscreen
1 / 1

Transitioning VisIt to CMake - PowerPoint PPT Presentation


  • 146 Views
  • Uploaded on

Transitioning VisIt to CMake. Brad Whitlock ASQ Division L awrence Livermore National Laboratory.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Transitioning VisIt to CMake' - dunn


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Transitioning VisIt to CMake

Brad Whitlock

ASQ Division

Lawrence Livermore National Laboratory

VisIt is a visualization and data analysis tool with a complex build system that transforms over 1 million lines of C++ source code into many executables and hundreds of plug-in shared libraries. Historically, VisIt has relied on two distinct build systems to support different platforms. In early 2010, both build systems were replaced with a single build system based on CMake. The resulting build system has proven superior and has eliminated a long-standing maintenance burden.

Introduction:

Methods:

  • VisIt has a very complex build system that needs to be simplified to boost developer productivity.
  • We chose to write a new build system that replaces both old ones using CMake (cross-platform make) from Kitware, Inc.

Incremental replacement of autoconf build system

Detect 3rd party libraries such as VTK, Qt, Python

Add targets for core VisIt libraries

Add targets for most important executables

Add targets for plug-ins

Add advanced features

After creating a basic build system with just the main targets, we started developing on all platforms to avoid problems with portability.

  • VisIt comprises:
    • 5 main executables
    • 45+ core libraries
    • 20+ plot plug-ins
    • 45+ operator plug-ins
    • 100+ database plug-ins
    • Each plug-in consists of 3-6 shared libraries

CLI

Metadata server

Plug-ins

Plug-ins

GUI

Compute server

Viewer

Plug-ins

Plug-ins

Plug-ins

Core libraries

  • Two build systems: autoconf for UNIX&Mac builds, Microsoft Visual Studio for Windows builds
  • Each build system represents hundreds of build targets
  • Responsibility for Windows build was on 1 person, which was not very fair and took an estimated 2 months/year to maintain

Results:

Discussion:

  • Conversion to a CMake build system took around 2 developer months of effort to achieve all features on all platforms. This also includes enhancements never before present in the old systems: make install, automatic packaging, symbol visibility, static builds.
  • Our CMake build system works on all platforms and a single source of build-logic informs the entire build process so maintenance going forward will be minimized.
  • Developers on different platforms can use their preferred development environment instead of a 1 size fits all approach.
  • Switching to CMake had other benefits:
    • Out of source build
    • Better build dependencies
    • Support for parallel make over all directories
  • Choosing CMake was the right choice for VisIt since we were able to:
    • Consolidate all build-logic
    • Address portability
    • Target multiple build environments
    • Simplify the installation and packaging process
  • Getting started with CMake does not take much time and projects can increase in complexity as needed. Complexity can be managed by using built-in functions and by reusing macros that set up build targets. We have used CMake to replace 2 build systems, ensuring we have a single up-to-date build system at all times. This reduces errors and frees developers to work on actual source code.

LLNL-POST-468557

This work performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344.