I have no problem on the installation page mentioning using spack to
install PETSc; but we shouldn't pretend that it is easy and will always work.
I fear if we just say
spack install petsc
we'll get emails that expect us to debug the person's set up of spack,
which we absolutely do not want to be in that game. For example my complaint to
Satish about zlib which was totally my own fault for having incorrectly setup
spack.
Barry
On Oct 21, 2018, at 4:55 PM, Jed Brown <j...@jedbrown.org> wrote:
>
> "Balay, Satish" <ba...@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].
>
> * 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.
>
>
>
> [1] Having configure churn for a while and then say that --download-zlib
> or --enable-zlib is required is super lame.
>
>> And if you want to build any branch of petsc from spack - it requires
>> additional configs to spack code [an entry for each petsc branch].
>>
>> One feature that petsc configure has - that spack does not yet have
>> (as far as I know) is 'self.dlib' - which I just used in p4est.py: [Ah
>> - I see a bug in my code - there should also be a corresponding usage
>> of 'self.dinclude'].
>
> It is broken encapsulation if this is required for includes or for
> linking with shared libraries. Pkg-config and similar systems have
> Libs.static for such transitive dependencies. Spack has this
> information. Are you saying it breaks when using static libraries?
>
> P4est is actively maintained and should be fixed if it at fault in this
> instance.
>
>> And then there is the compiler library detection issue. [ideally spack
>> should detect this and pass it down to all packages]. Curently some
>> packages have hacks for this.
>>
>> var/spack/repos/builtin/packages/zoltan/package.py:
>> config_args.append('--with-libs=-lgfortran')
>> var/spack/repos/builtin/packages/mfem/package.py: libs +=
>> LibraryList(find_system_libraries('libdl'))
>>
>> etc..
>
> Have these been reported in the Spack issue tracker?
