[petsc-dev] clash of --download-xxx with something in /usr/include /usr/local/include

[Barry Smith]

> On Jan 27, 2016, at 2:10 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> BTW: Wrt /usr/include [or /usr/lib] - one should not pass in this
> location ever to configure [as its a default compiler search path].

   Of course, but this is not relevant here.
> 
> Not sure if its possible for configure to check and error out. [ in
> some cases - one needs these paths - if the compilers - c, c++,
> fortran - do not share the same default paths..]

   I am just suggesting compile a file with #include <Hd5xxx.h> with no additional search paths (so it only checks the default locations) and if the compile succeeds we know there is an install of h5d that could cause problems.  

    I am not suggesting turning off default locations or anything like that.

   Barry

> 
> --with-package-include="" --with-package-lib="-lfoo"
> 
> Satish
> 
> On Wed, 27 Jan 2016, Satish Balay wrote:
> 
>> I guess something like the following might work:
>> 
>> For any include file configure checks - it preserves the signature of
>> its location and dependencies [and locadtions].  I think a
>> 'preprocessed file' will have the relavent info/signature.
>> 
>> And at the end of configure - these signatures [preprcessed files]
>> have to be regenerated - and compare..
>> 
>> Satish
>> 
>> On Wed, 27 Jan 2016, Barry Smith wrote:
>> 
>>> 
>>>   When one runs for example --download-hd5f but there are hdf5 include files in /usr/include or /usr/local/include different compile stages, for example for different external packages, may use the wrong include files leading to very confusing failed builds. 
>>> 
>>>   Is there any systematic tests we could add in configure that could detect this type of potential problem and error out or warn?
>>> 
>>>   Thanks
>>> 
>>>   Barry
>>> 
>>> 
>>> 
>> 
>> 
>