[email protected] (Ludovic Courtès) writes: >> +(define-public libpetsc >> + (package >> + (name "libpetsc") > > I think this should be “petsc”, as it’s the upstream name and commonly > used AFAIK. WDYT?
I was originally thinking "petsc" but then discovered that the package name on many other distributions is "libpetsc". I would personally prefer "petsc". >> + ;; Try to keep installed files from leaking build directory paths. >> + ;; Fortran modules will have references to the build directory >> + ;; because cmake passes absolute path names to the compiler. > > Rather “directory names” and “absolute file names” (info "(standards) > GNU Manuals"). I'll fix that. > (This CMake story is terrible, BTW.) I think PETSc has an alternative build system. I'll check whether using that one would improve anything. >> +(define-public libpetsc-complex >> + (package (inherit libpetsc) >> + (name "libpetsc-complex") > > Likewise, “petsc-complex”? Yes. >> +++ b/gnu/packages/patches/petsc-fix-threadcomm.patch > > Please add a comment at the beginning of the patch saying what it does > and whether it’s available upstream. Will do. -- `~Eric
