Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-05 Thread Barry Smith
> On Jan 5, 2021, at 5:30 PM, Satish Balay via petsc-dev > wrote: > > BTW: for CI - the following might grab most of the config logs as artifacts > [assuming they are either config.log or configure.log] - but yeah - all logs > won't be in the same location [or single file, and good to have

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-05 Thread Satish Balay via petsc-dev
BTW: for CI - the following might grab most of the config logs as artifacts [assuming they are either config.log or configure.log] - but yeah - all logs won't be in the same location [or single file, and good to have a fix that works for both users and CI] Satish diff --git a/.gitlab-ci.

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-05 Thread Satish Balay via petsc-dev
On Tue, 5 Jan 2021, Satish Balay via petsc-dev wrote: > On Tue, 5 Jan 2021, Barry Smith wrote: > > > > > > > > On Jan 5, 2021, at 8:28 AM, Satish Balay wrote: > > > > > > Well we have to look at artifacts for configure.log. Why is this more of > > > a burden for slepc or externalpackage logs

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-05 Thread Satish Balay via petsc-dev
On Tue, 5 Jan 2021, Barry Smith wrote: > > > > On Jan 5, 2021, at 8:28 AM, Satish Balay wrote: > > > > Well we have to look at artifacts for configure.log. Why is this more of a > > burden for slepc or externalpackage logs? > >Some of the "artifacts" don't even exist to look at as artifa

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-05 Thread Barry Smith
> On Jan 5, 2021, at 8:28 AM, Satish Balay wrote: > > Well we have to look at artifacts for configure.log. Why is this more of a > burden for slepc or externalpackage logs? Some of the "artifacts" don't even exist to look at as artifacts; for example slepc4py log files. And if we continu

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-05 Thread Satish Balay via petsc-dev
Well we have to look at artifacts for configure.log. Why is this more of a burden for slepc or externalpackage logs? Whatever you say for slepc log applies for configure.log. If its only CI issue - and you want all logs on STDOUT - then you can modify .gitlab-ci.yml. Perhaps: diff --git a/.g

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-04 Thread Jose E. Roman
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 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

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-04 Thread Barry Smith
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

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-04 Thread Pierre Jolivet
> On 5 Jan 2021, at 1:33 AM, Barry Smith 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

[petsc-dev] builds of PETSc based packages should not get their own secret files

2021-01-04 Thread Barry Smith
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