[petsc-dev] provider stuff in package.py

[Barry Smith]

  Satish,

   My point these are just low level utilities that belong somewhere in the lower level parts of BuildSystem, not in package.py


On Oct 1, 2014, at 8:30 AM, Satish Balay <balay at mcs.anl.gov> wrote:

> This used to be hacky code in blaslapack.py. I think I must have moved
> it into a function - instead of inline hacks in there. (and updated
> code as we saw breakages)
> 
> Perhaps at some point it was also needed by superlu [since it has some
> blas equivalent - that should be skipping the optimization flags] - so
> it got moved into package.py.
> 
> I guess we didn't do the alternative of identifying optimization flags
> used - and strip them out - as we don't know what they can be.
> Perhaps we could assume optimization flags are stored separately - and
> look for it [instead of assuming] - I don't know..
> 
> Satish
> 
> On Tue, 30 Sep 2014, Barry Smith 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.
>> 
>>   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
>> 
>>