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

[Barry Smith]

> On Jan 27, 2016, at 11:32 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   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.  
> 
> Once you detect that such a version exists, what are you going to do
> about it?
> 
> A typical situation is that /usr/lib/libhdf5.so is a non-parallel build
> while some other location contains a libhdf5.so built to use a
> particular MPI implementation.  Those versions are fundamentally
> different, but the system might use /usr/lib/libhdf5.so for lots of
> other things and replacing it with the MPI version is not viable.  If
> you alert the user, their response is likely "Yes, I know it's
> there. Now do the right thing."  If you're capable of doing that, why
> not just do it without bothering the user?

   If the other package (i.e. trilinos) is incorrectly looking in the system location for the hdf5 include files before my installed location* (because somebody, as Satish said, got a -I/usr/include where it doesn't belong). Then I don't think I am capable of doing the right thing period!  Hence I would stop and tell the person they either have to remove those files or they need to use them and not use --download-xxx period. 

  Thus I propose if -download-hd5 is used and --download-trilinos we first check for system hdf5 and stop with an error if there are any. Objections?

  Barry

*This is not speculation, this is what wasted my time debugging this afternoon.