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).
