$ 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. > > > > > > > >
