Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ADIOS2 #4944

Merged
merged 1 commit into from
Aug 5, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
118 changes: 118 additions & 0 deletions var/spack/repos/builtin/packages/adios2/package.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
##############################################################################
# Copyright (c) 2013-2017, Lawrence Livermore National Security, LLC.
# Produced at the Lawrence Livermore National Laboratory.
#
# This file is part of Spack.
# Created by Todd Gamblin, tgamblin@llnl.gov, All rights reserved.
# LLNL-CODE-647188
#
# For details, see https://github.com/llnl/spack
# Please also see the NOTICE and LICENSE files for our notice and the LGPL.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License (as
# published by the Free Software Foundation) version 2.1, February 1999.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY OF
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the terms and
# conditions of the GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
##############################################################################
from spack import *


class Adios2(CMakePackage):
"""Next generation of ADIOS developed in the Exascale Computing Program"""

homepage = "https://www.olcf.ornl.gov/center-projects/adios/"
url = "https://github.com/ornladios/ADIOS2/archive/v2.0.0.tar.gz"

version('develop', branch='master',
git='https://github.com/ornladios/ADIOS2.git')

version('2.0.0', '019115e5c6ac28bd0f4201f590f5d994')

variant('shared', default=True,
description='Also build shared libraries')
variant('mpi', default=True,
description='Enable MPI')
# transforms (not yet implemented)
# variant('bzip2', default=True,
# description='Enable BZip2 compression')
# variant('zfp', default=True,
# description='Enable ZFP compression')
# transport engines
variant('dataman', default=True,
description='Enable the DataMan engine for WAN transports')
# currently required by DataMan, optional in the future
# variant('zeromq', default=False,
# description='Enable ZeroMQ for the DataMan engine')
variant('hdf5', default=False,
description='Enable the HDF5 engine')
variant('adios1', default=False,
description='Enable the ADIOS 1.x engine')
# language bindings
variant('python', default=True,
description='Enable the Python >= 2.7 bindings')

# requires mature C++11 implementations
conflicts('%gcc@:4.7')
conflicts('%intel@:15')
conflicts('%pgi@:14')

# DataMan needs dlopen
conflicts('+dataman', when='~shared')

depends_on('cmake@3.5.0:', type='build')

# contained in thirdparty/
# depends_on('googletest')
# depends_on('pugixml')

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed these are embedded private dependencies that are built-in. We currently don't even support external versions of them, though we certainly could in the future if that's important for spack integration

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, it is usually a good thing to be able to switch between internally shipped and externally (maybe even patched) versions.

Copy link
Member Author

@ax3l ax3l Aug 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chuckatkins I actually had a very time patching the dependencies of gRPC recently, so if I could make a wish: yes, please :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ax3l @chuckatkins it's safer to embed these dependencies since APIs might change. It's good that from time to time we check for updates, adapt to the more recent versions and test. We recently run into a situation with the zfp wrapper in the current ADIOS2 master, zfp 0.5.0 wouldn't work since we are using zfp 0.5.1 API.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely, we do it similarly.

Nevertheless, be aware that in packaging we can define upper bounds for the last tested API.
Additionally, embedding dependencies by default leads to the risk to carry into a project:

  • the burden of maintenance of these packages for exotic platforms/new compilers/etc. if they break
  • the risk of forgetting to backport needed patches upstream

# depends_on('kwsys')
# depends_on('nlohmannjson')
# depends_on('pybind11@2.1.1:', when='+python')

depends_on('mpi', when='+mpi')

depends_on('hdf5', when='+hdf5')
depends_on('hdf5+mpi', when='+hdf5+mpi')
depends_on('adios', when='+adios1')
depends_on('adios+mpi', when='+adios1+mpi')

depends_on('bzip2', when='+bzip2')
depends_on('zfp', when='+zfp')

extends('python', when='+python')
depends_on('python@2.7:', type=('build', 'run'), when='+python')
depends_on('py-numpy@1.6.1:', type=('build', 'run'), when='+python')
depends_on('py-mpi4py@2.0.0:', type=('build', 'run'), when='+mpi +python')

def cmake_args(self):
spec = self.spec

args = [
'-DADIOS2_BUILD_SHARED_LIBS:BOOL={0}'.format((
'ON' if '+shared' in spec else 'OFF')),
'-DADIOS2_BUILD_TESTING=OFF',
'-DADIOS2_USE_MPI={0}'.format((
'ON' if '+mpi' in spec else 'OFF')),
'-DADIOS2_USE_BZip2={0}'.format((
'ON' if '+bzip2' in spec else 'OFF')),
'-DADIOS2_USE_ZFP={0}'.format((
'ON' if '+zfp' in spec else 'OFF')),
'-DADIOS2_USE_DataMan={0}'.format((
'ON' if '+dataman' in spec else 'OFF')),
'-DADIOS2_USE_ZeroMQ={0}'.format((
'ON' if '+dataman' in spec else 'OFF')),
'-DADIOS2_USE_HDF5={0}'.format((
'ON' if '+hdf5' in spec else 'OFF')),
'-DADIOS2_USE_ADIOS1={0}'.format((
'ON' if '+adios1' in spec else 'OFF')),
'-DADIOS2_USE_Python={0}'.format((
'ON' if '+python' in spec else 'OFF'))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple things to watch out for:

  1. Does it use the correct Python? Some CMake projects have a flag that lets you pick the correct Python executable to use. It should be first in your PATH though.
  2. Does it install the Python libraries to the correct location (<prefix>/lib/python2.7/site-packages, where <prefix> is the prefix of Adios2 and 2.7 is the MAJOR.MINOR version of Python)? I've seen too many packages that installed their Python libraries to the Python installation prefix instead of their own prefix. Or they installed them to a different directory hierarchy than lib/python2.7/site-packages. Some CMake packages have an option to control this.

]
return args