Sure, but we could have our own petsc-centric tests triggered by gitlab CI also
> On Jun 10, 2019, at 4:51 PM, Balay, Satish <[email protected]> wrote: > > On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote: > >> >> >>> On Jun 10, 2019, at 4:33 PM, Balay, Satish <[email protected]> wrote: >>> >>> now configure needs to know and support full spack build and query all the >>> dependency info from spack.. >> >> We could have some test cases where PETSc is also built by spack, which >> presumably works and would also test petsc-spack > > this is xsdk test suite.. [right now it just does a build test - but have to > add example tests to spack] > > Satish >> >>> >>> For now - I'll try out a simpler model [i.e manually rebuild as needed] >> >> Not for long you don't, we have better things to do with your time. >> >>> >>> Satish >>> >>> On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote: >>> >>>> That seems ok. We could also overload --download-mpich=spack for anal >>>> people like me :-) >>>> >>>> Somehow we also need to let configure know where the spack configuration >>>> is. >>>> >>>>> On Jun 10, 2019, at 4:21 PM, Jed Brown <[email protected]> wrote: >>>>> >>>>> "Smith, Barry F." <[email protected]> writes: >>>>> >>>>>> Yes, spack could be used to do this. I guess essentially Buildsystem >>>>>> would issues commands to spack on each "prebuilt" package each time it >>>>>> runs in test mode (using the URL in the package file?) and after the >>>>>> first time spack would ignore the commands since it already had the >>>>>> version ready. I could use this on my machine also. >>>>>> >>>>>> Barry >>>>>> >>>>>> --spack-mpich etc ? >>>>> >>>>> Would --with-mpich=spack be confusing? >>>> >>> >> >
