slepc4py source is not yet included in SLEPc source, but this will be done soon. Jose
> El 5 ene 2021, a las 8:30, Barry Smith <bsm...@petsc.dev> escribió: > > > Thanks. > > I'd like to move to also building the python bindings for both PETSc and > SLEPc by default in the future. Gives better testing and makes it easier for > users who shouldn't need to worry about adding obscure options to get the > python bindings built. Users should be able to turn off python bindings as > opposed to having to turn them on. > > Barry > > >> On Jan 5, 2021, at 1:05 AM, Pierre Jolivet <pie...@joliv.et> wrote: >> >> >> >>> On 5 Jan 2021, at 1:33 AM, Barry Smith <bsm...@petsc.dev> wrote: >>> >>> >>> For packages that are built after PETSc configure (and or install is done) >>> slepc, hpddm etc we've traditional saved the output in its own file >>> stashed away somewhere. >>> >>> For the CI this is driving me nuts because when they fail the output is >>> essentially "lost" and thus it is impossible to determine what has gone >>> wrong. >>> >>> I have started to directly output in the same stream as the PETSc compiles >>> to make debugging much easier. Generally the packages are relatively small >>> and don't have a huge amount of output when compiling correctly. I did it >>> for PETSc4py and SLEPc (slepc4py is a mystery yet how it get's hidden in >>> slepc). >> >> I guess we could change the redirect rule here >> https://gitlab.com/slepc/slepc/-/blob/master/config/packages/slepc4py.py#L53? >> But we’d need to check whether slepc4py is built with --download-slepc >> --download-slepc-configure-arguments="--download-slepc4py” (inside PETSc) or >> simply --download-slepc4py (inside SLEPc). >> >> I’m in favour of having a single file because it can be quite nightmarish to >> ask users for multiple .log files hidden in different folders, but I can >> understand if we stick with the current approach as well. >> >> Thanks, >> Pierre >> >>> Are there any large downsides to this plan? >>> >>> Barry >
