October 2018 - petsc-dev - mailman3.cels.anl.gov

Python 3 support in configure
by Jed Brown 22 Oct '18

22 Oct '18

Configure now supports Python 3.4+ in addition to the prior Python 2.6+ support. If you are working on configure, please test with Python 3. For example, observe that print is a function and map() returns a map object so you'll need to use [f(x) for x in xs] or list(map(f, xs)) if you require a list. Please let us know of any issues you may encounter.

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Jed Brown 22 Oct '18

22 Oct '18

"Balay, Satish" <balay(a)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.

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Balay, Satish 22 Oct '18

22 Oct '18

Currently fortran modules are built sequentially [due to dependencies] Perhaps there is a way to split them up - and introduce some parallelism.. Satish On Mon, 22 Oct 2018, Matthew Knepley wrote: > Jenkins will now catch bad Fortran bindings. However, this is a larger > problem. GFortran takes forever to build the bindings. Is it similar for > other compilers? > > Matt > >

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Matthew Knepley 22 Oct '18

22 Oct '18

On Mon, Oct 22, 2018 at 10:58 AM Dener, Alp <adener(a)anl.gov> wrote: > > > On Oct 22, 2018, at 8:18 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > Jenkins will now catch bad Fortran bindings. However, this is a larger > problem. GFortran takes forever to build the bindings. Is it similar for > other compilers? > > > On my MacBook, the Homebrew GFortran 8.2.0 takes 5-8 seconds on `make > allfortranstubs`, and ~30 seconds on Fortran modules during `make`. The > full compile finishes in about 3.5 minutes total. Doesn’t seem like a very > long time to me, but then again I also have a very barebones configuration > with only MPI and blas/lapack. > 1) You have to compare the modules to the rest of the build, since I am rebuilding very frequently. 2) I am on the Mac Air, so it takes longer. Matt > Matt > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ > <http://www.cse.buffalo.edu/~knepley/> > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Dener, Alp 22 Oct '18

22 Oct '18

On Oct 22, 2018, at 8:18 AM, Matthew Knepley <knepley(a)gmail.com<mailto:[email protected]>> wrote: Jenkins will now catch bad Fortran bindings. However, this is a larger problem. GFortran takes forever to build the bindings. Is it similar for other compilers? On my MacBook, the Homebrew GFortran 8.2.0 takes 5-8 seconds on `make allfortranstubs`, and ~30 seconds on Fortran modules during `make`. The full compile finishes in about 3.5 minutes total. Doesn’t seem like a very long time to me, but then again I also have a very barebones configuration with only MPI and blas/lapack. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] I just removed Fortran support from my development build
by Jose E. Roman 22 Oct '18

22 Oct '18

In my experience, ifort is much faster than gfortran building the Fortran bindings. Jose > El 22 oct 2018, a las 15:18, Matthew Knepley <knepley(a)gmail.com> escribió: > > Jenkins will now catch bad Fortran bindings. However, this is a larger problem. GFortran takes forever to build the bindings. Is it similar for other compilers? > > Matt > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/

1 0

Re: [petsc-dev] Fortran interface problem in v.3.10.2
by Martin Diehl 22 Oct '18

22 Oct '18

