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)

Portfile (2.5 KB) - added by dstrubbe (David Strubbe) 11 years ago.
Portfile.2 (3.6 KB) - added by dstrubbe (David Strubbe) 11 years ago.
Portfile.3 (3.8 KB) - added by dstrubbe (David Strubbe) 11 years ago.
Portfile.4 (3.6 KB) - added by dstrubbe (David Strubbe) 11 years ago.
config.log (72.4 KB) - added by neverpanic (Clemens Lang) 11 years ago.
Portfile.5 (4.5 KB) - added by dstrubbe (David Strubbe) 11 years ago.

Download all attachments as: .zip

Change History (20)

Changed 11 years ago by dstrubbe (David Strubbe)

Attachment: Portfile added

comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Thanks. Some observations:

These lines can be removed because they are the defaults:

distfiles           octopus-${version}.tar.gz
extract.suffix      .tar.gz
extract.cmd         tar
extract.pre_args    -xzf

Setting FCFLAGS=-O3 CFLAGS=-O3 in configure.args can be more simply accomplished by setting configure.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:

Error: Cannot install octopus for the arch(s) 'i386 x86_64' because
Error: its dependency libxc does not build for the required arch(s) by default
Error: and does not have a universal variant.

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.

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 Changed 11 years ago by dstrubbe (David Strubbe)

This release is now live. This should fix the livecheck and checksum issues.

comment:4 in reply to:  3 ; 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 of build.cmd, which defaults to “make”, so you can leave that out if you haven’t changed build.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 a pre-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 in reply to:  4 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 a pre-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: newclosed

LGTM, commited in r107233. Thank you for your work.

Note: See TracTickets for help on using tickets.