Dear Barry, all, pls find my comments below.
On Thu, 2024-03-21 at 13:19 -0400, Barry Smith wrote: > > Martin, > > Thanks for the suggestions and offer. > > The tool we use for automatically generating the Fortran stubs > and interfaces is bfort. > > Its limitations include that it cannot handle string arguments > automatically and cannot generate more than one interface for a > function. This is why we need to provide these manually (the use of > a,b,... is to prevent long lines and the need for continuations in > the definitions of the interfaces). This should be fixable: Either tell the compiler to accept long lines or introduce line breaks if needed. > > Adding support for strings is very straightforward, just a > little more smarts in bfort. perfect. If I remember correctly, a lot of interfaces that I contributed where needed because of strings. > > Adding support for multiple interface generation is a bit > trickier because the code must (based on the C calling sequence) > automatically determine all the combinations of array vs single value > the interfaces should generate and then generate a Fortran stub for > each (all mapping back to the same master stub for that function). > I've talked to Bill Gropp about having him add such support, but he > simply does not have time for such work so most recent work on the > bfort that PETSc uses has been by us. I don't have the time either, hence the idea to search for someone paid by google. > > We've always had some tension between adding new features to > bfort vs developing an entirely new tool (for example in Python > (maybe calling a little LLVM to help parse the C function), for maybe > there is already a tool out there) to replace bfort. Both approaches > have their advantages and disadvantages instead we've relied on the > quick and dirty of providing the interfaces as needed). We have not > needed the Fortran standard C interface stuff and I would prefer not > to use it unless it offers some huge advantage). both approaches (improving bfort or writing something new) are fine with me. Regarding the Fortran standard interfacing: Are your main concern the use of ISO_Fortran_binding.h on the C side? (see https://fortran-lang.discourse.group/t/examples-iso-c-binding-calling-fortran-from-c/4149/3 ). Other language features (like the '*' to indicate 'any type') on the Fortran side are already used as far as I know. > > Thoughts? > > Barry > > > > > > > > > On Mar 21, 2024, at 12:21 PM, Martin Diehl > > <[email protected]> wrote: > > > > Dear PETSc team, > > > > I've worked on Fortran interfaces (see > > https://gitlab.com/petsc/petsc/-/issues/1540) but could not get far > > in > > the time I could afford. > > > > In discussion with Javier (in CC) the idea came up to propose to > > offer > > the work on Fortran interfaces for PETSc as a Google Summer of Code > > project. > > > > fortran-lang has been accepted as organization and the current > > projects > > are on: > > https://github.com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas > > > > The main work would be the automatization of interfaces that are > > currently manually created via Python. This includes an improved > > user > > experience, because correct variable names (not a, b, c) can be > > used. > > It should be also possible to automatically create descriptions of > > the > > enumerators. > > > > As outlook tasks, I would propose: > > - check whether a unified automatization script can also replace > > the > > current tool for creation of interfaces. > > - investigate improved handling of strings (there are ways in newer > > standards). > > > > I can offer to do the supervision, but would certainly need > > guidance > > and the ok from the PETSc core team. > > > > best regards, > > Martin > > > > -- > > KU Leuven > > Department of Computer Science > > Department of Materials Engineering > > Celestijnenlaan 200a > > 3001 Leuven, Belgium > -- KU Leuven Department of Computer Science Department of Materials Engineering Celestijnenlaan 200a 3001 Leuven, Belgium
signature.asc
Description: This is a digitally signed message part
