Even petscdiff should not be installed in the bin location, it should be 
moved to a more appropriate place for the test suite.

   Frankly the brew folks are right, we are nuts to install all this crap in 
the prefix/bin location. I don't think we need to/should install anything in 
prefix/bin


  Barry


> On Feb 23, 2018, at 2:36 PM, Balay, Satish <ba...@mcs.anl.gov> wrote:
> 
> $ ls |cat
> adiforfix.py*
> configVars.py*
> FASTMathInstaller.py*
> maint/
> parseargs.py*
> PetscBinaryIO.py*
> PetscBinaryIO_tests.py*
> PetscBinaryIOTrajectory.py*
> petsc_conf.py*
> petscdiff*
> petsc_gen_xdmf.py*
> petsclogformat.py*
> petscmpiexec*
> petsc-mpiexec.uni*
> petscnagupgrade.py*
> petscnagupgrade.pyc
> petscrun*
> popup*
> portabilitycheck.py*
> saws/
> sendToJenkins*
> taucc.py*
> TOPSGenerator.py*
> uncrustify.cfg
> update.py*
> win32fe/
> 
> 
> 
> I guess most of them are not needed - and whats needed can perhaps be somehow 
> trimmed.
> 
> The new testsuite tries to use 'petscdiff' above.
> 
> And old makefiles try to use 'petscnagupgrade.py' - which is not appropriate 
> for distributions anyway [but requires a patch to disable]
> 
> Satish
> 
> On Fri, 23 Feb 2018, Smith, Barry F. wrote:
> 
>> 
>>  Jed,
>> 
>>    I am getting into this thread a little late. What is, exactly, what we 
>> need to change with ./configure ; make ; make install to make the PETSc 
>> "upstream installation" not a mess?  Are we simply over installing stuff? 
>> (This could be). Is it the optional dependency handling? 
>> 
>>   In bin we have 
>> 
>>      petsc_gen_xdmf.py,      PetscBinaryIO.py        
>> PetscBinaryIOTrajectory.py that probably belong elsewhere. 
>> 
>>   You should feel free to make branches that move this kind of stuff to more 
>> appropriate places and stop installing unneeded crap, but you can't expect 
>> someone else on the PETSc team to magically fix misinstalls and you need to 
>> be proactive as well.
>> 
>>   Barry
>> 
>>   It is important to follow "standards" when possible even if they are a bit 
>> annoying so long as they don't totally ruin the user experience. Our current 
>> install is not written in stone and can be adjusted to make package people 
>> happy if possible.
>> 
>> 
>> 
>> 
>> 
>>> On Feb 23, 2018, at 2:19 PM, Jed Brown <j...@jedbrown.org> wrote:
>>> 
>>> What, if anything, really needs to be installed to $prefix/bin?
>>> 
>>> From the Homebrew lead maintainer.
>>> 
>>> 
>>> From: Mike McQuaid <notificati...@github.com>
>>> Subject: Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science 
>>> (#23598)
>>> Date: February 23, 2018 at 1:59:53 PM CST
>>> To: Homebrew/homebrew-core <homebrew-c...@noreply.github.com>
>>> Cc: Jed Brown <j...@jedbrown.org>, Mention <ment...@noreply.github.com>
>>> Reply-To: Homebrew/homebrew-core 
>>> <reply+00000ce7ce699f5d2e67cfb5b15ac92562f1255ca51ef0f992cf0000000116a834b992a169ce11832...@reply.github.com>
>>> 
>>> 
>>> doesn't this attitude complete defeat the purpose of a package manager?
>>> 
>>> You're asking of the hardest working package manager maintainers in the 
>>> world (@ilovezfs). Chances he has a better idea about the purpose of a 
>>> package manager than you do.
>>> 
>>> I cannot understand not wanting a package because it is complicated to 
>>> install.
>>> 
>>> This is perhaps because you do not maintain a package manager.
>>> 
>>> What you're suggesting is that any software using PETSc should either force 
>>> users to compile it from scratch or discontinue supporting macOS entirely.
>>> 
>>> No, what's being suggested is that PETSc's currently upstream installation 
>>> is a mess and we don't want to maintain the hacks required to make it not 
>>> one indefinitely. You can copy and paste this formula as-is into a tap and 
>>> it'll work for you just fine.
>>> 
>>> That seems like the wrong approach for a package manager.
>>> 
>>> In the package manager you maintain you should take a different approach, 
>>> then.
>>> 
>>> Just my opinion...
>>> 
>>> If you have to end your statement like that: it's probably worth keeping 
>>> quiet in future, please.
>>> 
>>> To be clear, I'm not being harsh here because I like doing so but because 
>>> this entitled, know-it-all attitude literally kills open source projects 
>>> and @ilovezfs's motivation is more important to me than allowing that to go 
>>> unchallenged.
>>> 
>>> —
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub, or mute the thread.
>>> 
>>> 
>>> 
>> 
>> 

Reply via email to