[petsc-dev] Why is -I$PETSC_DIR/src/dm/mesh/sieve in CLINKER even when configured without Sieve?

[Satish Balay]

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