Opened 11 years ago
Closed 11 years ago
#39282 closed submission (fixed)
Submission: octopus
Reported by: | dstrubbe (David Strubbe) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.3 |
Keywords: | Cc: | neverpanic (Clemens Lang) | |
Port: | octopus |
Description
Portfile for Octopus, a time-dependent density-functional theory code, intended for the science category.
Attachments (6)
Change History (20)
Changed 11 years ago by dstrubbe (David Strubbe)
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 11 years ago by dstrubbe (David Strubbe)
Sorry about the version confusion. I did mean to put 4.1.0 -- it is not actually released yet, though the tarball is available. I am a developer of this code, and we are planning to release very shortly (days, hopefully). Knowing that it takes a little time to check issues with a new port, I thought I would get the process started even though the release didn't come out yet, so it is ready then. Here is a revised Portfile, with some other enhancements; see what you think. I will confirm here when the release is live and the port can actually be committed.
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile.2 added |
---|
comment:3 follow-up: 4 Changed 11 years ago by dstrubbe (David Strubbe)
This release is now live. This should fix the livecheck and checksum issues.
comment:4 follow-up: 6 Changed 11 years ago by larryv (Lawrence Velázquez)
Replying to dstrubbe@…:
This release is now live. This should fix the livecheck and checksum issues.
A few more things:
- We prefer RMD160 and SHA256 for Portfile checksums. You should leave out SHA1, unless upstream publishes a SHA1 hash.
- The default for
use_parallel_build
is already “yes”, so you can leave that out. - The default for
test.cmd
is the value ofbuild.cmd
, which defaults to “make”, so you can leave that out if you haven’t changedbuild.cmd
. - Using
active_variants
procs directly in variant scripts will cause issues when MacPorts processes the Portfile on systems that don’t have the pertinent ports present. See this macports-dev post. In short, they need to be in apre-configure
script.
comment:5 Changed 11 years ago by dstrubbe (David Strubbe)
Thanks. I switched to SHA256, updated checksums, fixed master_sites, moved configure.args outside pre-configure (or else the configure.args-append in the variants scripts didn't seem to do anything), removed the defaults you mention, and moved the require_active_variants calls to pre-configure. However, the require_active_variants don't seem to have any effect now; I can't figure out what the problem is.
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile.3 added |
---|
comment:6 Changed 11 years ago by neverpanic (Clemens Lang)
Replying to larryv@…:
- Using
active_variants
procs directly in variant scripts will cause issues when MacPorts processes the Portfile on systems that don’t have the pertinent ports present. See this macports-dev post. In short, they need to be in apre-configure
script.
This only applies to active_variants 1.0
and has been fixed in active_variants 1.1
. Please move require_active_variants
out of the pre-configure phase again.
comment:7 Changed 11 years ago by dstrubbe (David Strubbe)
All right, I have moved require_active_variants back again, and it seems to work again. Does the Portfile look good now?
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile.4 added |
---|
comment:8 Changed 11 years ago by neverpanic (Clemens Lang)
Cc: | cal@… added |
---|
The build fails for me:
********************************************** *** octopus + utilities will be generated ********************************************** checking for libxc... yes (-I /opt/local/include /opt/local/lib/libxc.a) checking for sgemm in -lsatlas... yes (-lsatlas) checking whether zdotc works... yes checking for cheev in ... yes () checking for gsl-config... /opt/local/bin/gsl-config checking for GSL - version >= 1.9... 1.15.0 checking whether GSL can be linked... yes checking for dfftw_plan_dft_1d... no checking for dfftw_plan_dft_1d in -lfftw3... no checking for dfftw_init_threads... no configure: error: Could not find required FFT library. Command failed: cd "/opt/local/var/macports/build/_opt_dports_science_octopus/octopus/work/octopus-4.1.0" && ./configure --prefix=/opt/local --with-libxc-prefix=/opt/local --with-blas=-lsatlas --disable-gdlib --without-sparskit --enable-newuoa FCCPP="/opt/local/bin/cpp-mp-4.7 -ansi" Exit code: 1
I'm attaching config.log
.
Changed 11 years ago by neverpanic (Clemens Lang)
Attachment: | config.log added |
---|
comment:9 Changed 11 years ago by dstrubbe (David Strubbe)
Hm, thanks for checking it out. Did the port correctly make sure you had fftw-3 installed? What version of fftw-3 do you have? This is what my fftw-3 @3.3.3_1+gcc46 gives me; does yours differ?
$ port contents fftw-3 Port fftw-3 contains: /opt/local/bin/fftw-wisdom /opt/local/bin/fftw-wisdom-to-conf /opt/local/include/fftw3.f /opt/local/include/fftw3.f03 /opt/local/include/fftw3.h /opt/local/include/fftw3l.f03 /opt/local/include/fftw3q.f03 /opt/local/lib/libfftw3.3.dylib /opt/local/lib/libfftw3.a /opt/local/lib/libfftw3.dylib /opt/local/lib/libfftw3.la /opt/local/lib/libfftw3_threads.3.dylib /opt/local/lib/libfftw3_threads.a /opt/local/lib/libfftw3_threads.dylib /opt/local/lib/libfftw3_threads.la /opt/local/lib/pkgconfig/fftw3.pc /opt/local/share/info/fftw3.info /opt/local/share/info/fftw3.info-1 /opt/local/share/info/fftw3.info-2 /opt/local/share/man/man1/fftw-wisdom-to-conf.1.gz /opt/local/share/man/man1/fftw-wisdom.1.gz
comment:10 Changed 11 years ago by neverpanic (Clemens Lang)
I do have fftw-3
installed:
:) clemens@cschlepptop:~$ port -v installed fftw-3 The following ports are currently installed: fftw-3 @3.3.3_1 (active) platform='darwin 12' archs='x86_64'
The symbols configure checks for don't seem to be present in my libfftw3.3.dylib
, though:
:) clemens@cschlepptop:~$ nm /opt/local/lib/libfftw3.3.dylib | grep dfftw :( clemens@cschlepptop:~$
Do I need to build fftw-3
with a specific variant?
comment:11 Changed 11 years ago by neverpanic (Clemens Lang)
Answering my own question: Yes, it seems fftw-3 +gcc47
does have these symbols.
comment:12 Changed 11 years ago by neverpanic (Clemens Lang)
It also seems to me configure will pick up "automagic" dependencies, if they are present:
configure: WARNING: Could not find NetCDF library. *** Will compile without NetCDF and ETSF I/O support checking for etsf_io... disabled (-I /usr/include ) configure: WARNING: Could not find etsf_io library. *** Will compile without ETSF I/O support checking for BerkeleyGW... no (-I /library -L/library -lBGW_wfn) configure: WARNING: Could not find BerkeleyGW library. *** Will compile without BerkeleyGW support checking for arpack library... no checking for arpack library with -larpack... no configure: WARNING: Could not find ARPACK library. *** Will compile without ARPACK support configure: WARNING: Could not find Libfm library. *** Will compile without Libfm support configure: WARNING: Could not find PFFT library. *** Will compile without PFFT support
To keep the build reproducible and to avoid linking against a port without specifying a dependency you should explicitly disable those by passing arguments to configure. If you want to support these libraries, add variants or add a dependency.
comment:13 Changed 11 years ago by dstrubbe (David Strubbe)
Ok, fftw-3 needs a Fortran variant, so I added a check. And I explicitly disabled these other libraries. Many are not available as ports anyway.
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile.5 added |
---|
comment:14 Changed 11 years ago by neverpanic (Clemens Lang)
Resolution: | → fixed |
---|---|
Status: | new → closed |
LGTM, commited in r107233. Thank you for your work.
Thanks. Some observations:
These lines can be removed because they are the defaults:
Setting
FCFLAGS=-O3 CFLAGS=-O3
inconfigure.args
can be more simply accomplished by settingconfigure.optflags
to-O3
.The port version is 4.1.0 but the livecheck says the latest version is 4.0.1. Perhaps livechecking http://www.tddft.org/programs/octopus/download/ would be more accurate. Downloading from there would be better too because it would avoid an HTTP redirect.
The checksums don't match.
The universal variant doesn't work:
You could disable the universal variant to resolve that. Usually we'd like to add a universal variant if possible, but these ports use gcc4x ports to compile, which makes a universal variant difficult.