On Sat, 2018-10-20 at 17:51 +0000, Smith, Barry F. wrote: > > On Oct 20, 2018, at 12:43 PM, Martin Diehl <m.diehl(a)mpie.de> wrote: > > > > From: "Smith, Barry F." <bsmith(a)mcs.anl.gov> > > To: Martin Diehl <m.diehl(a)mpie.de> > > Cc: Adrian Croucher <a.croucher(a)auckland.ac.nz>, For users of the > > development version of PETSc <petsc-dev(a)mcs.anl.gov> > > Sent: 10/20/2018 6:22 PM > > Subject: Re: [petsc-dev] Fortran interface problem in v.3.10.2 > > > > > > > > > On Oct 20, 2018, at 6:13 AM, Martin Diehl <m.diehl(a)mpie.de> > > > wrote: > > > > > > Barry, Adrian, > > > > > > I looked into this and found the following on type(*) from IBM > > > > > > https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.l… > > > > > > > > > To summarize, type(*) is exactly meant for C interfaces with > > > void* > > > dummy arguments (sorry for the Fortran speak, I don't know if > > > dummy > > > argument is a term common in C programming). > > > > > > The last statement is > > > "An assumed-type dummy argument cannot correspond to an actual > > > argument > > > of a derived type that has type parameters, type-bound > > > procedures, or > > > final subroutines." > > > which seems to be the reason why the code does not compile. > > > > I am now concerned that our use of type(*) in PETSc Fortran > > interfaces is just wrong and I see no good solution except to not > > have interface definitions for any Fortran stub routines that have > > void *arguments. > > To my understanding, it is fine. type(*) was meant for interfacing > > *void and that's what you use it for. However, it imposes some > > restrictions on the actual argument. For that reason, Intel Fortran > > does not compile the example code, with or without explicit > > interface. GNU fortran compiles the code without interface, > > presumably because it cannot detect that the code is not standard > > conforming. > > I'm sorry, I don't understand. Are you saying that the example > code is not correct Fortran? In the case that your interface has a type(*) argument, it is not valid Fortran because 'context_type' contains the type-bound procedure 'context_init'. That is why the GNU compiler complains when the interface exists. Apparently, without the interface it accepts it, so not having an interface would be a solution in that case. However, the Intel compiler will fail during linking with or without interface, so it does not seem to be a general solution. At the moment, I believe that one simply has to live with the limitations that type(*) imposes on the data that can be passed to void*. To clarify this, I opened a thread in the Intel developer zone and will keep you updated https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-an… > > > > I propose to further clarify the situation I'll present the problem > > at the Intel Developer Zone forum. > > > > > > > > > > > Then, I tried the following things: > > > > > > 1) Compiling your code with the current PETSc master and gfortran > > > 8.2 > > > to check whether this issue has been fixed by the GCC > > > developers. > > > > > > It still gives the same error > > > > > > > > > 2) Compiling your code with the Intel Fortran compiler (18.0.1) > > > an the > > > current PETSc master. > > > > > > It gives a very cryptic error > > > /usr/bin/x86_64-linux-gnu-ld: test_snes.o: undefined reference > > > to > > > symbol 'for_set_reentrancy' > > > /opt/intel/compilers_and_libraries_2018/linux/lib/intel64/libifco > > > remt.s > > > o.5: error adding symbols: DSO missing from command line > > > See also https://software.intel.com/en-us/node/679295 > > > > > > > > > 3) Compiling your code with the Intel Fortran compiler and either > > > PETSc > > > 3.10.0 or the PETSc master without the Fortran interface for > > > SNESsetConvergenceTest > > > > > > It still gives the same error as for 2) > > > > > > > > > Do you have access to any other compilers to check whether they > > > can > > > compile your application/test_example? > > > > > > best regards > > > Martin > > > > > > > > > > > > > > > On Fri, 2018-10-19 at 19:52 +0000, Smith, Barry F. wrote: > > > > > > > > Adrian, > > > > > > > > I goggled a bit but couldn't understand anything I found. My > > > > guess > > > > is that > > > > > > > > type(*) > > > > > > > > doesn't work for certain derived types (why not?) perhaps those > > > > that > > > > contain procedures. If I remove the procedure from the > > > > routine it all compiles, thus producing some evidence my theory > > > > is > > > > correct. > > > > > > > > So we have a problem. The type checking one user wants is > > > > causing > > > > another users code to not build. > > > > > > > > Here is a short term fix you can do. After you run > > > > ./configure > > > > edit $PETSC_ARCH/include/petscconf.h locate > > > > > > > > #ifndef PETSC_HAVE_FORTRAN_TYPE_STAR > > > > #define PETSC_HAVE_FORTRAN_TYPE_STAR 1 > > > > #endif > > > > > > > > then run make. This will turn off the type checking for all > > > > routines > > > > that have type(*) arguments which includes > > > > SNESSetConvergenceTest > > > > > > > > I don't have a good long term solution at the moment. Maybe a > > > > Fortran expert has some idea. > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Oct 18, 2018, at 10:14 PM, Adrian Croucher < > > > > > > > > a.croucher(a)auckland.ac.nz> wrote: > > > > > > > > > > hi Barry, > > > > > > > > > > On 18/10/18 11:34 AM, Smith, Barry F. wrote: > > > > > > Sorry about this problem. I think the change was only > > > > > > > > introduced in master and should not affect 3.10.x Please > > > > confirm that > > > > master is where the failed compile is? > > > > > > > > > > Yes, it's on master. I have tracked down the commit at which > > > > > it > > > > > > > > started to fail: 6f222c9d1e, "type checking for Fortran" (Fri > > > > Sep > > > > 28). > > > > > > > > > > > Please send us the calling sequence of your routine that > > > > > > won't > > > > > > > > compile (cut and paste). > > > > > > > > > > I've attached a minimal example program which fails with the > > > > > > > > following error: > > > > > > > > > > call SNESSetConvergenceTest(snes, convergence, context, & > > > > > 1 > > > > > Error: Actual argument at (1) to assumed-type dummy is of > > > > > derived > > > > > > > > type with type-bound or FINAL procedures > > > > > > > > > > Cheers, Adrian > > > > > > > > > > > > On Oct 17, 2018, at 5:21 PM, Adrian Croucher < > > > > > > > > a.croucher(a)auckland.ac.nz> wrote: > > > > > > > > > > > > > > hi > > > > > > > > > > > > > > A colleague has just reported that my code no longer > > > > > > > builds with > > > > > > > > PETSc 3.10.2, though it builds OK with 3.10.1. > > > > > > > > > > > > > > The problem appears to be the Fortran interface to > > > > > > > > SNESSetConvergenceTest(), which was changed at commit f9a1a4d. > > > > > > > > > > > > > > It now complains about the context argument we are > > > > > > > passing in to > > > > > > > > this function ('cctx' in the interface, which is declared there > > > > as > > > > type(*)). The error is: > > > > > > > > > > > > > > "Error: Actual argument at (1) to assumed-type dummy is > > > > > > > of > > > > > > > > derived type with type-bound or FINAL procedures" > > > > > > > > > > > > > > This is true, the argument being passed in is of derived > > > > > > > type > > > > > > > > with type-bound procedures. Previously this didn't bother it, > > > > but it > > > > looks like it does now. > > > > > > > > > > > > > > Is its complaint legitimate? or perhaps a compiler bug? > > > > > > > (this is > > > > > > > > using gcc 6.3.0) > > > > > > > > > > > > > > - Adrian > > > > > > > > > > > > > > > > > -- > > > > > Dr Adrian Croucher > > > > > Senior Research Fellow > > > > > Department of Engineering Science > > > > > University of Auckland, New Zealand > > > > > email: a.croucher(a)auckland.ac.nz > > > > > tel: +64 (0)9 923 4611 > > > > > > > > > > <test_snes.F90> > > > > > > -- > > > ----------------------------------------------- > > > Max-Planck-Institut für Eisenforschung GmbH > > > Max-Planck-Straße 1 > > > D-40237 Düsseldorf > > > > > > Handelsregister B 2533 > > > Amtsgericht Düsseldorf > > > > > > Geschäftsführung > > > Prof. Dr. Gerhard Dehm > > > Prof. Dr. Jörg Neugebauer > > > Prof. Dr. Dierk Raabe > > > Dr. Kai de Weldige > > > > > > Ust.-Id.-Nr.: DE 11 93 58 514 > > > Steuernummer: 105 5891 1000 > > > ------------------------------------------------- > > > Please consider that invitations and e-mails of our institute > > > are > > > only valid if they end with …(a)mpie.de. > > > If you are not sure of the validity please contact rco(a)mpie.de > > > > > > Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E- > > > Mails > > > aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. > > > In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de > > > > > > > > > > > > ------------------------------------------------- > > > Max-Planck-Institut für Eisenforschung GmbH > > > Max-Planck-Straße 1 > > > D-40237 Düsseldorf > > > > > > Handelsregister B 2533 > > > Amtsgericht Düsseldorf > > > > > > Geschäftsführung > > > Prof. Dr. Gerhard Dehm > > > Prof. Dr. Jörg Neugebauer > > > Prof. Dr. Dierk Raabe > > > Dr. Kai de Weldige > > > > > > Ust.-Id.-Nr.: DE 11 93 58 514 > > > Steuernummer: 105 5891 1000 > > > > > > > > > Please consider that invitations and e-mails of our institute > > > are > > > only valid if they end with …(a)mpie.de. > > > If you are not sure of the validity please contact rco(a)mpie.de > > > > > > Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E- > > > Mails > > > aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. > > > In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de > > > ------------------------------------------------- > > > > > > > > ------------------------------------------------- > > Max-Planck-Institut für Eisenforschung GmbH > > Max-Planck-Straße 1 > > D-40237 Düsseldorf > > > > Handelsregister B 2533 > > Amtsgericht Düsseldorf > > > > Geschäftsführung > > Prof. Dr. Gerhard Dehm > > Prof. Dr. Jörg Neugebauer > > Prof. Dr. Dierk Raabe > > Dr. Kai de Weldige > > > > Ust.-Id.-Nr.: DE 11 93 58 514 > > Steuernummer: 105 5891 1000 > > > > > > Please consider that invitations and e-mails of our institute are > > only valid if they end with …(a)mpie.de. > > If you are not sure of the validity please contact rco(a)mpie.de > > > > Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails > > aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. > > In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de > > ------------------------------------------------- > > -- ----------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 ------------------------------------------------- Please consider that invitations and e-mails of our institute are only valid if they end with …(a)mpie.de. If you are not sure of the validity please contact rco(a)mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de ------------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 Please consider that invitations and e-mails of our institute are only valid if they end with …(a)mpie.de. If you are not sure of the validity please contact rco(a)mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de -------------------------------------------------

1 0

I just removed Fortran support from my development build
by Matthew Knepley 22 Oct '18

22 Oct '18

Jenkins will now catch bad Fortran bindings. However, this is a larger problem. GFortran takes forever to build the bindings. Is it similar for other compilers? Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] --download and spack
by Balay, Satish 21 Oct '18

