[petsc-dev] superlu_dist: update to version v5.4.0

[Jed Brown]

Packaging systems disallow this -- every installed file must have a
unique owner.  This is needed for reproducibility and to support clean
uninstalls -- packaging systems aren't likely to implement reference
counting on identical files just to support SuperLU.  This means every
packager needs to choose a way to circumvent this collision.  Why not
just use separate namespaces so there are no collisions?

"Xiaoye S. Li" <xsli at lbl.gov> writes:

> The include file superlu_enum_consts.h is identical in serial superlu and
> superlu_dist.  It hasn't had problem of configuring & using both packages
> at the same time.
>
> Sherry
>
> On Wed, Jun 13, 2018 at 6:02 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>
>> On Wed, 13 Jun 2018, Paul T. Bauman wrote:
>>
>> > On Wed, Jun 13, 2018 at 9:57 AM Smith, Barry F. <bsmith at mcs.anl.gov>
>> wrote:
>> >
>> > >
>> > >
>> > > > On Jun 12, 2018, at 9:36 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>> > > >
>> > > > Sure - that will work.
>> > > >
>> > > > But ultimately - if superlu and superlu_dist are separate packages
>> > > > (and meant to be used from the same applicaton)- they should not have
>> > > > any include files - that are common.
>> > > >
>> > > > If they have common files - then there should be some version check
>> > > > that prevent the wrong version of the common file from used.
>> > > >
>> > > > Or perhaps some other better organizaton of files between the
>> packages
>> > > > is possible.
>> > > >
>> > > > Alternative is - PETSc configure should eror out if one tries to use
>> > > > both packages at the same time.
>> > >
>> > >    We don't like this at all. Applications should be able to switch
>> > > between packages at runtime not require reconfiguring and rebuild etc.
>> > >
>> >
>> > Not meaning to butt-in, but I wanted to reenforce this point from the
>> user
>> > perspective because we do this *all the time* (superlu in serial, then
>> > superlu_dist in parallel) and would be very frustrating if it went away.
>>
>> Sorry - didn't mean to imply that this was a good choice. I was
>> enumerating various ways of looking at the superlu with superlu_dist
>> relation [wrt sharing common include files that one package can
>> overwrite the copy of the file from the other one]
>>
>> Satish
>>