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

[Satish Balay]

Its fine to have duplicates in default location.

The issue is with using 'gcc -I/usr/include'

i.e 'gcc -I/my/location' will work - irrespective of any packages
installed in default location But 'gcc -I/usr/include -I/my/location'
will break.

However - if one wants to pick up some packages from /usr/local - but
[or /sw/include] - and not others - i.e locations that are not
compiler defaults - that can cause grief..

Satish

On Wed, 27 Jan 2016, Barry Smith wrote:

> 
>   On a different tack, maybe try to find the include file with the default paths BEFORE running the download/install and then stopping and telling the person they are already there in a dangerous place?
> 
>    Barry
> 
>   
> > On Jan 27, 2016, at 2:00 PM, Satish Balay <balay at mcs.anl.gov> 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
> >> 
> >> 
> >> 
> > 
> 
>