[petsc-dev] Undefined symbols for _kspfgmresmodifypcksp_ and _kspfgmresmodifypcnochange_ when rebuilding

[Satish Balay]

On Wed, 22 Aug 2018, Jed Brown wrote:

> Matthew Knepley <knepley at gmail.com> writes:
> 
> > Someone changes an interface, and you pull the change. The header changes
> > will cause all the C files
> > using that API to rebuild. However, the doc system (sowing) runs bfort on
> > the C file to generate the Fortran
> > binding. It runs on all headers at once, so there is no separately rule for
> > bforting a C file when it changes.
> > Things are now even worse, since we have Python code separate from bfort
> > which create the Fortran
> > modules, which also will not fire on updates to the C file.
> >
> > The simplest fix is that you know that every time you see this problem, you
> > rerun 'make allfortranstubs'.
> > The complicate fix is to rewrite bfort and the module generation into one
> > program which respects the
> > dependency information. 
> 
> A simpler solution that is not a sledgehammer would be for these
> "generate everything" scripts write a temporary file, diff with the
> (possibly stale) existing output, and only replaces when the content is
> different.  We don't want to make allfortranstubs always because it
> implies that every ftn-auto file will be recompiled even if it hasn't
> changed.  That is faster with ccache, but still not fast enough (and
> implies re-linking everything).

Well the primary cost here is the compile of fortran modules - and
that also results in a relink

And I think these costs are unavoidable even with a trivial change in
fortran interface.

Satish

> 
> > Since there is literally no credit associated with this job, it is
> > unlikely ever to happen.  We await the passing of the last Fortran
> > programmer.
>