21 Oct '18

On Sun, 21 Oct 2018, Jed Brown wrote: > "Balay, Satish" <balay(a)mcs.anl.gov> writes: > > > On Sun, 21 Oct 2018, Jed Brown wrote: > > > >> "Balay, Satish" <balay(a)mcs.anl.gov> writes: > >> > >> > On Sun, 21 Oct 2018, Jed Brown wrote: > >> > > >> >> "Balay, Satish" <balay(a)mcs.anl.gov> writes: > >> >> > >> >> > I don't think spack is really a replacemet for --download-package yet. > >> >> > > >> >> > For one - it has some initial setup hump users have to go over. [how > >> >> > does one specify compilers, and my prebuilt MPI?] > >> >> > >> >> The configuration profile is somewhat clumsy, but lots of facilities do > >> >> it. If PETSc were to support using spack for prerequisites, we would > >> >> probably want PETSc to be able to set it up. > >> >> > >> >> > And then - we would need to update petsc support in spack to be as > >> >> > externsive wrt externalpackages as we currently have. > >> >> > >> >> There are separate ideas: > >> >> > >> >> * ./configure --download-hypre=spack > >> >> > >> >> or some similar syntax tells configure to ask Spack how to link to a > >> >> suitably-built Hypre and to install it if necessary, resolving any > >> >> possible transitive dependencies [1]. > >> > > >> > I don't think spack is designed to support this model [just install > >> > one package or a subset of pacakges - per our spec]. For one - it > >> > doesn't have a configure like interface to pass options from petsc > >> > configure to spack [for all the checks that petsc configure has > >> > already done. > >> > > >> >> > >> >> * spack install petsc+hypre > >> >> > >> >> as a recommended way for users to install. An issue with this is that > >> >> Spack code runs before anything PETSc works with, and Spack setup > >> >> (system compilers, MPI, etc.) can be nontrivial. > >> > > >> > This is the recommended mode. And I think its useful for users who don't > >> > want to deal with petsc directly or petsc interface directly. > >> > > >> > [for ex: deal.ii users - who want to install deal.ii - but just want a > >> > compatible petsc installed automatically]. > >> > >> This is *exactly* the same model as you rejected a paragraph above. > >> There is no difference whether we are talking about installing > >> dependencies for PETSc or dependencies for Deal.II. > > > > Not really. My initial claim was 'spack was not yet a replacement for > > --download-package' option in PETSc. I don't think deal has this > > feature. > > Okay, fair enough. But if it's usable for installing dependencies > needed by a typical deal.II user, it should also be usable for > installing PETSc's dependencies. > > >> Also, I think most users don't care whether exactly the same compiler > >> options are passed to all dependent packages. They want to link against > >> a working debug or optimized stack with minimal build time. > >> > >> >> [1] Having configure churn for a while and then say that --download-zlib > >> >> or --enable-zlib is required is super lame. > >> > > >> > spack automatically figures out and installs tonnes of additional packages. The > >> > above model gives the choice of user deciding what to do. In case of p4est - it could > >> > be an optionl dependency instead of mandatory dependency. > >> > > >> > I guess optional dependency handling is a bit complex. > >> > >> It is, but if we're downloading a bunch of packages and zlib is deemed > >> required, we shouldn't fail. It's these minutes of babysitting > >> configure and needing to start over to add non-obvious dependencies that > >> is infuriating and drives people away from PETSc and/or blocks them from > >> running their code at new facilities. (It's a completely different > >> calculus if I know I can log in, issue a couple simple commands, and be > >> running in 5-10 minutes versus if I expect to need to babysit and > >> troubleshoot configuration idiosyncrasies for hours.) > > > > In my case - I have spack running for 4-6h - and then I get an error - > > and then I have to figureout how to work arround them - and restart > > builds. Different tools have different error cases.. > > I agree it can be irritating, though Spack is reasonably reliable about > caching previous builds so it usually isn't starting over from scratch > after fixing any particular issue. If certain dependencies change [due to my choice of workarrounds] - it builds another copy of all packages that are affected. > And I didn't mean that the zlib thing on its own is a reason to use > Spack, but that PETSc configure should either return immediately (<5 > seconds) if the dependency graph is incomplete and/or try to do what the > user surely wants and find a zlib. Sure - perhaps there are improvements possible for both the tools.. Satish

