[petsc-dev] What needs to be done before a release?

[Jed Brown]

On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <bourdin at lsu.edu> wrote:

> Apologies, will do next time. That would also have helped me realize that
> I had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am
> attaching the patch I was planing on submitting.
>
> Out of curiosity, what is the rationale for not wanting an explicit
> interface? As far as I understand, the fortran standard mandates an
> explicit interface in this situation (array of strings). I would understand
> in the situation of pure f77 compatibility for instance, but we threw this
> away with the iso_c_binding module anyway...
>

Fortran modules are horribly nonportable from a build system perspective
since every compiler manages them differently. Having the interfaces
requires those extra interface files in the includes that we already hate
so much, and we can't protect the headers (to make including the right ones
simple like in C) because you have to include them for every subroutine.

I think it would be better [1] for the "modern" Fortran users for PETSc to
do everything with modules, using explicit interfaces for all functions,
and datatypes for PETSc objects. Unfortunately, that forces people to spell
out things like type(Mat) [2] and XGetContext() either requires an explicit
interface written by the user [3] or use of the ISO C bindings in the
interface [4].

I can think of no explanation for this absurdity other than that the
Fortran language standards committee is the most successful global trolling
agency in modern history [5].


> Perhaps introducing f2003 in petsc was a bad idea, considering the large
> variety of compilers you need to support. If you feel that it introduces
> more issues than solving problems, feel free to strip the PetscOptionsEnum
> and PetscBagRegisterEnum bindings. They could easily be packaged separately
> for the few people who will ever need them.
>

[1] Better, but it would be best for them to stop using Fortran.
[2] No #includes means no macros [6] and no equivalent of typedef.
[3] Disaster because (a) it is maintained by the user with no way to check
that it is correct and (b) the user may need multiple incompatible
definitions in the same project.
[4] Indeed, the best way to write a Fortran library called from Fortran is
to use the ISO C bindings.
[5] The people who dream up ways to link MKL and the Portland Group deserve
honorable mention.
[6] Type macros are terrible anyway because of the aforementioned punchcard
nostalgia leading to different projects adopting different line/format
styles and compilers having no portable way to select.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120601/995a3945/attachment.html>