logic of config options

[Satish Balay]

On Tue, 5 May 2009, Giuseppe Ghibò wrote:

> Hi.
> 
> I'm trying to package petsc 2.3.3,

Why package this older version? Current version is 3.0.0.

> but I didn't understand the logic of some options, in particular for
> umfpack.  E.g. If I specify at the config stage:
> 
> --with-umfpack-lib=[${_libdir}/libumfpack.a,${_libdir}/libamd.a]
> 
> and the ${_libdir} path contains both shared and static libraries then
> the linking command are expanded to:
> 
> -lumfpack -Wl,-rpath,<path of petsc> -lamd
> 
> Ditto if I specify:
> 
> --with-umfpack-lib=[libumfpack.a]
> 
> they are expanded to the two libs "-lumpack -lamd" (i.e. it guesses the
> other lib "libamd" even if I don't specify).

petsc-3.0.0 won't add the extra -lamd

> So what is the logic behind the --with-xxx-lib option?  Should I
> specify just the list of comma separated libraries enclosed in
> '[...]' pair?

Yes - this is the python list syntax that configure accepts. However
It should also accept "-Lfoo -lbar" syntax - but it appears to do this
for only a few packages. [Nees fixing?]

> And how to force the usage of static libraries when both shared and
> static exists?

Currently this is not possible. Perhpas it will be if "-Lfoo -lbar" is
supported.

> Because in other cases I see it could be specified also the linking
> command. E.g., if I have a system-wide lapack library, I could use:
> 
> --with-lapack-lib=[-llapack]
> 
> but this sound working in some option and not in some other. So what
> is the "right way"?

yeah - its an inconsitancy on our part...

Satish