Conversation
| ) | ||
|
|
||
| @property | ||
| def mpi_headers(self): |
There was a problem hiding this comment.
supposedly that's how one overrides spec['mpi'].headers which returns HeaderList object which by default looks for * headers and is recursive. Looking for mpi.h in include64 looks ok to me. Hopefully include64 always exists.
| # recurse from self.prefix will find too many things for all the | ||
| # supported sub-architectures like 'mic' | ||
| return find_headers( | ||
| 'mpi', root='{0}64'.format(self.prefix.include), recurse=False) |
There was a problem hiding this comment.
Never seen an include64 before, but Intel does some weird things. If you want, you can add it to lib/spack/spack/util/prefix.py so that you can use self.prefix.include64.
There was a problem hiding this comment.
If I do this I will have to check which mpi it is to now which include to use. This way it is transparent for the dependents to mpi. And is is the equivalent to what is done for mpi_libs
In fact <prefix>/include64 in this case is a symbolic link to <prefix>/linux64/include
There was a problem hiding this comment.
Oh yes, I'm not suggesting you get rid of mpi_headers, just saying you could replace '{0}64'.format(self.prefix.include) with self.prefix.include64.
| high-performance simulation of large biomolecular systems.""" | ||
|
|
||
| homepage = "http://www.ks.uiuc.edu/Research/namd/" | ||
| url = "file://NAMD_2.12_Source.tar.gz" |
There was a problem hiding this comment.
Does this actually work? For most other packages I've used:
url = 'file://{0}/NAMD_2.12_Source.tar.gz'.format(os.getcwd())This allows Spack to download the file if it is present in the current directory.
There was a problem hiding this comment.
It does not find it and take it from the mirror. But I can change it so there is no need to add it first to a mirror.
| depends_on('fftw@3:', when="fftw=3") | ||
|
|
||
| # depends_on('fftw@3:', when="fftw=mkl") | ||
| depends_on('intel-mkl', when="fftw=mkl") |
There was a problem hiding this comment.
I wonder if we should make fftw a virtual provider.
There was a problem hiding this comment.
I am not totally sure but I think that mkl as a different interface but when you install it you can compile the a part to have the proper interface.
And if we add provide('fftw') the package fftw should be renamed.
| description='Enable the use of FFTW/FFTW3/MKL FFT') | ||
|
|
||
| variant('interface', default='none', values=('none', 'tcl', 'python'), | ||
| description='Enables TCL and/or python interface') |
There was a problem hiding this comment.
I'm not sure if this should be a multi-valued variant or not. It wouldn't be hard to have +tcl and +python variants. Multi-valued variants are useful when there are too many possible values to create variants for or if the values are mutually exclusive.
There was a problem hiding this comment.
I did it because they are kind of exclusive, according to the help of the build script +python enforce +tcl if it is 2 separated variant I have to also add a check because ~tcl+python is not valid.
|
|
||
| def build(self, spec, prefix): | ||
| with working_dir('{0}-spack'.format(self.arch)): | ||
| make() |
There was a problem hiding this comment.
If you override build_directory, you won't have to do this for every phase:
@property
def build_directory(self):
return '{0}-spack'.format(self.arch)|
Hell yes!!!! Has anyone started VMD? |
|
|
||
| def build(self, spec, prefix): | ||
| with working_dir(self.build_directory): | ||
| make() |
There was a problem hiding this comment.
I don't think you need to define build anymore as this is the default implementation.
alalazo
left a comment
There was a problem hiding this comment.
LGTM. Only a couple very minor comments.
| s.sbin = join_path(s, 'sbin') | ||
| s.etc = join_path(s, 'etc') | ||
| s.include = join_path(s, 'include') | ||
| s.include64 = join_path(s, 'include64') |
There was a problem hiding this comment.
OT: I wonder why in this file we have +12/-11 lines diff, while at a first glance it seems you added only one line...
There was a problem hiding this comment.
I kept the alignment of spaces before the =
|
|
||
| def build(self, spec, prefix): | ||
| with working_dir(self.build_directory): | ||
| make() |
|
ping @adamjstewart |
* Initial version of the namd package * Modified charm to consider compile against intel/intel-mpi * Correction of namd to compile with intel-mkl and intel compiler * Adding inclue64 in the prefix * adding property for the build directory * removing useless function build
* Initial version of the namd package * Modified charm to consider compile against intel/intel-mpi * Correction of namd to compile with intel-mkl and intel compiler * Adding inclue64 in the prefix * adding property for the build directory * removing useless function build
* Initial version of the namd package * Modified charm to consider compile against intel/intel-mpi * Correction of namd to compile with intel-mkl and intel compiler * Adding inclue64 in the prefix * adding property for the build directory * removing useless function build
This adds the package for namd. To download the source it uses a login password, but if I got it right anyone can ask for it for non-commercial uses.
I did not test all the possible installation, just
gccwith and withouttcl/pythoninterfaces andfftw=3,and
intelwithintel-mpiandfftw=mklIn both case with
charm backend=mpiWhile testing this package for intel tools (compiler, mpi, mkl), I add to tweak the package
charmandintel-mpi.It should be only additions and corrections on the way the backends where checked. @eschnett can you check that I did not break anything in
charm?For
intel-mpi@davydden and @alalazo you are the one that wrote it.