[petsc-users] automatic determination of which libraries petsc wants

[Sean Farley]

On Thu, Jan 31, 2013 at 6:46 PM, Geoffrey Irving <irving at naml.us> wrote:
> On Thu, Jan 31, 2013 at 4:38 PM, Matthew Knepley <knepley at gmail.com> wrote:
>> On Thu, Jan 31, 2013 at 7:34 PM, Matthew Knepley <knepley at gmail.com> wrote:
>>>
>>> On Thu, Jan 31, 2013 at 7:25 PM, Geoffrey Irving <irving at naml.us> wrote:
>>>>
>>>> We have an scons build system linking against PETSc, and it would be
>>>> nice to have an automatic way of determining the list of libraries
>>>> that a statically linked, installed version of PETSc wants (e.g., the
>>>> MacPorts installed version).  What's a good way to do such a thing
>>>> from *outside* the PETSc build system?
>>>
>>>
>>> It depends on how much work you want to do. For at least two years I
>>> think,
>>> our default had been -lpetsc. I would just do this.
>>
>>
>> Satish is right, use 'make getlinklibs'.
>>
>> However, if you don't have to waste time on a life or family, you may want
>> to consider
>> getting the info straight from the configure. You can load up the Python
>> module from
>> from $PETSC_ARCH/conf/RDict.db and pull out all these things. There is an
>> example
>> in configVars.py.
>
> configVars.py errors out at "import script":
>
>> ./bin/configVars.py
> Traceback (most recent call last):
>   File "./bin/configVars.py", line 7, in <module>
>     import script
> ImportError: No module named script
>
> Indeed, I don't see any file named script.py anywhere underneath
> /optlocal/lib/petsc, nor any directory named exactly "config" as
> configVars seems to want.
>
> Bad macports, bad?

MacPorts does a lot of things bad ;-) Actually, now that I'm a
certified MacPorts developer, I've had my sights on fixing the PETSc
port. First, I need to do some massaging to get the other devs to
understand the need of a standalone gfortran port. Then, the rest will
fall in place (hopefully).