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 <[email protected]> wrote: > > > >> On 5 Jan 2021, at 1:33 AM, Barry Smith <[email protected] >> <mailto:[email protected]>> 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 > <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
