[petsc-dev] Disabling a header in configure based on a bad link?

[Matthew Knepley]

On Wed, Sep 25, 2013 at 7:32 AM, Aron Ahmadia <aron at ahmadia.net> wrote:

> Hi folks,
>
> I'm working on a Cygwin64 port of PETSc and I have a question about doing
> a specific disable in BuildSystem based on a failing link.
>
> The Cygwin folks provide an fenv.h implementation that (as far as I can
> tell), is currently broken due to an undefined FE_DFL_ENV variable.  My
> inclination is to disable this functionality in PETSc by declaring that
> fenv.h is unavailable if a simple link test fails.  I tried to write a test
> like this (in Configure.py)
>
> def configureCygwin(self):
>   '''Cygwin specific stuff'''
>   # detect problem with missing FE_DFL_ENV symbol in Cygwin64
>   if not self.checkLink('#include <fenv.h>', 'fesetenv(FE_DFL_ENV)'):
>       self.headers.headers.remove('fenv.h')
>
>
> I don't think it worked.  Has anybody had experience with *disabling*
> functionality in BuildSystem?  Should we be less optimistic about having
> the header and only enable it if the test passes?  Where would it go?
>

I agree that this should be a supported way to go. The problem here is that
the header check already added the make
macro:


https://bitbucket.org/petsc/petsc/src/8dcff661f4ea44e2a26a9a756885f60ead790644/config/BuildSystem/config/headers.py?at=master#cl-83

You can remove this define using


https://bitbucket.org/petsc/petsc/src/8dcff661f4ea44e2a26a9a756885f60ead790644/config/BuildSystem/config/base.py?at=master#cl-149

  Thanks,

      Matt


> Cheers,
> Aron
>



-- 
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/20130925/8c07b8c3/attachment.html>