1 0

Re: [petsc-dev] --download and spack
by Jed Brown 21 Oct '18

21 Oct '18

"Balay, Satish" <balay(a)mcs.anl.gov> writes: > On Sun, 21 Oct 2018, Jed Brown wrote: > >> "Balay, Satish" <balay(a)mcs.anl.gov> writes: >> >> > On Sun, 21 Oct 2018, Jed Brown wrote: >> > >> >> "Balay, Satish" <balay(a)mcs.anl.gov> writes: >> >> >> >> > I don't think spack is really a replacemet for --download-package yet. >> >> > >> >> > For one - it has some initial setup hump users have to go over. [how >> >> > does one specify compilers, and my prebuilt MPI?] >> >> >> >> The configuration profile is somewhat clumsy, but lots of facilities do >> >> it. If PETSc were to support using spack for prerequisites, we would >> >> probably want PETSc to be able to set it up. >> >> >> >> > And then - we would need to update petsc support in spack to be as >> >> > externsive wrt externalpackages as we currently have. >> >> >> >> There are separate ideas: >> >> >> >> * ./configure --download-hypre=spack >> >> >> >> or some similar syntax tells configure to ask Spack how to link to a >> >> suitably-built Hypre and to install it if necessary, resolving any >> >> possible transitive dependencies [1]. >> > >> > I don't think spack is designed to support this model [just install >> > one package or a subset of pacakges - per our spec]. For one - it >> > doesn't have a configure like interface to pass options from petsc >> > configure to spack [for all the checks that petsc configure has >> > already done. >> > >> >> >> >> * spack install petsc+hypre >> >> >> >> as a recommended way for users to install. An issue with this is that >> >> Spack code runs before anything PETSc works with, and Spack setup >> >> (system compilers, MPI, etc.) can be nontrivial. >> > >> > This is the recommended mode. And I think its useful for users who don't >> > want to deal with petsc directly or petsc interface directly. >> > >> > [for ex: deal.ii users - who want to install deal.ii - but just want a >> > compatible petsc installed automatically]. >> >> This is *exactly* the same model as you rejected a paragraph above. >> There is no difference whether we are talking about installing >> dependencies for PETSc or dependencies for Deal.II. > > Not really. My initial claim was 'spack was not yet a replacement for > --download-package' option in PETSc. I don't think deal has this > feature. Okay, fair enough. But if it's usable for installing dependencies needed by a typical deal.II user, it should also be usable for installing PETSc's dependencies. >> Also, I think most users don't care whether exactly the same compiler >> options are passed to all dependent packages. They want to link against >> a working debug or optimized stack with minimal build time. >> >> >> [1] Having configure churn for a while and then say that --download-zlib >> >> or --enable-zlib is required is super lame. >> > >> > spack automatically figures out and installs tonnes of additional packages. The >> > above model gives the choice of user deciding what to do. In case of p4est - it could >> > be an optionl dependency instead of mandatory dependency. >> > >> > I guess optional dependency handling is a bit complex. >> >> It is, but if we're downloading a bunch of packages and zlib is deemed >> required, we shouldn't fail. It's these minutes of babysitting >> configure and needing to start over to add non-obvious dependencies that >> is infuriating and drives people away from PETSc and/or blocks them from >> running their code at new facilities. (It's a completely different >> calculus if I know I can log in, issue a couple simple commands, and be >> running in 5-10 minutes versus if I expect to need to babysit and >> troubleshoot configuration idiosyncrasies for hours.) > > In my case - I have spack running for 4-6h - and then I get an error - > and then I have to figureout how to work arround them - and restart > builds. Different tools have different error cases.. I agree it can be irritating, though Spack is reasonably reliable about caching previous builds so it usually isn't starting over from scratch after fixing any particular issue. And I didn't mean that the zlib thing on its own is a reason to use Spack, but that PETSc configure should either return immediately (<5 seconds) if the dependency graph is incomplete and/or try to do what the user surely wants and find a zlib.

1 0