[petsc-dev] provider stuff in package.py
Matthew Knepley
knepley at gmail.com
Tue Sep 30 16:58:58 CDT 2014
On Tue, Sep 30, 2014 at 4:40 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> This does not belong in package.py, where does it belong?
>
> def checkNoOptFlag(self):
> flag = '-O0'
> if self.setCompilers.checkCompilerFlag(flag): return flag
> return ''
>
> def getSharedFlag(self,cflags):
> for flag in ['-PIC', '-fPIC', '-KPIC', '-qpic']:
> if cflags.find(flag) >=0: return flag
> return ''
>
> def getPointerSizeFlag(self,cflags):
> for flag in ['-m32', '-m64', '-xarch=v9','-q64']:
> if cflags.find(flag) >=0: return flag
> return ''
>
> def getWindowsNonOptFlags(self,cflags):
> outflags = []
> for flag in cflags.split():
> if flag in ['-MT','-MTd','-MD','-MDd','-threads']:
> outflags.append(flag)
> return ' '.join(out flags)
>
> And having a Windows and Not Windows functions for Opt flags in the API
> is disgraceful.
These should not be anywhere:
1) The first check should just be in compilerOptions.py I think. Not sure
what it is for.
2) We already check for shared library flags, and I think they are
compilers.sharedLibraryFlags
3) I am not sure why we need a check for pointer size flags, but it should
be a test in types.py
if we do need it.
4) These should go with 1)
Matt
> Barry
>
>
> On Sep 30, 2014, at 4:09 PM, Matthew Knepley <knepley at gmail.com> wrote:
>
> > On Tue, Sep 30, 2014 at 4:00 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > Matt,
> >
> > Can all the “provider” stuff in package.py like
> >
> > def getDefaultPrecision(self):
> > '''The precision of the library'''
> > if hasattr(self, 'precisionProvider'):
> > if hasattr(self.precisionProvider, 'precision'):
> > return self.precisionProvider.precision
> > return self._defaultPrecision
> > def setDefaultPrecision(self, defaultPrecision):
> > '''The precision of the library'''
> > self._defaultPrecision = defaultPrecision
> > return
> > defaultPrecision = property(getDefaultPrecision, setDefaultPrecision,
> doc = 'The precision of the library’)
> >
> > be cleaned up/simplified/removed with the new BuildSystem model?
> >
> > What was the original need for the provider stuff and is there still a
> need? If there is still a need can it be satisfied some other way. Is there
> every a need for a different provide for different packages? For example
> hypre gets one xxx provider and some other package gets a different xxxx
> provider.
> >
> > The provider stuff is intended to support out-of-package ways to say
> something about the configuration. So we have an object
> > that can come from anywhere. The stuff around it just access the object
> automatically, instead of making the user pull it out and
> > reference it. I thought that was easier.
> >
> > Do you want to just set a flag? I thought that was limiting, and
> duplicated information.
> >
> > You can get rid of all this boilerplate code in newer version of Python.
> We have been
> > outlawing newer versions. If we reopen that discussion, I vote for
> autoinstalling Python
> > 2.7.
> >
> > Thanks,
> >
> > Matt
> >
> > Barry
> > --
> > What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> > -- Norbert Wiener
>
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140930/eea0bc70/attachment.html>
More information about the petsc-dev
mailing list