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.

Sign up for GitHub

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

Jump to bottom

Paraview fixes #767

Merged
merged 3 commits into from
Apr 14, 2016
Merged

Paraview fixes #767

merged 3 commits into from
Apr 14, 2016

Conversation

mathstuf
Copy link
Contributor

@mathstuf mathstuf commented Apr 8, 2016

@mathstuf
paraview: use the right cmake variables
3a4aac0
@mathstuf
paraview: use internal netcdf
6e56ba9 
VTK needs to learn to cope with netcdf being split like this.
@mathstuf
paraview: use internal hdf5
20b9f34 
Spack's HDF5 is too new. Rather than forcing everything in a ParaView
chain to use older HDF5, use the internal one until ParaView is patched
properly.
@dhandeo
Copy link
Contributor

dhandeo commented Apr 13, 2016

+1. My branch https://github.com/dhandeo/spack/tree/paraview-qt-osx2 has similar commits, but now I will make separae pr for rebased qt-osx, and another one for paraview+qt

@tgamblin
Copy link
Member

@mathstuf @dhandeo Could Paraview just depend on specific versions of HDF/netcdf?

@tgamblin tgamblin merged commit d6a232d into spack:develop Apr 14, 2016
@mathstuf mathstuf deleted the paraview-fixes branch April 14, 2016 12:10
@mathstuf
Copy link
Contributor Author

NetCDF? No. VTK wants the C++ bindings to live in the same prefix (it's on my list to fix so that we can stop using this heavily patched setup, but has been low priority). For HDF5, yeah, probably, but I'd rather not force an old version on anyone else in the ParaView hierarchy (it'd just be limited to VTK's readers and writers).

@tgamblin
Copy link
Member

@mathstuf: ok, sounds good to me. Paraview's up to you guys... the old version of HDF5 could likely happily coexist with others, though. The only thing would be once the #311 stuff gets added, Spack may try to actually use the old version for other builds if it is the only thing installed.

@adamjstewart
Copy link
Member

@mathstuf: I've actually been working with some of the guys from the ACME project and they also have the problem that their build system expects the NetCDF-Fortran libraries to be installed in the same location as the NetCDF-C libraries. Their working on patching their CMake macros, but in the meantime I just hacked Spack to install in the same prefix as NetCDF-C.

olupton pushed a commit to olupton/spack that referenced this pull request Feb 7, 2022
Add git to list of deployed modules (spack#767)
39864d1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@mathstuf @dhandeo @tgamblin @adamjstewart