[petsc-users] petsc externalpackage directory

[Barry Smith]

> On Feb 2, 2016, at 11:18 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> On Tue, 2 Feb 2016, Barry Smith wrote:
> 
>> 
>>> On Feb 2, 2016, at 11:06 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>>> 
>>> On Tue, 2 Feb 2016, Jed Brown wrote:
>>> 
>>>> Satish Balay <balay at mcs.anl.gov> writes:
>>>> 
>>>>> On Tue, 2 Feb 2016, Jed Brown wrote:
>>>>> 
>>>>>> Satish Balay <balay at mcs.anl.gov> writes:
>>>>>> 
>>>>>>> Well my recommendation was for this use case of "same install on a different machine"
>>>>>> 
>>>>>> If you're installing to the same location on equivalently-configured
>>>>>> machines,
>>>>> 
>>>>> I presumed the copy is to a different machine - perhaps with different file system/organization.
>>>> 
>>>> Like different versions of compilers or different library versions?
>>>> Then the failure mode I mentioned is possible.
>>> 
>>> This has nothing to do with sources in PETSC_ARCH/externalpackages. They are equivalent to tarballs.
>>> 
>>> [stuff in PETSC_ARCH/include can conflict]
>>> 
>>>> 
>>>>>> And it breaks _constantly_.  It must be like 30% of petsc-maint traffic
>>>>>> in the past year; advice being "delete PETSC_ARCH and reconfigure".
>>>>> 
>>>>> All of these breakages are usually due to 2 different cases.
>>>>> - [as mentioned before] - due to 'git pull' changing dependencies
>>>>> - [without git pull or equivalent] conflict between switching from say
>>>>> --download-mpich to --download-openmpi - in install location
>>>>> [PETSC_ARCH/include] and not sources in PETSC_ARCH/externalpackages
>>>>> 
>>>>> I agree starting from tarballs is the recommended way - but this copy
>>>>> [of petsc+externalpackages together] will also work.
>>>> 
>>>> I said it was unreliable, not that it would necessarily fail.  I don't
>>>> think we can claim this is supported behavior without a way to ensure
>>>> clean build directories.
>>> 
>>> Each time configure is invoked with --download-package - it does a
>>> 'make clean' or equivalent in each of these packages/build dirs - and
>>> then rebuilds.
>> 
>>  Satish,
>> 
>>   Jed's point is most external packages (or at least some) do not properly implement make clean so you will often be dragging along a bunch of already generated (and likely wrong) files. You could say, "well that is not our fault, but it can still cause problems so the fact that is not our fault is not relevant."
>> 
> 
> My point here is - we haven't have problems with it. [if we had - then you would be doing 'rm -rf PETSC_ARCH' 20 times every day..]

  But people who "think" machine 1 (outside the firewall) has the same configuration at machine 2 (inside the firewall) are almost always wrong!. The two machines will likely have different versions of all kinds of things that "may" cause the inappropriate already generated files to break something.

  Barry




> 
> Satish