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

[Balay, Satish]

I'm not sure if one can give priority to mod compilation in gmake - but I think the first module
is scheduled quickly - but then that takes some time to compile.

          CC arch-linux2-c-debug/obj/sys/objects/gcomm.o
Use "/usr/bin/gmake V=1" to see verbose compile lines, "/usr/bin/gmake V=0" to suppress.
          FC arch-linux2-c-debug/obj/sys/f90-mod/petscsysmod.o

But due to dependencies - I think the second one gets placed further back in the queue

          CC arch-linux2-c-debug/obj/vec/is/sf/interface/dlregissf.o
          FC arch-linux2-c-debug/obj/vec/f90-mod/petscvecmod.o

etc.. And by the time all sources without dependencies get compiled
[i.e all c code] - the module sources are left at the end of the build.

Satish

On Mon, 22 Oct 2018, Smith, Barry F. wrote:

> 
>   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.
>