On Tue, 12 Oct 2010, Jed Brown wrote: > On Tue, Oct 12, 2010 at 15:30, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > We could try to filter out empty directories and non-existent directories > > at the end, just before printing to the petscvariables file > > > > Satish fixed the nonexistant /usr/local showing up from valgrind. I think > it's better to fix packages that may be injecting non-existent directories > than to filter them out at the end. It's not necessary to give > -I$PETSC_DIR/$PETSC_ARCH/include twice.
configure does attempt to weed out duplicate paths. However currently they can come from different configure variables in a make target, so a few duplicates are visible. [until make targets are better organized and more work offloaded to configure. But matt wanted to throw away make - so there was no point in better organizing make files for this issue] > > The reason we list directories that "the MPI compiler wrappers" already > > use is for mixed languages. We cannot be sure that all the linkers (c,c++, > > fortran) use each others libraries/directories so we generate a list of all > > that any of them use. It would be possible, though I think too fragile and > > not worth doing for a couple of unneeded -L's to try to, for each language, > > remove those that the compiler for that language already supports > > internally. > > > > Okay, I'm not too concerned by redundant MPI paths as long as they come > *last* (in my case above, the nonexistent /usr/local/include came *after* > MPI directories which is definitely bad). > > I still don't understand manually passing the private (not MPI-related) > compiler path /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1. Maybe this is in > case the Fortran compiler comes from a different vendor, but we still need > to be able to locate libgcc.a. I guess I don't have a good solution to > that, but it still feels icky. we do: 'user-specified-compiler -v' and grab all grabble compiler options from this verbose info' And these private paths, libraries etc are visible from there - and grabbed. [including options in the mpicc wrapper]. The point here is: we do not know which of these options are redundant [esp if one has mpicc with gcc, mpif90 with ifort - or other xlc/xlf] - etc situations. Or wierd compilers and stuff where there are no common paths between c/fortran/c++ compilers. Since there are no smarts in configure to determine and weed out unneeded paths and so far things worked with merging all the options [they are listed in the order scaned from the above compilers] - we stick to using extra options - and not attempting to find the minimal options. We've had numerous petsc-maints where we were missing some special option the compiler was using [at link time] - that was required - and had to fix - than weed out.. Satish
