Opened 10 years ago

Closed 10 years ago

#46929 closed defect (invalid)

octopus: add mpi.enforce_variant fftw-3

Reported by: tenomoto (Takeshi Enomoto) Owned by: dstrubbe (David Strubbe)
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: haspatch Cc: dstrubbe (David Strubbe)
Port: octopus

Description

The build of octopus on buildbots failed because vanilla fftw-3 are built but octopus requires fftw-3 with a fortran variant, which can be forced with

mpi.enforce_variant fftw-3

mpi.enforce_variant are used a few places in Portfile. Why not add another?

Attachments (1)

patch-Portfile.diff (471 bytes) - added by tenomoto (Takeshi Enomoto) 10 years ago.

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by tenomoto (Takeshi Enomoto)

Attachment: patch-Portfile.diff added

comment:1 Changed 10 years ago by dstrubbe (David Strubbe)

Hello Takeshi,

This would not solve the problem unfortunately. You can see in the log that we are already checking whether fftw-3 has a Fortran variant:

Error: Install fftw-3 with a Fortran variant.
Error: org.macports.fetch for port octopus returned: fftw-3 not installed with a Fortran variant.

The problem is, that is not a default variant, and so the buildbot does not have fftw-3 installed with a Fortran variant when building octopus. mpi.enforce_variant would not do this either. Moreover, it is too restrictive, in that we do not need the same Fortran compiler as octopus, just some Fortran variant. Ideas on how to fix this situation are certainly welcome.

comment:2 in reply to:  1 Changed 10 years ago by seanfarley (Sean Farley)

Replying to dstrubbe@…:

The problem is, that is not a default variant, and so the buildbot does not have fftw-3 installed with a Fortran variant when building octopus. mpi.enforce_variant would not do this either.

Yes, this is because we can't depend on a variant in MacPorts.

Moreover, it is too restrictive, in that we do not need the same Fortran compiler as octopus, just some Fortran variant. Ideas on how to fix this situation are certainly welcome.

This is something @dstrubbe has brought up before but I am very much against it. MacPorts has trouble enough as it is to enforce mpi and other compiler libraries, much less depending on variants (which is impossible currently). Ensuring that we use the same fortran compiler is the only way to make ports *reliable* and *reproducible*. Furthermore, @dstrubbe has yet to bring up a valid reason for needing a different fortran compiler. In the past, I have wanted something similar (gfortran as a standalone port) but it is damn near impossible to have this without so much work. It is easier and safer to just ensure the same compilers here.

comment:3 Changed 10 years ago by tenomoto (Takeshi Enomoto)

How about creating fftw-3-fortran subport?

comment:4 in reply to:  3 Changed 10 years ago by seanfarley (Sean Farley)

Replying to takeshi@…:

How about creating fftw-3-fortran subport?

Where would it end? atlas-fortran? fftw-3-fortran-mpich? petsc-fortran? petsc-fortran-mpich? py-numpy-atlas-fortran? dolfin-fortran?

The MacPorts system just isn't designed for fortran nor mpi.

comment:5 Changed 10 years ago by dstrubbe (David Strubbe)

Resolution: invalid
Status: newclosed

Thanks for your comments. I think we are in agreement that the proposal would not solve the problem, so I am closing this ticket.

Note: See TracTickets for help on using tickets.