On Wed, 22 Aug 2018, Jed Brown wrote: > Matthew Knepley <knep...@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. >