[petsc-dev] I just removed Fortran support from my development build

[Smith, Barry F.]

  Jed,

  Why are the modules always built last? 

         .....
         FC arch-basic/obj/sys/objects/f2003-src/fsrc/optionenum.o
          FC arch-basic/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o
          FC arch-basic/obj/mat/f90-mod/petscmatmod.o
          FC arch-basic/obj/dm/f90-mod/petscdmmod.o
          FC arch-basic/obj/dm/f90-mod/petscdmplexmod.o
          FC arch-basic/obj/ksp/f90-mod/petsckspmod.o
          FC arch-basic/obj/snes/f90-mod/petscsnesmod.o
          FC arch-basic/obj/ts/f90-mod/petsctsmod.o
          FC arch-basic/obj/tao/f90-mod/petsctaomod.o

I don't think they have any dependency on the compiled C code so couldn't each module (still build sequentially within the list of modules) run in parallel with a bunch of C compilers? Why are they always scheduled last, forcing sequential?

   Barry


> On Oct 22, 2018, at 11:00 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Balay, Satish" <balay at mcs.anl.gov> writes:
> 
>> Currently fortran modules are built sequentially [due to dependencies]
>> 
>> Perhaps there is a way to split them up - and introduce some parallelism..
> 
> I think we would have to follow a pattern similar to the petsc*types.h
> headers where we would have a module that only defines types (needed by
> higher level PETSc packages) and a separate module that uses the types
> module and provides all the interfaces.  There would still be
> dependencies between the types modules, but not between the interfaces
> (because the Fortran interface modules don't call other interfaces).
> 
> For incremental builds when using ccache, rebuilding the modules can
> easily dominate execution time.