Satish Balay <[email protected]> writes: > On Thu, 16 May 2013, Jed Brown wrote: > >> Matthew Knepley <[email protected]> writes: >> >> > I don't think this makes sense. A certain pair of library and include >> > makes sense. Decoupling these invites all sorts of mismatches which >> > would be hard to track down. I do not see what is wrong with the >> > strategy above? >> >> It causes confusing error conditions and in almost all cases, the same >> includes are used for all library guesses. >> > > Even for just the libraries I think we needed: > try (liba) if all true (test1,test2,test3) then accept (liba) > else try (libb) if all true (test1,test2,test3) then accept (libb) > > hence the current code. Perhaps we need multiple semantics for > different situations.
The problem that after finding a _library_ that works, then finding that the includes do not work, and we go on a tangent trying lots of different libs with that same broken include. The include does not depend on the library so I think it should be tested independently. Note that if multiple includes need to be tried, the current approach requires num_include_alternatives * num_lib_alternatives but it could be tested in only num_include_alternatives + num_lib_alternatives Use of multiple includes is rare now, so I don't know if this would significantly affect speed.
